New release of the C Containers Library (CCL)

[MartinBroadhurst]

MartinBroadhurst wrote:
MartinBroadhurst wrote:
[...] and this (from another
thread):
Trust me, you don't want to. It is "wrong" to do that. You may have
to reinvent your containers a few times before you realize it
though.
...which is just obscure.
It is for you now, but someday, if you evolve container libraries
over time and do the required "homework", you'll understand why I
said that. (You're welcome).

No, I meant it is obscure because you haven't given your reasons.

(I can't resist this opportunity

"Heeeeeeere's yer sign"!

I don't know what that means.

Martin

 

[jacob navia]

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

MartinBroadhurst wrote:
MartinBroadhurst wrote:
[...] and this (from another
thread):

Trust me, you don't want to. It is "wrong" to do that. You may have
to reinvent your containers a few times before you realize it
though.

...which is just obscure.

It is for you now, but someday, if you evolve container libraries
over time and do the required "homework", you'll understand why I
said that. (You're welcome).

No, I meant it is obscure because you haven't given your reasons.

(I can't resist this opportunity

"Heeeeeeere's yer sign"!

I don't know what that means.

Martin

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.

jacob

 

[Jon]

MartinBroadhurst wrote:
MartinBroadhurst wrote:
[...] and this (from another
thread):

Trust me, you don't want to. It is "wrong" to do that. You may
have to reinvent your containers a few times before you realize
it though.

...which is just obscure.

It is for you now, but someday, if you evolve container libraries
over time and do the required "homework", you'll understand why I
said that. (You're welcome).

No, I meant it is obscure because you haven't given your reasons.

(I can't resist this opportunity

"Heeeeeeere's yer sign"!

I don't know what that means.

http://www.snopes.com/humor/jokes/heresign.asp

Read the whole page and let me know if you think it is funny. (Read, I'm
laughing with you, not at you).

"Ziiiiiiing!"

 

[MartinBroadhurst]

That implies too much to be correct.

What does it imply?

(And aside, your use of  "concrete"
is java-like or something rather than C++-like).

"Concrete class" is fairly common parlance in C++. It's used in the
FAQ a few times:

http://www.google.co.uk/webhp?hl=en...=&aql=&oq=&gs_rfai=&pbx=1&fp=94ec41b61855a1f3

Martin

 

[Jon]

It's almost exactly the same solution as you would use in Java or C#
if you are implementing multiple interfaces that share a common
method.

Well virtual derivation is in C++, so you don't have to do that.

This came about because of:



So he seemed to be implying that multiple inheritance in C++ is more
problematical than implementing multiple interfaces in Java.

It is, as it *practically* "requires" virtual derivation, even with pure
ABCs. (Not to mention, again, what a nightmare it is for the compiler
developer).

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

I agree that all 3 languages leave something to be desired (not to worry
though, I'm developing my own) but there is no ambiguity in Java when
deriving from multiple interfaces with the same method signature so no
need to do anything.

 

[Jon]

What does it imply?

It implies that use of (pure) ABCs is somehow void of the MI issues. It
implies that virtual derivation's purpose is solely when using classes
that are not pure ABC classses.

"Concrete class" is fairly common parlance in C++. It's used in the
FAQ a few times:

http://www.google.co.uk/webhp?hl=en...=&aql=&oq=&gs_rfai=&pbx=1&fp=94ec41b61855a1f3

Just because you found other incorrect usages of the term doesn't make it
correct. A "concrete" class in C++ is one who's object instances behave
like built-in types. Such a class must include the following special
member functions: a default constructor, a copy constructor, a
copy-assignment operator, a destructor.

 

[Jon]

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

MartinBroadhurst wrote:
MartinBroadhurst wrote:
MartinBroadhurst wrote:
[...] and this (from another
thread):

Trust me, you don't want to. It is "wrong" to do that. You may
have to reinvent your containers a few times before you realize
it though.

...which is just obscure.

It is for you now, but someday, if you evolve container libraries
over time and do the required "homework", you'll understand why I
said that. (You're welcome).

No, I meant it is obscure because you haven't given your reasons.

(I can't resist this opportunity

"Heeeeeeere's yer sign"!

I don't know what that means.

Martin

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.

If you are crabby, maybe you should go to bed. Maybe all that wanking is
making you irritable.

 

[MartinBroadhurst]

Well virtual derivation is in C++, so you don't have to do that.

But I don't want to use virtual derivation, and I don't have to.
That's the whole point.

It is, as it *practically* "requires" virtual derivation, even with pure
ABCs. (Not to mention, again, what a nightmare it is for the compiler
developer).

But it doesn't. You only *need* virtual derivation when you are
inheriting data members or method implementations from multiple
concrete classes that share a common ancestor, and you want to avoid
having 2 copies of them. The simple solution to this is not to derive
from multiple concrete classes. This is what Java and C# forbid, by
only allowing multiple interfaces, not multiple base classes.

I agree that all 3 languages leave something to be desired (not to worry
though, I'm developing my own) but there is no ambiguity in Java when
deriving from multiple interfaces with the same method signature so no
need to do anything.

Precisely, no need to do anything apart from implement the method
once, and there's no need to do anything in C++ apart from implement
the method once if you don't mind the same method being called by
pointers to either base class, as my first code sample showed.

Martin

 

[MartinBroadhurst]

It implies that use of (pure) ABCs is somehow void of the MI issues. It
implies that virtual derivation's purpose is solely when using classes
that are not pure ABC classses.

That is precisely virtual derivation's purpose.

Just because you found other incorrect usages of the term doesn't make it
correct. A "concrete" class in C++ is one who's object instances behave
like built-in types. Such a class must include the following special
member functions: a default constructor, a copy constructor, a
copy-assignment operator, a destructor.

Where did you get that from?

Martin

 

[Jon]

But I don't want to use virtual derivation, and I don't have to.
That's the whole point.

No, the whole point is that what you implied is incorrect.

But it doesn't. You only *need* virtual derivation when you are
inheriting data members or method implementations from multiple
concrete classes that share a common ancestor, and you want to avoid
having 2 copies of them. The simple solution to this is not to derive
from multiple concrete classes. This is what Java and C# forbid, by
only allowing multiple interfaces, not multiple base classes.

As a practical matter, you *do* "need" it, notwithstanding hacking around
it.

Precisely, no need to do anything apart from implement the method
once, and there's no need to do anything in C++ apart from implement
the method once if you don't mind the same method being called by
pointers to either base class, as my first code sample showed.

"Show me".

 

[Jon]

That is precisely virtual derivation's purpose.

If you mean "solely" with your usage of "precisely", you are wrong, which
is what you implied with your original passage.

Where did you get that from?

My brain. Research it and you will see.

 

[MartinBroadhurst]

No, the whole point is that what you implied is incorrect.

I implied that multiple inheritance from ABCs in C++ is no more
difficult than implementing multiple interfaces in C# or Java.
This is not incorrect. My first code example showed how you can not
care that 2 ABCs share a common method. My second one showed how you
can disambiguate if you want to.

As a practical matter, you *do* "need" it, notwithstanding hacking around
it.

Why do you need it? How is just implementing a method once, or twice,
hacking around it?

"Show me".

I don't know what this means.

Martin

 

[MartinBroadhurst]

If you mean "solely" with your usage of "precisely", you are wrong, which
is what you implied with your original passage.

Just tell me why I would want to use virtual inheritance with ABCs.

My brain. Research it and you will see

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

Martin

 

[Jon]

I implied that multiple inheritance from ABCs in C++ is no more
difficult than implementing multiple interfaces in C# or Java.
This is not incorrect. My first code example showed how you can not
care that 2 ABCs share a common method. My second one showed how you
can disambiguate if you want to.


Why do you need it? How is just implementing a method once, or twice,
hacking around it?


I don't know what this means.

It means produce an example of "not needing to do anything" in C++.

(Aside from this subthread being belaboring, note my OP:

">> What C++ forgot and Java remembered was the "interface". You can
At 2 levels: The language implementation level (very hard/complex) and
the language usage level (inelegant/kludgy)." )

 

[MartinBroadhurst]

It means produce an example of  "not needing to do anything" in C++.

That's what I just did.

I agree that all 3 languages leave something to be desired (not to worry
though, I'm developing my own) but there is no ambiguity in Java when
deriving from multiple interfaces with the same method signature so no
need to do anything.

There's no need to do anything in Java, apart from implement that
method.

And there's no need to do anything in C++, apart from implement that
method.

If you *want to*, you can implement it twice with fully qualified
names.

But you don't have to.

">> What C++ forgot and Java remembered was the "interface". You can


At 2 levels: The language implementation level (very hard/complex) and
the language usage level (inelegant/kludgy)." )- Hide quoted text -

And the implementation and usage of the C# and Java languages are
simpler and more elegant in this respect?

Martin

 

[Jon]

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

Nope. What I stated is *the* C++ concept of "concrete class". All other
uses are colloquial *at best*, but I consider them incorrect (because
they are).

 

[Jon]

Just tell me why I would want to use virtual inheritance with ABCs.

//#define USE_VIRTUAL_DERIVATION
//#define USE_USING

#if defined USE_VIRTUAL_DERIVATION
#define VIRTUAL virtual
#else
#define VIRTUAL
#endif

struct A
{
virtual ~A(){}
virtual void doit()=0;
};

struct B: VIRTUAL A
{
virtual ~B(){}
};

struct C: VIRTUAL A
{
virtual ~C(){}
};

struct D: VIRTUAL B, VIRTUAL C
{
virtual ~D(){}

#if defined USE_USING
using B::doit;
using C::doit;
#endif
};

struct E: VIRTUAL D
{
virtual ~E(){}
virtual void doit(){}
};

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

int __cdecl main()
{
E e;
DoItD(e);
return 0;
}

 

[MartinBroadhurst]

Nope. What I stated is *the* C++ concept of "concrete class". All other
uses are colloquial *at best*, but I consider them incorrect (because
they are).

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

Martin

 

[Jon]

And the implementation and usage of the C# and Java languages are
simpler and more elegant in this respect?

I see no remark in my passage above about C# or Java.

 

[MartinBroadhurst]

//#define USE_VIRTUAL_DERIVATION
//#define USE_USING

#if defined USE_VIRTUAL_DERIVATION
#define VIRTUAL virtual
#else
#define VIRTUAL
#endif

struct A
{
   virtual ~A(){}
   virtual void doit()=0;

};

struct B: VIRTUAL A
{
   virtual ~B(){}

};

struct C: VIRTUAL A
{
   virtual ~C(){}

};

struct D: VIRTUAL B, VIRTUAL C
{
   virtual ~D(){}

#if defined USE_USING
   using B::doit;
   using C::doit;
#endif

};

struct E: VIRTUAL D
{
   virtual ~E(){}
   virtual void doit(){}

};

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

int __cdecl main()
{
   E e;
   DoItD(e);
   return 0;



}

So what does that gain you?

Martin