On 4/19/2012 12:32, nemesis wrote:
> so, all your programs are some monolithic piece of software with all parts
> compiled in one go?

Mine are. But then, they get deployed to google's production machines, where 
you really would like them to run stably even if someone else changes their 
code. :-)

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 4/17/2012 12:51, Warp wrote:
>      // Execution will *never* reach here
>      // It's valid to omit a 'return'

But the compiler can prove that statically, so I'm not sure the problem.

I'm also not sure what the problem is with preventing use of uninitialized 
values without requiring the compiler to initialize them.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 4/18/2012 4:13, Warp wrote:>    But the C++ compiler cannot break the 
standard by making the situation
> an error. It can only issue a warning.

You mean, the C++ compiler cannot break the C standard by making this 
illegal. Even tho it makes other valid C programs illegal. :-)

>    (And besides, any kind of detection of this cannot be 100% accurate,
> as the problem "will this line of code ever be reached?" is unsolvable
> in the general case.)

But detecting type errors isn't 100% accurate either.

   int x = 1 ? 5 : "hello";

That's not legal, but it's not a type violation either.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 4/19/2012 18:38, Alain wrote:
> Le 2012/04/17 09:40, Warp a écrit :
>
>>> is a perfectly valid statement in C++. On the other hand, it also mea
ns that
>>
>>> while (x[i] = y[i--]) ;
>>
>>> is perfectly valid. You sick, sick people.
>>
>> I think that's Undefined Behavior because the same variable is being
>> modified and referenced more than once in the same expression.
>>
>
> Nothing undefined here.

Does it compare x[i] to y[i] or to y[i-1]?  Why do you answer that way?

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

Le 20/04/2012 03:16, Darren New a écrit :
> On 4/17/2012 8:06, Warp wrote:
>> Invisible<voi### [at] devnull>  wrote:
>>>>     Likewise template functions are implicitly 'inline' without
>>>> having to
>>>> explicitly say so.
>>
>>> Well, by definition a template generates a new copy of the function each
>>> time you use it, no?
>>
>>    No. A new version is created for each used *type*.
> 
> Technically, I think a new copy of the function is generated/compiled
> for each compilation unit that uses it for each type, but the different
> versions for the same type are merged, right?
> 
> I.e., if x.c uses myfunc<int>() and y.c uses myfunc<int>() you'd need to
> compile that function twice and toss one at link time, right?
> 

IIRC, If the call to myfunc<int>() is done in the same compilation unit
(same top level cpp file), it will be generated once as "static
function" (jump to local symbol, at best; that does not work if it
become inlined code of course).

If they are in separate compilation units (different top level *.cpp
files), each units will get its own version.

Linker will not remove either. (because it has no way to know if the one
in unit A is identical to the one in unit B: naming is no use, you might
have compiled unit A with the version of Monday, and unit B with the
version of Saturday.
(that's the issue with template: generated code can grow very fast if
you use the template in many *.cpp files)

Post a reply to this message

Le 20/04/2012 03:56, Darren New a écrit :
> On 4/19/2012 18:38, Alain wrote:
>> Le 2012/04/17 09:40, Warp a écrit :
>>
>>>> is a perfectly valid statement in C++. On the other hand, it also
>>>> means that
>>>
>>>> while (x[i] = y[i--]) ;
>>>
>>>> is perfectly valid. You sick, sick people.
>>>
>>> I think that's Undefined Behavior because the same variable is being
>>> modified and referenced more than once in the same expression.
>>>
>>
>> Nothing undefined here.
> 
> Does it compare x[i] to y[i] or to y[i-1]?  Why do you answer that way?
> 
You missed the point: let's name k the initial value of i;

Would you expect the test to be between:
 x[k] & y[k]
 x[k-1] & y[k]

It cannot be x[k] & y[k-1], per the definition of the post-decrement
operator.

-- 
A good Manager will take you
through the forest, no mater what.
A Leader will take time to climb on a
Tree and say 'This is the wrong forest'.

Post a reply to this message

>> No. A new version is created for each used *type*.
>
> Technically, I think a new copy of the function is generated/compiled
> for each compilation unit that uses it for each type, but the different
> versions for the same type are merged, right?

I'm presuming that's why it's implicitly inline - to allow the merging.

Post a reply to this message

>>> The integral part of the value is assigned to the int.
>> So... it always rounds towards zero?
>
> As long as they're both positive.

Does it round towards zero, or towards negative infinity?

>> Aren't expressions guaranteed to execute left-to-right?
>
> No. That's what the comma operator is for that you dislike so much. ;-)

Oh good. The book /insists/ that left-to-right order is guaranteed. Nice 
to know that in addition to being poorly explained, it's also factually 
inaccurate. :-P

>> always struggle to remember whether zero means true or false. The
>> solution,
>
> You're aware that boolean math matches up with + and * right? So
> remember it that way.

A better way might be to think of true and false as 1 and 0. (Although 
of course C allows true to be /anything/ that isn't 0, not just 1.)

>> From what I'm seeing, just having multiple compilation units is a
>> nightmare.
>
> Multiple compilation units is only a nightmare when each can't refer to
> any other compilation units.

I'm currently trying to work out how I can compile a program where 
module 1 refers to module 2, but module 2 also refers to module 1. As 
far as I can figure out, this is impossible...

Post a reply to this message

>>>> while (x[i] = y[i--]) ;
>>>
>>>> is perfectly valid. You sick, sick people.
>>>
>>> I think that's Undefined Behavior because the same variable is being
>>> modified and referenced more than once in the same expression.
>>>
>>
>> Nothing undefined here.
>
> Does it compare x[i] to y[i] or to y[i-1]? Why do you answer that way?

Last time I checked, the /comparison/ operator is ==.

The = operator performs *assignment*. :-P

(Assuming that neither x[] nor y[] contains any zero bytes, presumably 
this is also an infinite loop...)

Post a reply to this message

>> When will we see the Haskell# language?
>
> I'm pretty sure the whole .NET bit is too OO to make that useful.There's
> way too much stateful stuff (like I/O) that you'd want to use from .NET
> to make it reasonable to have a purely function .net language.

Haskell already supports a wide range of I/O operations. That's pretty 
stateful, and it's not a problem.

Yeah, if you wanted to talk to the .NET libraries, it would all end up 
being monadic. (Even the .NET stuff that's actually pure - since it 
isn't /marked/ as pure.) But it would still work fine.

I think it's probably vacuous to try to estimate how "useful" it would 
be without actually trying it...

Post a reply to this message