New release of the C Containers Library (CCL)

[Jon]

You might be right, but if you don't give me a reference, I'm not
going to believe you.

I don't care if you believe me or not. "No skin off my nose".

 

[Jon]

So what does that gain you?

What if there was no "using" directive in C++? Could you solve the
problem without using virtual derivation?

 

[MartinBroadhurst]

What if there was no "using" directive in C++? Could you solve the
problem without using virtual derivation?

I've no idea, but how does that justify your assertion that you *must*
use virtual inheritance when you inherit from more than one ABC?

class IDispatch : virtual public IUnknown;

It isn't written that way, and yet a component with dual interfaces is
bound to inherit IUnknown more than once.

The component just implements QueryInterface, AddRef and Release from
IUnknown as if it had been inherited once; there isn't a problem.

Martin

 

[Jon]

I've no idea, but how does that justify your assertion that you *must*
use virtual inheritance when you inherit from more than one ABC?

Show me where I said that.

That code (whittled down to bare nothingness to illustrate the problem)
is *still* in a library I use. I didn't realize until today that "using"
would "fix" the issue (but I don't want to drag namespaces into that code
so virtually derived it will stay), but that code is circa 199X and where
I was discussing from. That particular scenario stuck in my mind.

[snipped COM stuff]

 

[MartinBroadhurst]

Show me where I said that.

I'm not going through it again looking for it. You know perfectly well
you have said that more than once.

That code (whittled down to bare nothingness to illustrate the problem)
is *still* in a library I use. I didn't realize until today that "using"
would "fix" the issue (but I don't want to drag namespaces into that code
so virtually derived it will stay), but that code is circa 199X and where
I was discussing from. That particular scenario stuck in my mind.

You didn't consider this?:

void DoItD(D& obj){ dynamic_cast<B&>(obj).doit(); }

Martin

 

[Jon]

I'm not going through it again looking for it. You know perfectly well
you have said that more than once.


You didn't consider this?:

void DoItD(D& obj){ dynamic_cast<B&>(obj).doit(); }

Enabling RTTI for the problem is "too big a pill to swallow". Also, and
moreso, exceptions would have to be enabled also, so now it's a *really
big* pill. Not to mention that it seems kludgy.

 

[MartinBroadhurst]

Enabling RTTI for the problem is "too big a pill to swallow". Also, and
moreso, exceptions would have to be enabled also, so now it's a *really
big* pill. Not to mention that it seems kludgy.

void DoItD(D& obj){ ((B&)obj).doit(); }

....then. It doesn't use RTTI or throw.

It does kind of look kludgy, but it puts responsibility where it
belongs, rather than dispersing it all over the place.

Martin

 

[Jon]

void DoItD(D& obj){ ((B&)obj).doit(); }

...then. It doesn't use RTTI or throw.

Well, no (and this reason is applies to the 'dynamic_cast' version also)
because DoItD is not a part of the code, the classes A through E are and
the Ds get used all over the place so imagine how ugly the code would be.

It does kind of look kludgy, but it puts responsibility where it
belongs, rather than dispersing it all over the place.

Well I don't think "putting responsibillity where it belongs" applies in
this case (even before I clued-you-in on the actual usage of classes A
through E).

 

[MartinBroadhurst]

Well, no (and this reason is applies to the 'dynamic_cast' version also)
because DoItD is not a part of the code, the classes A through E are and
the Ds get used all over the place so imagine how ugly the code would be.

If you have functions that use Ds all over the place, you can just
have a method in D, or a function taking a D outside it, that does the
cast and calls doit.
All the D functions then just work through this.

Well I don't think "putting responsibillity where it belongs" applies in
this case (even before I clued-you-in on the actual usage of classes A
through E).

I don't think that base classes should know or care about how they are
combined with other base classes. This is why I think that virtual
inheritance is fundamentally unsound.

Martin

 

[Keith Thompson]

Le 08/11/10 10:41, MartinBroadhurst a écrit :

He has NO reasons, that is why he is "obscure". Besides, this guy is not
interested in discussing rationally but insulting other people of "wankers".

Just another troll in this group.

I agree. I've stopped replying to anything "Jon" posts; it works
well for me, and probably improves the overall signal-to-noise
ratio of the newsgroup. Please consider doing the same.

 

[Keith Thompson]

My contention was that this is not the case, since the main problem is
common to C++, C# and Java (base classes or interfaces with common
names), and has a similar solution in all three (in C++ and C#,
disambiguate through fully qualified names, in C++ again and in Java,
implement one method that overrides both base class (interface)
methods).

This no longer has anything to do with C. If you must engage in
a meaningless discussion with "Jon", please do it where it's topical.

 

[Jon]

If you have functions that use Ds all over the place, you can just
have a method in D,

No, D is an interface (pure ABC).

or a function taking a D outside it, that does the
cast and calls doit.
All the D functions then just work through this.


I don't think that base classes should know or care about how they are
combined with other base classes. This is why I think that virtual
inheritance is fundamentally unsound.

Well I don't disagree. That's the language though.

 

[Jon]

This no longer has anything to do with C. If you must engage in
a meaningless discussion with "Jon", please do it where it's topical.

As if your ranting/personal attacks are "on topic".

 

[Jon]

I agree. I've stopped replying to anything "Jon" posts; it works
well for me, and probably improves the overall signal-to-noise
ratio of the newsgroup. Please consider doing the same.

Consider going back under the rock you crawled out from.

 

[Kenny McCormack]

This no longer has anything to do with C. If you must engage in
a meaningless discussion with "Jon", please do it where it's topical.

Are meaningless discussions topical anywhere?

 

[Kenny McCormack]

Who the hell are you?

Generally, he is:

http://redwing.hutman.net/~mreed/warriorshtm/android.htm

But today, he's also playing:

http://redwing.hutman.net/~mreed/warriorshtm/admin.htm

It is in his duly appointed role as admin, that he makes these
pronouncements.

If you dont like it then ignore the thread or killfile the posters.

It is related to C and is totally on topic,

Some people dont like living in a box. Grow up.

This is Kiki's sandbox. He's in control. It's his whole life.
You know this by now.

 

[Ian Collins]

I think your brain is confused between POD types and concrete classes.

He is, very much so.

if this discussion were to take place on c.l.c++ (where it probably
belongs) he would quickly be put right.

 

[Seebs]

He has NO reasons, that is why he is "obscure". Besides, this guy is not
interested in discussing rationally but insulting other people of "wankers".

Just another troll in this group.

Just as a data point: I frequently feel that you are being unfair to
people when you accuse them of trolling. In this case, however, I fully
endorse your evaluation.

I recommend killfiling our recent series of new trolls, they're
uninteresting.

-s

 

[Jon]

(Ian Collins invited this subthread topic into comp.lang.c++, so I added
it to the list)

He is, very much so.

if this discussion were to take place on c.l.c++ (where it probably
belongs) he would quickly be put right.

So you both don't know what a POD is either huh. The web is your friend.
Look them both up unless you wanna keep misunderstanding the concepts and
potentially cause others to "learn" the incorrect things.

 

[MartinBroadhurst]

So you both don't know what a POD is either huh. The web is your friend.
Look them both up unless you wanna keep misunderstanding the concepts and
potentially cause others to "learn" the incorrect things.- Hide quoted text

I do know what a POD type is, and I know what a concrete class is as
well. Your definition contains elements of both, but is neither.

Martin