On 4/20/2012 1:38, Invisible wrote:
>>> In other words, yet again, "now you know how this works, you don't
>>> need to actually use it".
>>
>> Right. Except in very limited circumstances when you know how deeply
>> you'll recurse, because there's no guarantee it'll work and no way to
>> check.
>
> ...what?

You have no way of knowing how much stack space you have. Nobody writing 
reliable code wants to recurse for each level of a tree without knowing how 
deep the tree is.

>>> "Registers are a special area of memory built right into the CPU."
>>> Erm...
>>
>> What's questionable about that? Heck, on the Sigma 9, the registers 0
>> thru 15 were actually addressed as memory locations 0 thru 15, to the
>> point where you could store program code in the registers and branch to it.
>
> Nobody designs hardware like that any more. Haven't done for decades. :-P

So? They're still special areas of memory built into the CPU. Just because 
you can't address them using normal addressing modes any more doesn't mean 
they're not memory.

>>> "They take care of internal housekeeping."
>>> ...actually...
>>
>> Program Status Word.
>
> The /registers/ do not take care of anything. The /processor/ does.

Oh come on. :-)  The TLB registers take care of internal housekeeping 
certainly.  As do watchdog timer counters, interrupt mask levels, etc.

>>> So I'm guessing an architecture exists where the instruction pointer
>>> /isn't/ a single register then? :-P
>>
>> Yep. Anything with memory mapping hardware, segment registers, etc.
>
> None of which are relevant in the current day and age, unless you're writing
> an OS. Certainly this technicality has no place in an introductory
> programming text.

You asked. The IP address isn't a single register even on a 8086, and that 
isn't *that* long ago.

>>> Still, it does answer something I've always wondered about: What *is*
>>> the C calling convention?
>>
>> Undefined, generally speaking. Or rather, implementation-specific. And
>> depends on pragmas, sometimes.
>
> So you're telling me that the de facto calling convention that all software
> always uses is "undefined"?

Implementation-specific, yes.  How could you define it in a standard when 
you don't even know what architecture you're compiling for?

-- 
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/20/2012 0:51, Invisible wrote:
>>>> 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?

I don't remember. I never use it under those circumstances, probably because 
it's implementation-defined.

> Oh good. The book /insists/ that left-to-right order is guaranteed.

There are a handful of operators for which that's true. The rest, not so much.

> 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.)

The real way to think of it is "BZ" and "BNZ" - branch on zero, and branch 
on not zero.  Of course, if you don't know common modern assembler, that 
might not be any easier to remember.

> 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...

Neither can actually refer to the other, so you're good to go there. Just 
use the normal header file stuff.

Everything you refer to has to be compiled in the same compilation unit, so 
C and C++ really don't have any trouble with circular references. A benefit 
I never really realized before.

-- 
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/20/2012 5:18, Warp wrote:
> Darren New<dne### [at] sanrrcom>  wrote:
>> If you could #include<abc.o>  you'd get rid of all the silliness of
>> declaring inline functions multiple times, function prototypes, and all that
>> kind of BS.
>
>    So you would be simply changing the dependency to a .h file to dependency
> to a .o file. What would be the relevant difference?

You'd be getting rid of function prototypes, declaring inline functions 
multiple times, mismatched declarations between compilation units, 
compatible compiler flags between separately-compiled modules, and etc. That 
would be the relevant difference.

(Of course, if you *want* to have header files, you can still depend on the 
.o file instead of the .h file, and let people write the .c file even though 
you can still compile against the .h file.)

>    Also, I assume you understand that templated code cannot be precompiled
> into an object file? They need to be recompiled each time they are used...
> which is kind of the whole idea.

Of course. It's basically macro expansion. That's why I didn't say depending 
on a .h file would get rid of template functions.

-- 
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/20/2012 0:20, Le_Forgeron wrote:
> 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;

I don't think I missed the point. I just got the possible answers wrong. 
The 
*point* was that there *were* multiple possible answers. :-)

-- 
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/20/2012 0:55, Invisible wrote:
>>>>> 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

Yah yah. Still missing the point. It's still undefined, whether it's an 
assignment or a comparison.

-- 
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/20/2012 0:57, Invisible wrote:
>>> 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...

Well, they tried making STM work on .NET and gave up because of all the 
state, if you remember.

-- 
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/20/2012 10:02, Orchid Win7 v1 wrote:
> On 20/04/2012 02:41 AM, Darren New wrote:
>> Plus, the IDE for Smalltalk doesn't really deal too much with the fact
>> that it's OO. It didn't do any of the sorts of completion you're talking
>> about.
>
> Well, to be fair, since Smalltalk isn't statically typed, you'd be
> hard-pressed to figure out what messages are applicable to a given variable.
> ;-)

You'd be surprised. People write code that looks at javascript, for example, 
and comes up with something like 70% of the variables being statically typed 
in ways that it's even easy to tell.  Even when you *could* figure it out, 
indeed even when the variable had a value already, you didn't get the sorts 
of completion you're talking about.

-- 
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/20/2012 1:07, Invisible wrote:
>>> (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.
>
> The general problem of determining whether every possible code path is
> well-typed is undecidable. Type systems insert artificial restrictions to
> /make/ the problem decidable. Hence, there are expressions and statements
> which are well-typed, but do not type-check.

Which is the point I'm making. We put up with saying "that'll never be the 
wrong type, but it's still illegal", so the argument that "whether this code 
is reachable is unsolvable, so we shouldn't even try" is equally bogus.)

-- 
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

>> Does it round towards zero, or towards negative infinity?
>
> I don't remember. I never use it under those circumstances, probably
> because it's implementation-defined.

No wonder so many programs don't compile if you (say) change from a 
32-bit OS to a 64-bit OS...

>> 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.)
>
> The real way to think of it is "BZ" and "BNZ"

Sure, that's obviously how it's implemented (and why it works that way). 
Still doesn't help me remember which is which. ;-)

Post a reply to this message

>>> 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.
>>
>> The general problem of determining whether every possible code path is
>> well-typed is undecidable. Type systems insert artificial restrictions to
>> /make/ the problem decidable. Hence, there are expressions and statements
>> which are well-typed, but do not type-check.
>
> Which is the point I'm making.

And I'm agreeing. ;-) [Although I'm not sure I got the technical terms 
right...]

> We put up with saying "that'll never be
> the wrong type, but it's still illegal", so the argument that "whether
> this code is reachable is unsolvable, so we shouldn't even try" is
> equally bogus.)

Well, to be fair, the code you worked is well-typed, but /very stupid/. 
The fact that it gets rejected is no big deal, really.

(OTOH, all the advocates of dynamically-typed languages seem to think 
that this is /the primary reason/ that statically-typed languages suck - 
because you /can't/ just do whatever the hell you want, no matter how 
incoherent.)

Post a reply to this message