"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C8698CB.61C5ECAC@deming-os.org...
> Right, that's exactly what I did.  But it didn't work because I had to
implement
> the ThingChild constructor like this:
>
>     ThingChild::ThingChild() : Thing( new WorkerChild ) {...}
>
> And different compilers differ on whether that 'new WorkerChild' causes a
new
> object to be created for every ThingChild::ThingChild, or if the same WorkerChild (created once at runtime) is passed every time, or if the
whole
> thing was legal at all.

Really?  Which compiler(s)?  I've never seen one that couldn't handle this properly, though I've only used Borland, Watcom, VC++ 4 thru 7, GCC, and CodeWarrior.

Sean

"Walter" <walter@digitalmars.com> schrieb im Newsbeitrag news:a671bd$1rjq$1@digitaldaemon.com...
>
> "Immanuel Scholz" <digital-mars@kutzsche.net> wrote in message news:a65u2p$1bko$1@digitaldaemon.com...
> > Why does Walter do not like warnings?
>
> I should put this in the FAQ <g>.
>
> The trouble with warnings is they introduce ambiguities into whether a program successfully compiled or not. Many times I've gotten source code from someone, and it compiles with warnings. Are those warnings supposed
to
> be there or not? Who knows?
>
> Looking closer at each warning, it turns out to be the result of a problem in the design of the language. They can be eliminated by changing the design. For example, warnings about possible = in conditional:

What about "unused parameter"? If I read right, in D this is an error?
But often it is ignored, because you have to declare a parameter (as example
because you everride a virtual function) but do not use it:

InvisibleLine::draw (int x,int y, int color);

Does not need color, because it is invisible, but has to declare a third
parameter
to be correct overwrite the virtual draw.

Imi

"Immanuel Scholz" <digital-mars@kutzsche.net> wrote in message news:a67p5j$26ie$1@digitaldaemon.com...

> InvisibleLine::draw (int x,int y, int color);
>
> Does not need color, because it is invisible, but has to declare a third
> parameter
> to be correct overwrite the virtual draw.

The suggested form is:

    void draw(int x, int y, int /* unnamed */);

This makes it clear that the 3rd parameter is not used.
I believe that's what Stroustrup said about C++ as well.

"Sean L. Palmer" wrote:

> Really?  Which compiler(s)?  I've never seen one that couldn't handle this properly, though I've only used Borland, Watcom, VC++ 4 thru 7, GCC, and CodeWarrior.

I remember having a problem with this.  Frankly, I don't remember if the problem was that I found compilers with varying outputs, if I just couldn't find a spec, or what.  Maybe I'm nuts, and all compilers are the same...but if so, I don't have any idea what the spec is, and it's not obvious from the language construction.

So, bascially, I may be totally wrong about C++.  If so, I'm sorry.

I still think that calling super() inside the function body is a better way to
do things.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C879F11.7CBD799C@deming-os.org...
> "Sean L. Palmer" wrote:
>
> > Really?  Which compiler(s)?  I've never seen one that couldn't handle
this
> > properly, though I've only used Borland, Watcom, VC++ 4 thru 7, GCC, and CodeWarrior.
>
> I remember having a problem with this.  Frankly, I don't remember if the problem was that I found compilers with varying outputs, if I just
couldn't
> find a spec, or what.  Maybe I'm nuts, and all compilers are the
same...but if
> so, I don't have any idea what the spec is, and it's not obvious from the language construction.
>
> So, bascially, I may be totally wrong about C++.  If so, I'm sorry.
>
> I still think that calling super() inside the function body is a better
way to
> do things.

I agree... it's the way we used to do things back in the old days using Borland Pascal.  I think Delphi still works this way.

It makes a constructor more like an ordinary virtual function that's been overridden.  As with any such function, the overridden version gets control first, does what it has to do, (possibly) calls the inherited version, does any final work, then returns.  You always have to do before the call to inherited function what needs to be done before the inherited function is called, and afterward what needs done afterwards.  If you want to change its inputs you do it before, and if you want to change its outputs you do it after, usually.  But there's no hard and fast rule about it, you just do it in the way that works.  If it doesn't work you did it the wrong way.

I don't mind shooting myself in the foot once in a while... it keeps me awake.  I'd rather have a more flexible language than one that prevents me from being bad.  It's good to be bad sometimes.  ;)

Sean

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:a68c6n$2f91$1@digitaldaemon.com...

> I agree... it's the way we used to do things back in the old days using Borland Pascal.  I think Delphi still works this way.

Absolutely. AFAIK it doesn't even require the base constructor to be called (which is definitely not the best idea)!

"Pavel Minayev" <evilone@omen.ru> schrieb im Newsbeitrag news:a65ub0$1blo$1@digitaldaemon.com...
> In D, constants are always compile-time. That's one of its major
> differences from C++. As the result, constants turn out to
> be literals, or expressions involving literals and/or other
> constants. No memory is allocated for consts.

Isn't it a disadvantage to loose the type safety provided by declaring something const? What was the reason for this decission?


> The question is, how the program tells, in function init(), that vtable isn't yet initialized? Add a bit flag and perform an implicit check for each method call?

Err. Ok, I confuse "static-linkage" a bit with "vpt not completly build up".

Imi

"Immanuel Scholz" <digitals-mars@kutzsche.net> wrote in message news:a6a72b$q9c$1@digitaldaemon.com...

> Isn't it a disadvantage to loose the type safety provided by declaring something const? What was the reason for this decission?

I don't really see much reason in it. In C++, the most obvious reason for const would be const references (const Object& foo), to allow passing of temporaries created in the process of type conversions. Since there are no such things in D, the need for const is not high.

I'm sure Walter might add something to this... =)

"Pavel Minayev" <evilone@omen.ru> schrieb im Newsbeitrag news:a681do$2a37$1@digitaldaemon.com...
> "Immanuel Scholz" <digital-mars@kutzsche.net> wrote in message news:a67p5j$26ie$1@digitaldaemon.com...
>
> > InvisibleLine::draw (int x,int y, int color);
> >
> > Does not need color, because it is invisible, but has to declare a third
> > parameter
> > to be correct overwrite the virtual draw.
>
> The suggested form is:
>
>     void draw(int x, int y, int /* unnamed */);
>
> This makes it clear that the 3rd parameter is not used.
> I believe that's what Stroustrup said about C++ as well.

oh. I thought unnamed parameter were not allowed in D?
Great, now I am absolutly satisfied (at least with "no warnings" ;)

"Immanuel Scholz" <digital-mars@kutzsche.net> wrote in message news:a6b1b3$14ro$1@digitaldaemon.com...

> oh. I thought unnamed parameter were not allowed in D?

For some reason, they are currently forbidden in function
definitions (but allowed in declarations).

Following Walter's logic, to prevent the "unused parameter" warning, unnamed parameters must be allowed everywhere...