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

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