Alain <aze### [at] qwertyorg> wrote:
> >>     while (x[i] = y[i--]) ;

> Nothing undefined here.

> It's a simple loop that compare the array x[] and y[] untill it find a 
> value that is different.
> You get the value of x[i] and see if it's the same as the value of y[i] 
> then you decrement i by one.
> On exit, i will point to the value preceding the first different value.

  The compiler is free to decrement 'i' before it evaluates 'x[i]' or
after it. Hence you might get 'x[i]' as it was before the decrement, or
after. (The only thing that is guaranteed is that 'y[i]' is evaluated
before 'i' is decremented.) That's why it's undefined behavior.

-- 
                                                          - Warp

Post a reply to this message

Orchid Win7 v1 <voi### [at] devnull> wrote:
> On the other hand, it appears to be aimed at people who already know the 
> C++ language. That isn't really me, yet. I know some of the syntax, but 
> certainly not all of it, or what all of it actually does.

  I think you'll learn on the fly (at least if you have the right
attitude).

-- 
                                                          - Warp

Post a reply to this message

>> 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...
>
>    The only thing that's impossible for a class to have another class
> as member variable, and that another class having the first class as
> member variable.

Yeah, that's exactly what I'm trying to do.

Actually, no, wait... Class X has class Y as a member, but class Y only 
/mentions/ class X. (It has member functions that return objects of 
class X.)

> (For obvious reasons. It would be an infinitely large class.)

It can if at least one of the classes refers to the other through a 
pointer or a reference. (Think about it: A binary tree class has no 
problem containing /itself/ as a member variable or two.)

So, the way I see it, I have two options:

1. Put class X and class Y in the same header file.

2. Start throwing unchecked casts around the place.

Post a reply to this message

On 20/04/2012 01:36 PM, Warp wrote:
> Orchid Win7 v1<voi### [at] devnull>  wrote:
>> On the other hand, it appears to be aimed at people who already know the
>> C++ language. That isn't really me, yet. I know some of the syntax, but
>> certainly not all of it, or what all of it actually does.
>
>    I think you'll learn on the fly (at least if you have the right
> attitude).

Given that I already some some clue about C++, that might actually work...

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> >    The only thing that's impossible for a class to have another class
> > as member variable, and that another class having the first class as
> > member variable.

> Yeah, that's exactly what I'm trying to do.

  I don't think so.

> Actually, no, wait... Class X has class Y as a member, but class Y only 
> /mentions/ class X. (It has member functions that return objects of 
> class X.)

  Sounds like a rather complicated design. Anyways, you can declare classes
(as opposed to defining them). In other words, you can do this:

//----------------------------------------
// This could be eg. in a "Y.hh" header file
class X; // declaration of X

class Y
{
 public:
    void foo() { std::cout << "I'm an Y\n"; }
    X gimmeAnX();
};
//----------------------------------------

  You can then define X for example like:

//----------------------------------------
// This could be eg. in a "X.hh" header file,
// in which case you would have a
// #include "Y.hh" here.
class X
{
    Y anObjectOfY;

 public:
    void bar() { anObjectOfY.foo(); }
};
//----------------------------------------

  After both definitions you can now implement the Y::gimmeAnX() function,
eg. like:

//----------------------------------------
// This could be eg. in a "Y.cc" source file,
// in which case you would have a
// #include "X.hh" here.
X Y::gimmeAnX() { return X(); }
//----------------------------------------

  (All of the above code could be in one single source file as well,
in that order, which is why I didn't explicitly use any #include lines.)

> > (For obvious reasons. It would be an infinitely large class.)

> It can if at least one of the classes refers to the other through a 
> pointer or a reference.

  It wouldn't be a member variable then.

> So, the way I see it, I have two options:

> 1. Put class X and class Y in the same header file.

  Not necessary (and even if you put it in the same header file, that alone
wouldn't solve your problem).

> 2. Start throwing unchecked casts around the place.

  The correct solution is to use class declarations.

-- 
                                                          - Warp

Post a reply to this message

On 20/04/2012 03:15 PM, Warp wrote:

>    Sounds like a rather complicated design. Anyways, you can declare classes
> (as opposed to defining them). In other words, you can do this:
>
> //----------------------------------------
> // This could be eg. in a "Y.hh" header file
> class X; // declaration of X

Ah, I see. This is the fact I was looking for. :-)

So this does... what? Tells the compiler "hey, this type exists, but I'm 
not going to tell you anything about it"?

>>> (For obvious reasons. It would be an infinitely large class.)
>
>> It can if at least one of the classes refers to the other through a
>> pointer or a reference.
>
>    It wouldn't be a member variable then.

What would it be then?

>> 1. Put class X and class Y in the same header file.
>
>    Not necessary (and even if you put it in the same header file, that alone
> wouldn't solve your problem).

Quite right. That doesn't help at all...

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> > class X; // declaration of X

> Ah, I see. This is the fact I was looking for. :-)

> So this does... what? Tells the compiler "hey, this type exists, but I'm 
> not going to tell you anything about it"?

  It tells that there's a class named X.

  From that point forward you can do anything with that type that does not
require calling its member functions or accessing its contents. (In other
words, you can handle pointers and references of that type.) You can also
make further declarations using it (such as declaring it as the return
type of a function).

  Doing anything else with an object of that type requires a full class
definition, but that can be done later in the code.

  This allows inter-dependency between classes.

> >>> (For obvious reasons. It would be an infinitely large class.)
> >
> >> It can if at least one of the classes refers to the other through a
> >> pointer or a reference.
> >
> >    It wouldn't be a member variable then.

> What would it be then?

  A pointer/reference to an object of that type.

  What I mean is that you can't do this:

class A { B b; };
class B { A a; };

  That would be a pair of infinitely large classes.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   From that point forward you can do anything with that type that does not
> require calling its member functions or accessing its contents.

  (Oh, and of course anything requiring knowing the size of X doesn't work
with the declaration only, of course. For instance, "sizeof(X)" obviously
doesn't work without the full class definition.)

-- 
                                                          - Warp

Post a reply to this message

Le 2012-04-19 09:21, Invisible a écrit :
>>>> in any case, even humble C can do that, provided a Makefile is ready.
>>>> heck, Makefiles are language-agnostic even...
>>>
>>> Makefiles only work on Unix. :-P But hey, you can write a simple script
>>> to build your project under Windows.
>>
>> WAT?
>
> To tell you the truth, I don't even /like/ Make all that much. (I think
> it's the tab characters. Or the slightly clunky way it deals with
> targets that aren't files.) I only really use it for building C, because
> it's either that or work out how to invoke the compiler manually...
>
> But as I say, a tiny amount of shell scripting will automate most tasks,
> without the need for Make.
>

If you like reinventing the wheel... ;)

>>> The /real/ problem, of course, is that you have to open a command
>>> window, CD to the right folder, and type in "make program1" or whatever.
>>> This takes significantly longer than pressing F7 (or whatever).
>>
>> Which you only have to do once... After that you only need to hit
>> ALT-TAB and the up arrow.
>
> That works great - /until/ your command history has more than one
> command in it. E.g., if you use the same window to run the compiler, run
> the main program, and control your SCM. Then you end up jabbing up-arrow
> endlessly, or executing the wrong command, or both. Very annoying.
>

You know you can open more than one command promt.

> (I wonder why nobody has yet thought of making an editor where you can
> add buttons to the toolbar and kind arbitrary commands to them? You
> could even give them keyboard shortcuts...)
>

Dare I say it?  Oh... sure... why not...

Emacs does it.  ;)

Notepad++ too.

>> Starting notepad++ and a command prompt take significantly less time
>> than starting any IDE.
>
> Depends on the IDE. Some are slower than others. I do take your point
> though - some of them do take an absurd amount of time to start. Then
> again, "you only do that once". :-P
>
>>> Sure, once you take your hands off the keyboard and onto the mouse to
>>> switch from the text editor window to the command prompt window. :-P
>>>
>>
>> As mentioned previously, ALT-TAB. Much faster.
>
> And if in the middle of your coding session, you quickly switch to your
> email client to check something, next time you try to use Alt+Tab, it
> takes you to the wrong window.
>

Keep you thumb on ALT, and hit TAB repeatedly until you get to the right 
application.

> It sounds trivial, but it's really very, very annoying.
>
> (It becomes even more fun when what you're working on involves more
> windows. E.g., right now I'm writing some TeX, so I have my text editor
> open, my command window open, and my DVI window open. You can 100%
> guarantee that almost every time I change window I change to the wrong
> one...)

I usually have my e-mail client, corporate instant messenger app ( 
usually with a few chat windows opened), 3 or four browser windows, a 
couple Excel sheets, two VPN apps (don't ask!) and a couple other 
network monitoring apps loaded at any one time.  Mastering the ALT-TAB 
combo is much, much, much, faster than using the mouse to switch apps 
from the task bar.  Not to mention a lot cheaper than a dozen 
occupational therapy sessions due to tendinitis or carpal tunnel syndrome.

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

On 20/04/2012 03:29 PM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>>> class X; // declaration of X
>
>> Ah, I see. This is the fact I was looking for. :-)
>
>> So this does... what? Tells the compiler "hey, this type exists, but I'm
>> not going to tell you anything about it"?
>
>    It tells that there's a class named X.
>
>    From that point forward you can do anything with that type that does not
> require calling its member functions or accessing its contents. (In other
> words, you can handle pointers and references of that type.) You can also
> make further declarations using it (such as declaring it as the return
> type of a function).
>
>    Doing anything else with an object of that type requires a full class
> definition, but that can be done later in the code.
>
>    This allows inter-dependency between classes.

Right. So I can declare functions that take it or return it, and I can 
declare (but not define) variables of that type. And then I can #include 
the full description before I try implementing anything that actually 
needs to touch it "for real". (?)

>    What I mean is that you can't do this:
>
> class A { B b; };
> class B { A a; };
>
>    That would be a pair of infinitely large classes.

Yes, clearly that can't work.

Post a reply to this message

>> To tell you the truth, I don't even /like/ Make all that much. (I think
>> it's the tab characters. Or the slightly clunky way it deals with
>> targets that aren't files.) I only really use it for building C, because
>> it's either that or work out how to invoke the compiler manually...
>>
>> But as I say, a tiny amount of shell scripting will automate most tasks,
>> without the need for Make.
>
> If you like reinventing the wheel... ;)

Not so much "reinventing the wheel". More like "I don't actually need 
the full power of Make".

>> That works great - /until/ your command history has more than one
>> command in it. E.g., if you use the same window to run the compiler, run
>> the main program, and control your SCM. Then you end up jabbing up-arrow
>> endlessly, or executing the wrong command, or both. Very annoying.
>
> You know you can open more than one command promt.

...which just changes the problem from "hitting the up arrow the right 
number of times" to "hitting Alt+Tab the right number of times".

>> (I wonder why nobody has yet thought of making an editor where you can
>> add buttons to the toolbar and kind arbitrary commands to them? You
>> could even give them keyboard shortcuts...)
>
> Dare I say it? Oh... sure... why not...
>
> Emacs does it. ;)

Yeah, but... WHY WOULD YOU DO THAT? >_<

>>> As mentioned previously, ALT-TAB. Much faster.
>>
>> And if in the middle of your coding session, you quickly switch to your
>> email client to check something, next time you try to use Alt+Tab, it
>> takes you to the wrong window.
>
> Keep you thumb on ALT, and hit TAB repeatedly until you get to the right
> application.

I know that. It's still more fiddly and error-prone than just jabbing a 
button that always does the same thing, regardless of which application 
window you used most recently.

>> (It becomes even more fun when what you're working on involves more
>> windows.
>
> Mastering the ALT-TAB
> combo is much, much, much, faster than using the mouse to switch apps
> from the task bar.

It depends how far back in the stack you need to cycle. At some point, 
the mouse becomes faster.

> Not to mention a lot cheaper than a dozen
> occupational therapy sessions due to tendinitis or carpal tunnel syndrome.

Nobody gets tendinitis just from using a mouse.

You /might/ get tendinitis from working on a production line, executing 
the exact same pick up, solder, put down movements eight times per 
minute for hours on end without stopping for so much as twenty seconds 
for a break. (Yes, I've tried it.) You don't get it just from operating 
a computer normally. Not if you have sane desk height, etc.

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Right. So I can declare functions that take it or return it, and I can 
> declare (but not define) variables of that type.

  Btw, a class that has only been declared but not defined (in other words,
you have only said "class X;") is called an "incomplete type" in C++
parlance.

  You can have pointers and references to an incomplete type, and you can
use it wherever a type is required (without any actual object), such as in
function declarations. In other words, you can do eg. like this:

//--------------------------------------------------------------------
class MyClass;

// Function that takes an object of type MyClass as parameter and
// returns another object of that type:
MyClass aFunction(MyClass object);
//--------------------------------------------------------------------

  (Of course if you try to *call* that function without a full class
definition, you'll get a compiler error.)

  You could also declare an extern variable of that type (although that's
a quite rare circumstance, but it's still possible). In other words:

//--------------------------------------------------------------------
class MyClass;

extern MyClass aGlobalObject;
//--------------------------------------------------------------------

  One situation where you ought to not be able to do it, but you can, due
to a quirk in the language, is deleting an object using an incomplete
type. In other words, this will compile, albeit usually with a warning:

//--------------------------------------------------------------------
class MyClass;

void foo(MyClass* objPtr)
{
    delete objPtr; // Never do this!
}
//--------------------------------------------------------------------

  The major, major problem with that is that, while the memory taken by
that object will be freed, the destructor of the object will *not* be
called. Bad things will happen. (There was some reasoning why it's
nevertheless allowed by the standard, but I don't remember now what it
was.)

  This, however, will work ok:

//--------------------------------------------------------------------
class MyClass

// An extern function that allocates an object of type MyClass and
// returns it:
std::shared_ptr<MyClass> gimmeAnObjectOfTypeMyClass();

void foo()
{
    std::shared_ptr<MyClass> ptr = gimmeAnObjectOfTypeMyClass();

    // When foo() is exited, the allocated object will be destroyed
    // properly. In other words, its destructor will be called ok.
}
//--------------------------------------------------------------------

  The implementation of gimmeAnObjectOfTypeMyClass() (in a completely
different source file) can simply be:

//--------------------------------------------------------------------
#include "FullDefinitionOfMyClass.hh"

std::shared_ptr<MyClass> gimmeAnObjectOfTypeMyClass()
{
    return new MyClass(); // Constructs and returns an object of MyClass
}
//--------------------------------------------------------------------

  In the code above where the returned object is destroyed, at no point do we
have a full definition of 'MyClass'. Nevertheless, when the std::shared_ptr
that's managing it goes out of scope, it will delete it and its destructor
will be called. It achieves this through template magic.

  (Nevertheless, you seldom need to resort to this kind of trickery in
practical code. At least not this explicitly. Don't take this as an
example of what kind of code people usually write in C++.)

-- 
                                                          - Warp

Post a reply to this message

On 20/04/2012 04:16 PM, Warp wrote:

>    Btw, a class that has only been declared but not defined (in other words,
> you have only said "class X;") is called an "incomplete type" in C++
> parlance.

Right.

>    You can have pointers and references to an incomplete type, and you can
> use it wherever a type is required (without any actual object), such as in
> function declarations. In other words, you can do eg. like this:
>
> //--------------------------------------------------------------------
> class MyClass;
>
> // Function that takes an object of type MyClass as parameter and
> // returns another object of that type:
> MyClass aFunction(MyClass object);
> //--------------------------------------------------------------------
>
>    (Of course if you try to *call* that function without a full class
> definition, you'll get a compiler error.)

How about if you try to write the function body without the full class? 
I'm presuming that will fail too, since the compiler needs to know how 
much space to allocate...

>    You could also declare an extern variable of that type (although that's
> a quite rare circumstance, but it's still possible).

Right. But presumably you can't actually /create/ the variable, because 
you don't know it's size. (?)

>    One situation where you ought to not be able to do it, but you can, due
> to a quirk in the language, is deleting an object using an incomplete
> type. In other words, this will compile, albeit usually with a warning:
>
> //--------------------------------------------------------------------
> class MyClass;
>
> void foo(MyClass* objPtr)
> {
>      delete objPtr; // Never do this!
> }
> //--------------------------------------------------------------------
>
>    The major, major problem with that is that, while the memory taken by
> that object will be freed, the destructor of the object will *not* be
> called. Bad things will happen. (There was some reasoning why it's
> nevertheless allowed by the standard, but I don't remember now what it
> was.)

Oooohhhhh that's evil.

>    In the code above where the returned object is destroyed, at no point do we
> have a full definition of 'MyClass'. Nevertheless, when the std::shared_ptr
> that's managing it goes out of scope, it will delete it and its destructor
> will be called. It achieves this through template magic.

Sure. When the template expands, we /do/ have the full class spec, so it 
works. (At least, I'm presuming that's what happens.)

>    (Nevertheless, you seldom need to resort to this kind of trickery in
> practical code. At least not this explicitly. Don't take this as an
> example of what kind of code people usually write in C++.)

Oh hell yes - I don't intend on trying this... ever, actually.

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> >    In the code above where the returned object is destroyed, at no point do we
> > have a full definition of 'MyClass'. Nevertheless, when the std::shared_ptr
> > that's managing it goes out of scope, it will delete it and its destructor
> > will be called. It achieves this through template magic.

> Sure. When the template expands, we /do/ have the full class spec, so it 
> works. (At least, I'm presuming that's what happens.)

  The std::shared_ptr object in that example doesn't see the complete
definition of the class at any moment, because it hasn't been defined.
It gets initialized with another instance of std::shared_ptr (which was
created in that function somewhere else), but it itself doesn't see the
full definition of the class it's managing.

  To recapitulate:

//---------------------------------------------------------------------
class MyClass; // incomplete type

// A function somewhere else that returns a std::shared_ptr object:
std::shared_ptr<MyClass> foo();

void bar()
{
    std::shared_ptr<MyClass> ptr;
    // *this* shared_ptr object does not see a MyClass definition
    // at any point

    ptr = foo();
    // The shared_ptr returned by foo() is assigned to it.

    // Now when bar() ends, 'ptr' will destroy the object.
    // And properly at that. The destructor will be called ok.
    // Yet 'ptr' never sees the full definition of 'MyClass'.
}
//---------------------------------------------------------------------

  Even though 'ptr' above at no point sees the full definition of
'MyClass', it just works. It does so by employing template magic.

-- 
                                                          - Warp

Post a reply to this message

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

Post a reply to this message

On 4/20/2012 1:28, Invisible wrote:
> So what /was/ the Motorola 68000 designed to be programmed in then?

I would guess C or Algol or some such. There's a separation between address 
and data registers, there's a stack pointer, there are various addressing 
modes that (IIRC) include auto-increment, etc.

The 8086 was designed to be efficient for Pascal, for example. But not too 
efficient, given that it doesn't have proper frame pointers.

>>> I dislike code that's so littered with comments that you can't see the
>>> code
>>
>> Except in assembler.
>
> ?

At least on machines designed to be programmed in assembler, one can 
generally put a useful and informative comment on pretty much every line.

> It worries me that we're still using a language who's fundamental design
> decisions are based on hardware first produced in the 1970s.

Yep.

>>> So much for C and C++ being for system-level programming. :-P
>>
>> It was never very *good* for it. It was just better than its competitors
>> of the time.
>
> Jesus, did it even *have* any competitors?!

Assembly. ;-)  Probably LISP.  COBOL to a large extent.

>> No, of course not. C doesn't provide any way to ask for a type based on
>> what you need. You can only ask for types based on what the CPU
>> provides
>
> OK, well IA-32 provides 80-bit floats. So... is there a standard way to get
> them?

AFAIK, you have float and double. Maybe there's now a long double, but I 
don't recall.

> You'd expect part of the language's basic syntax to be, you know... part of
> the language's basic syntax. But it isn't. It's just a regular operator,
> which means you can use it in places where you shouldn't be putting random
> commas, and that makes it do strange stuff. (And, being C, this isn't
> checked in any way.)

Why would you put randomg *anything* in? This isn't a sonnet. It's computer 
code.  Why would you put random commas in any more than you put random quote 
marks in?

> The /logical/ thing is for a function that doesn't mention a return type to
> default to returning nothing. And yet, it doesn't. It arbitrarily defaults
> to int. Not bool, not void*, not w_char, but int. No reason, it just does.

Remember the compilation model.  Plus, "void" is a relatively recent 
development.

> I forget who said it: comprehension = 2 ^ -precision.

You just have to think mathely.


-- 
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:15, Le_Forgeron wrote:
> 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.

I don't think mis-matched declarations were ever something that C worried 
about. Does C++ actually check that sort of thing now?

I know that with Ada, you can't link incompatible object code, in the sense 
that if you have (the equivalent of) A.h and A.c and B.c, and B.c uses A.h, 
then both A.c and B.c have to get compiled after A.h gets compiled. If you 
go change A.h after you've already compiled A.c, you can no longer link 
against the old binary. The compiler winds up doing stuff like putting the 
hashes of every header file (equivalent) into each object code generated, 
and then checking they all match up at link time.

-- 
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:11, Warp wrote:
> Darren New<dne### [at] sanrrcom>  wrote:
>>> The book claims that if you write a function body inside a class definition,
>>> that makes the method inline. Is this true? I thought there was no
>>> difference either way...
>
>> It *has* to be.
>
>    It doesn't *have* to be (any more than any other function defined in a
> header file, or anywhere else), but the standard says it is, and so it is.

I meant, it *has* to be or it will link but won't compile, because you wind 
up compiling a version of the header file in each .c file it's included in.

Sure, it doesn't *have* to be implicitly inline, but since every function in 
a header file is either inline, or shouldn't be in the header file in the 
first place, or fails to link, it made sense to make the default "yes, 
please work."

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

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

Nobody writes recursive code? IN WHICH UNIVERSE??

I'm also loving the way you say "you don't know how big the stack is", 
and immediately follow that with "you should check how deep the tree 
is". But if you don't know how big the stack is, you STILL don't know if 
you can do it. :-P

Besides, it's not like there's an /alternative/ to recursion.

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

Well, to be /technical/ about it, the entire concept of "memory" is a 
fiction. It would be more accurate to say that there is a large topology 
of transistors connected together - but that's not a very useful way to 
think about it.

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

Amazing. So the one calling convention that every piece of software 
supports isn't actually defined at all. That's impressive, right there.

Post a reply to this message

> At least on machines designed to be programmed in assembler, one can
> generally put a useful and informative comment on pretty much every line.

I haven't yet seen an assembler where you /can't/ stick comments 
anywhere you want to. That /still/ doesn't mean I want the comments to 
out-number the actual code.

>> You'd expect part of the language's basic syntax to be, you know...
>> part of
>> the language's basic syntax. But it isn't. It's just a regular operator,
>> which means you can use it in places where you shouldn't be putting
>> random
>> commas, and that makes it do strange stuff. (And, being C, this isn't
>> checked in any way.)
>
> Why would you put randomg *anything* in? This isn't a sonnet. It's
> computer code. Why would you put random commas in any more than you put
> random quote marks in?

Ever heard of something called a "mistake"? Perhaps you don't make 
those, but I do sometimes. And it's worrying to know that if I do, the 
compiler isn't going to say "oh, you made a mistake", it's just going to 
generate code that does something bizarre.

> Plus, "void" is a relatively recent development.

This is The Real WTF.

Post a reply to this message

On 4/21/2012 11:30, Orchid Win7 v1 wrote:
>> At least on machines designed to be programmed in assembler, one can
>> generally put a useful and informative comment on pretty much every line.
>
> I haven't yet seen an assembler where you /can't/ stick comments anywhere
> you want to. That /still/ doesn't mean I want the comments to out-number the
> actual code.

I said "useful."

> Ever heard of something called a "mistake"? Perhaps you don't make those,
> but I do sometimes. And it's worrying to know that if I do, the compiler
> isn't going to say "oh, you made a mistake", it's just going to generate
> code that does something bizarre.

Sure. And if you randomly change * to / and + to -, you'll get similar 
errors. In practice, it's not a mistake people make.

-- 
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/21/2012 11:28, Orchid Win7 v1 wrote:
>> 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.
>
> Nobody writes recursive code? IN WHICH UNIVERSE??

I have written very very little recursive code in my entire career. Of that, 
90% of my recursive code is of the form
   Try to X, 10 times.
   if X failed,
     Try to X one fewer times

Yes, my current project has a tree structure that's at most 3 levels deep, 
and parsing that into flat structures is recursive, once. Before that, it 
was iterative over a queue. (Actually, it might still be, I don't remember.)

> I'm also loving the way you say "you don't know how big the stack is", and
> immediately follow that with "you should check how deep the tree is". But if
> you don't know how big the stack is, you STILL don't know if you can do it. :-P

Well, I know the stack is deep enough to hold 3 levels of tree. The point is 
you can't take an *arbitrary* tree and parse it recursively.

> Besides, it's not like there's an /alternative/ to recursion.

Of course there is. I'm pretty sure every recursive algorithm can be made 
explicitly iterative. The advantage of doing so is that you can handle 
failures of running out of resources, before you ask.

>>> 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.
>
> Well, to be /technical/ about it, the entire concept of "memory" is a
> fiction. It would be more accurate to say that there is a large topology of
> transistors connected together - but that's not a very useful way to think
> about it.

But in some cases, those transistors are wired together in a way that 
retains state arbitrarily long, which we call memory. ;-)

>>> 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?
>
> Amazing. So the one calling convention that every piece of software supports
> isn't actually defined at all. That's impressive, right there.

Which calling convention do you think every piece of software supports? It's 
defined by the implementation. Have you tried invoking Java code from C? 
Have you tried invoking C# code from C++? Have you invoked C++ objects from 
Haskell?

http://www.scribd.com/doc/20689745/Calling-Conventions

Not sure if you're trying to be sarcastic, incredulous, or simply ignorant here.

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

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

They gave up because they tried to make all the existing state mutation 
stuff still work in the presence of transactions, which is /obviously/ 
impossible.

Post a reply to this message

>> Ever heard of something called a "mistake"? Perhaps you don't make those,
>> but I do sometimes. And it's worrying to know that if I do, the compiler
>> isn't going to say "oh, you made a mistake", it's just going to generate
>> code that does something bizarre.
>
> Sure. And if you randomly change * to / and + to -, you'll get similar
> errors. In practice, it's not a mistake people make.

If you're in the middle of writing an expression, and the phone rings or 
something, and then you got back and hit "compile", it says "hey dude, 
this * operator only has one argument. Shouldn't there be two?"

But, apparently, if you're half way through writing a function call and 
the same thing happens, the compiler doesn't say anything, because comma 
is just a valid operator that you can put anywhere you want...

Post a reply to this message

>> Nobody writes recursive code? IN WHICH UNIVERSE??
>
> I have written very very little recursive code in my entire career.

Damn... I'm trying to think of something you can code without actually 
using recursion. Hmm. Well, I guess there must be /something/...

>> Besides, it's not like there's an /alternative/ to recursion.
>
> Of course there is. I'm pretty sure every recursive algorithm can be
> made explicitly iterative. The advantage of doing so is that you can
> handle failures of running out of resources, before you ask.

So if you want to count how many nodes there are in a binary tree, how 
do you do that non-recursively?

>> Amazing. So the one calling convention that every piece of software
>> supports
>> isn't actually defined at all. That's impressive, right there.
>
> Which calling convention do you think every piece of software supports?

> Not sure if you're trying to be sarcastic, incredulous, or simply
> ignorant here.

If a programming language supports calling /any/ foreign language, that 
language will always be C. It will know about standard C types, it will 
usually know about C structs, and it will let you call arbitrary C 
functions.

And yet, the way that you call a C function is, apparently, undefined.

That's pretty bizarre.

It also makes me wonder how the heck it's possible to take object code 
from multiple C compilers and link it all together, if each of them is 
potentially using a completely different calling convention. It sounds 
like it shouldn't work.

Post a reply to this message

Le 2012-04-20 10:47, Invisible a écrit :
>> Not to mention a lot cheaper than a dozen
>> occupational therapy sessions due to tendinitis or carpal tunnel
>> syndrome.
>
> Nobody gets tendinitis just from using a mouse.
>

I have two weeks off work, 10 physiotherapy sessions and a visit from an 
occupational therapist at home to redesign my work space that disagree 
with you.

When you need to use the mouse with your right hand, you need to lift 
your arm over the numeric keypad and off to the side to grab the mouse, 
then move the arm back to the keyboard so that your can continue typing. 
  In most cases, this means lifting your entire arm from the shoulder on 
down, whereas if you were using your mouse left-handed, you'd only need 
to move your wrist, with your elbow still resting on the chair's arm rest.

Repeated sporadic use of the mouse over the course of two long mights 
and days of work did cause me to have tendinitis bad enough that I had 
to be driven to the hospital since I could no longer lift my right arm 
at the shoulder, and it would have been too dangerous to try to drive in 
those conditions.

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

>> Nobody gets tendinitis just from using a mouse.
>
> I have two weeks off work, 10 physiotherapy sessions and a visit from an
> occupational therapist at home to redesign my work space that disagree
> with you.

OK. So maybe you had the desk at the wrong height or something? IDK. 
I've been using a mouse since I was 12, sometimes staying up to program 
until 2 in the morning, and it hasn't caused my any trouble.

FWIW, I also play keyboard, where you have to constantly support the 
entire weight of your arm all the time. And I played violin for years...

> When you need to use the mouse with your right hand, you need to lift
> your arm over the numeric keypad and off to the side to grab the mouse,
> then move the arm back to the keyboard so that your can continue typing.
> In most cases, this means lifting your entire arm from the shoulder on
> down, whereas if you were using your mouse left-handed, you'd only need
> to move your wrist, with your elbow still resting on the chair's arm rest.

I usually have an arm rest set up so I only have to lift my forearm, not 
my entire arm, but hey.

> Repeated sporadic use of the mouse over the course of two long mights
> and days of work did cause me to have tendinitis bad enough that I had
> to be driven to the hospital since I could no longer lift my right arm
> at the shoulder, and it would have been too dangerous to try to drive in
> those conditions.

Damn. And to think that I have to lift 14 stone of my dance partner...

That said, my shoulder *does* hurt now! >_<

Post a reply to this message

Le 2012-04-23 09:25, Invisible a écrit :
>>> Nobody gets tendinitis just from using a mouse.
>>
>> I have two weeks off work, 10 physiotherapy sessions and a visit from an
>> occupational therapist at home to redesign my work space that disagree
>> with you.
>
> OK. So maybe you had the desk at the wrong height or something? IDK.
> I've been using a mouse since I was 12, sometimes staying up to program
> until 2 in the morning, and it hasn't caused my any trouble.

It wasn't a problem for me either until I had to do it 40 hours straight...

>
> FWIW, I also play keyboard, where you have to constantly support the
> entire weight of your arm all the time. And I played violin for years...
>

That's probably it, your shoulder muscles are trained.

>> When you need to use the mouse with your right hand, you need to lift
>> your arm over the numeric keypad and off to the side to grab the mouse,
>> then move the arm back to the keyboard so that your can continue typing.
>> In most cases, this means lifting your entire arm from the shoulder on
>> down, whereas if you were using your mouse left-handed, you'd only need
>> to move your wrist, with your elbow still resting on the chair's arm
>> rest.
>
> I usually have an arm rest set up so I only have to lift my forearm, not
> my entire arm, but hey.
>
>> Repeated sporadic use of the mouse over the course of two long mights
>> and days of work did cause me to have tendinitis bad enough that I had
>> to be driven to the hospital since I could no longer lift my right arm
>> at the shoulder, and it would have been too dangerous to try to drive in
>> those conditions.
>
> Damn. And to think that I have to lift 14 stone of my dance partner...
>
> That said, my shoulder *does* hurt now! >_<

Not for 40 hrs straight...;)

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

Le 21/04/2012 05:43, Darren New a écrit :
> 
> I don't think mis-matched declarations were ever something that C
> worried about. Does C++ actually check that sort of thing now?

The mangling pattern/scheme of C++ for function's name uses a lot of the
signature: the namespace, the name itself and the description of the
arguments' types. A bit more than C with its double underscores.

As we are talking of template, I would think the code would be
duplicated anyway in the many files: templates are most probably inline
(if you use 1 of 13 templates, your code only get the one you used).

-- 
Software is like dirt - it costs time and money to change it and move it
around.

Just because you can't see it, it doesn't weigh anything,
and you can't drill a hole in it and stick a rivet into it doesn't mean
it's free.

Post a reply to this message

>> Damn. And to think that I have to lift 14 stone of my dance partner...
>>
>> That said, my shoulder *does* hurt now! >_<
>
> Not for 40 hrs straight...;)

Christ, 40 *seconds* straight is enough to wipe me out. o_O

I'm such a weed...

Post a reply to this message

On 20/04/2012 02:03 PM, Invisible wrote:
> On 20/04/2012 01:36 PM, Warp wrote:
>> Orchid Win7 v1<voi### [at] devnull> wrote:
>>> On the other hand, it appears to be aimed at people who already know the
>>> C++ language. That isn't really me, yet. I know some of the syntax, but
>>> certainly not all of it, or what all of it actually does.
>>
>> I think you'll learn on the fly (at least if you have the right
>> attitude).
>
> Given that I already some some clue about C++, that might actually work...

You know what? I'm just going to /buy/ the book. In the unlikely event 
that it actually helps me to get a better job, it will have easily paid 
for itself multiple times over.

Post a reply to this message

On 4/23/2012 1:08, Invisible wrote:
> a valid operator that you can put anywhere you want...

It has to be between two other arguments, and you can't write a naked comma 
operator in the middle of a function's arguments, because commas separate 
function arguments. So you'd still get a compiler error.

-- 
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/24/2012 0:07, Le_Forgeron wrote:
> The mangling pattern/scheme of C++ for function's name

Ah yes.  I had forgotten about that.

-
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/23/2012 1:31, Invisible wrote:
> Damn... I'm trying to think of something you can code without actually using
> recursion. Hmm. Well, I guess there must be /something/...

Almost all business logic. I don't remember seeing any recursion in any 
operating system kernels I've read. I can't think of any recursive SQL code 
I've written at all.

> So if you want to count how many nodes there are in a binary tree, how do
> you do that non-recursively?

You use a queue. Each node you visit, you tack on to the end of the queue to 
be counted, and you go until the queue is empty.

Alternately, manually maintain the stack. Which is not "recursion" in the C 
sense, because you can actually tell without just blasting memory in unknown 
ways when you run out of room for the stack.

> If a programming language supports calling /any/ foreign language, that
> language will always be C. It will know about standard C types, it will
> usually know about C structs, and it will let you call arbitrary C functions.

OK. Yes, as long as you link to the proper C calling convention.

> And yet, the way that you call a C function is, apparently, undefined.

It's implementation-defined. You have to read the compiler manual (or source 
code) to know what the sequence is. And different functions in the same code 
can have different calling conventions.

Unless you have a CPU that actually enforces calling conventions.

> It also makes me wonder how the heck it's possible to take object code from
> multiple C compilers and link it all together, if each of them is
> potentially using a completely different calling convention. It sounds like
> it shouldn't work.

And indeed it doesn't. Try compiling one library with gcc and another with 
visual C and see if they link cleanly. Take a library off the mac and link 
it to a Windows-compiled main().

For that matter, try compiling one program for x86 and the other for x64.

-- 
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/23/2012 0:59, Invisible wrote:
>>> 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.
>
> They gave up because they tried to make all the existing state mutation
> stuff still work in the presence of transactions, which is /obviously/
> impossible.

That's my point.  How useful would it be if you couldn't actually use any of 
the other .NET libraries, including even I/O, reflection, etc.?

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

>>> Well, they tried making STM work on .NET and gave up because of all the
>>> state, if you remember.
>>
>> They gave up because they tried to make all the existing state mutation
>> stuff still work in the presence of transactions, which is /obviously/
>> impossible.
>
> That's my point. How useful would it be if you couldn't actually use any
> of the other .NET libraries, including even I/O, reflection, etc.?

You do all of that stuff from /outside/ your transactions, that's all. 
Remember, transactions are only for thread communication. You start a 
transaction, fetch the next work item from the shared work queue, and 
the transaction. Then you process the work item, calling whatever 
libraries you need. Simples.

Post a reply to this message

On 25/04/2012 06:22 AM, Darren New wrote:
> On 4/23/2012 1:31, Invisible wrote:
>> Damn... I'm trying to think of something you can code without actually
>> using recursion. Hmm. Well, I guess there must be /something/...
>
> Almost all business logic.

I suppose I should consider myself lucky that I'm never going to be 
writing anything like that.

> I don't remember seeing any recursion in any
> operating system kernels I've read.

Really? That's surprising. No recursive sorting algorithms for balancing 
the B*-trees that the directory nodes use, or for sorting the ready 
thread list by priority?

> I can't think of any recursive SQL code I've written at all.

SQL is a rather special-purpose language. I'm not sure it even 
/supports/ recursion...

>> So if you want to count how many nodes there are in a binary tree, how do
>> you do that non-recursively?
>
> You use a queue. Each node you visit, you tack on to the end of the
> queue to be counted, and you go until the queue is empty.

In other words, you manually implement the stack.

Tell me, in what way does this prevent you running out of stack?

>> And yet, the way that you call a C function is, apparently, undefined.
>
> It's implementation-defined. You have to read the compiler manual (or
> source code) to know what the sequence is. And different functions in
> the same code can have different calling conventions.
>
> Unless you have a CPU that actually enforces calling conventions.

So... how is it ever possible to statically link software?

>> It sounds like it shouldn't work.
>
> And indeed it doesn't. Try compiling one library with gcc and another
> with visual C and see if they link cleanly.

It's news to me that this /doesn't/ work.

I mean, if every compiler uses its own random calling convention, then 
how /the hell/ is it possible to write some C, link it against GMP, 
wxWidgets and the OS header files, and get a usable binary? You know, 
given that you have no idea which compiler these libraries are compiled 
with...

> Take a library off the mac and link it to a Windows-compiled main().

Yeah, well, one is going to be an ELF object, and the other will be a PE 
module. You won't even be able to find a linker program that understands 
both file formats. :-P That has nothing to do with whether the machine 
code within those files would work if you linked it together.

> For that matter, try compiling one program for x86 and the other for x64.

There's absolutely no reason to expect binaries for different 
architectures to work together.

I would, however, expect that on any given architecture, the C calling 
convention is always the same.

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> You know what? I'm just going to /buy/ the book.

  I'd recommend getting both of them. (Of course you could buy the
"Effective C++" first, and if you like it, buy "More Effective C++"
later.)

-- 
                                                          - Warp

Post a reply to this message

Le 2012-04-25 04:22, Invisible a écrit :
> On 25/04/2012 06:22 AM, Darren New wrote:
>> On 4/23/2012 1:31, Invisible wrote:
>>> Damn... I'm trying to think of something you can code without actually
>>> using recursion. Hmm. Well, I guess there must be /something/...
>>
>> Almost all business logic.
>
> I suppose I should consider myself lucky that I'm never going to be
> writing anything like that.

Why not?  Didn't you rewrite the code to compile your danse tournament 
rankings?  I know you only did it for yourself, but that was business 
logic, even if you weren't using WebSphere, J2EE, Weblogic or some big 
platform like that.

>
>>> And yet, the way that you call a C function is, apparently, undefined.
>>
>> It's implementation-defined. You have to read the compiler manual (or
>> source code) to know what the sequence is. And different functions in
>> the same code can have different calling conventions.
>>
>> Unless you have a CPU that actually enforces calling conventions.
>
> So... how is it ever possible to statically link software?
>

You have to take extra steps to make sure it works.  For example, back 
in the days of Windows 3.1, you had to use the Pascal calling convention 
for your functions in order to make sure that they could interact with 
other modules.  (Maybe it's still that way, I haven't touched a C 
program in 15 years.)

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

On 25/04/2012 12:59 PM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> You know what? I'm just going to /buy/ the book.
>
>    I'd recommend getting both of them. (Of course you could buy the
> "Effective C++" first, and if you like it, buy "More Effective C++"
> later.)

I think I can actually buy the pair for a lower price... (Amazon likes 
to do that.)

Gotta love how Amazon screwed me over, and I was all pissed about it, 
and now here I am giving them my money again.

Post a reply to this message