New release of the C Containers Library (CCL)

[jacob navia]

Le 07/11/10 06:24, Jon a écrit :

Wouldn't it be quite "demeaning" for the comittee to standardize
*decidedly* implementation-level things in some kind of clever hack?

You do not know what you are talking about. You haven't read my
proposal, so you can't possible know what is all about.

I am proposing a standard interface for a container library, that has
nothing about concrete implementations. I have provided a SAMPLE
implementation to prove that it CAN be implemented, that is all.

"C

the *clever* language"? It sounds like modifying that old junker car and
taking it to the dragstrip to have fun with because it's not the daily
driver and it doesn't matter.

Your prejudices against C are known now. Please stop using this forum if
you think C is a bad language etc. Be consequent.

C is an "old junker car". Then there is no sense in trying to improve
it, etc.

There really is no way to start
standardizing clever hacks without changing the face and identity of C.
There really isn't. `

WHAT "clever hacks"? You dont' know what I am rpoposing anyway.

It's fine to do things like that outside of the
standard but I really don't see C morphing to that kind of new
exististence and giving up its place as a real programming language.

Ramblings and ramblings. Go on.

It has to stay "as it is" because it *is* what it is.

Thanks. I think your logic is completely clear by now.


[snip rest of drivel ]

 

[MartinBroadhurst]

Virtual derivation from C++ ABCs is still required when faced with "the
diamond of death" (at least with VC++ I know that it does).- Hide quoted text -

No it isn't. You just fully qualify the names in the derived class.

Martin

 

[MartinBroadhurst]

MS COM objects != C++ objects! MS had to invent COM because it was
concerned with cross-language OO. COM is at a much higher level than
language implementation. Apples and oranges.- Hide quoted text -

The COM binary standard is based on the structure of objects of
classes with virtual functions as implemented by Microsoft compilers.

Martin

 

[MartinBroadhurst]

Virtual derivation from C++ ABCs is still required when faced with "the
diamond of death" (at least with VC++ I know that it does).

#include <iostream>

class A
{
public:
virtual void f() = 0;
};

class I1 : public A
{
public:
virtual void f() = 0;
};

class I2 : public A
{
public:
virtual void f() = 0;
};

class C : public I1, public I2
{
public:
virtual void f()
{
std::cout <<"f()" << std::endl;
}
};

int main()
{
C* c = new C();
I1* i1 = c;
i1->f();
I2* i2 = c;
i2->f();
}

 

[MartinBroadhurst]

Virtual derivation from C++ ABCs is still required when faced with "the
diamond of death" (at least with VC++ I know that it does).

#include <iostream>

class A
{
public:
virtual void f() = 0;
};

class I1 : public A
{
public:
virtual void f() = 0;
};

class I2 : public A
{
public:
virtual void f() = 0;
};

class C : public I1, public I2
{
public:
virtual void I1::f()
{
std::cout <<"I1::f()" << std::endl;
}
virtual void I2::f()
{
std::cout <<"I2::f()" << std::endl;
}
};

int main()
{
C* c = new C();
I1* i1 = c;
i1->f();
I2* i2 = c;
i2->f();
}

 

[MartinBroadhurst]

Virtual derivation from C++ ABCs is still required when faced with "the
diamond of death" (at least with VC++ I know that it does).

To recap my last 2 posts (which are *not* the same):

When you have the "Dreaded Diamond of Death", you have 2 options:

1. Implement the common method in terms of one method, which will
apply to both parent classes
2. Implement the common method for each parent class individually, by
fully qualifying the method name

Neither option requires the use of virtual inheritance.

Martin

 

[Mark Wooding]

What C++ forgot and Java remembered was the "interface". You can
achieve nearly the same thing with multiple inheritance

This isn't right. Java interfaces are simply hamstrung mixins,
equivalent to a C++ class all of whose members are pure virtual
functions.

but that leads into all sorts of difficulties.

Only because C++ has (a) a hopelessly deficient approach to method
combination, and (b) its demented notion of repeated inheritance. Less
primitive object systems don't have these problems and cope with
multiple inheritance just fine; but C++ has given the idea a bad name.

(Not completely off-topic. I have a spare time project to implement a
non-broken object system for C. It does CLOS/Dylan-style superclass
linearization and method combinations, but, alas, only single dispatch.)

-- [mdw]

 

[MartinBroadhurst]

C++ is much much broader in scope than a single library (STL) or the C++
standard. There's that "little" think called *programming* that seems to
escape "language lawyers" quite regularly. You should have said "STL
approach" instead of "C++ approach".


And, "of course", since Lamborghini's are available, SUVs are irrelevant.

http://www.lamborghinihouston.com/http://automobiles.honda.com/cr-v/price..aspx- Hide quoted text -

- Show quoted text -

Greengrocer's, however, are relevant.

Martin

 

[MartinBroadhurst]

Now you know why I have chosen to develop my own language. It's much
easier. (And the result isn't kludgy).

I think that you should try to learn at least one language well before
you condemn them all and decide to write your own.

Martin

 

[Jon]

Le 07/11/10 06:24, Jon a écrit :

Wouldn't it be quite "demeaning" for the comittee to standardize
*decidedly* implementation-level things in some kind of clever hack?

You do not know what you are talking about. You haven't read my
proposal, so you can't possible know what is all about.

I am proposing a standard interface for a container library, that has
nothing about concrete implementations. I have provided a SAMPLE
implementation to prove that it CAN be implemented, that is all.

"C

the *clever* language"? It sounds like modifying that old junker car
and taking it to the dragstrip to have fun with because it's not the
daily driver and it doesn't matter.

Your prejudices against C are known now. Please stop using this forum
if you think C is a bad language etc. Be consequent.

C is an "old junker car". Then there is no sense in trying to improve
it, etc.

There really is no way to start
standardizing clever hacks without changing the face and identity of
C. There really isn't. `

WHAT "clever hacks"? You dont' know what I am rpoposing anyway.

It's fine to do things like that outside of the
standard but I really don't see C morphing to that kind of new
exististence and giving up its place as a real programming language.

Ramblings and ramblings. Go on.

It has to stay "as it is" because it *is* what it is.

Thanks. I think your logic is completely clear by now.


[snip rest of drivel ]

You seem quite autistic. There is help for that FYI.

 

[Jon]

The COM binary standard is based on the structure of objects of
classes with virtual functions as implemented by Microsoft compilers.

What did I just say?(!)

 

[Jon]

I think that you should try to learn at least one language well before
you condemn them all and decide to write your own.

I think you should stick with masturbation.

 

[Jon]

No it isn't. You just fully qualify the names in the derived class.

You suggested that the issue was moot, which of course, it is not.

(Aside, I meant pure ABC's but that is unrelated to this post).

 

[MartinBroadhurst]

You suggested that the issue was moot, which of course, it is not.

No, I said that it was no more difficult than implementing multiple
interfaces that share common names in Java or C#.

(Aside, I meant pure ABC's but that is unrelated to this post).

So did I.

Martin

 

[MartinBroadhurst]

I think you should stick with masturbation.

If you were to refute anything I have actually said with arguments
that were true, I would credit you straight away.

As it is, you tend to come out with things like this:

Virtual derivation from C++ ABCs is still required when faced with "the
diamond of death" (at least with VC++ I know that it does).

....which is factually incorrect, this:

You suggested that the issue was moot, which of course, it is not.

....which is a misrepresentation of what I said, 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.

Martin

 

[Jon]

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

 

[MartinBroadhurst]

MartinBroadhurst wrote:
On Nov 7, 5:59 am, "Jon" <[email protected]> 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.

Martin

 

[Jon]

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

 

[Jon]

That implies too much to be correct. (And aside, your use of "concrete"
is java-like or something rather than C++-like).

#include <iostream>

class A
{
public:
virtual void f() = 0;
};

class I1 : public A
{
public:
virtual void f() = 0;
};

class I2 : public A
{
public:
virtual void f() = 0;
};

class C : public I1, public I2
{
public:
virtual void I1::f()
{
std::cout <<"I1::f()" << std::endl;
}
virtual void I2::f()
{
std::cout <<"I2::f()" << std::endl;
}
};

int main()
{
C* c = new C();
I1* i1 = c;
i1->f();
I2* i2 = c;
i2->f();
}

You call that a "solution"? I should have typed what I meant:
"practically required".

 

[MartinBroadhurst]

That implies too much to be correct. (And aside, your use of  "concrete"
is java-like or something rather than C++-like).














You call that a "solution"? I should have typed what I meant:
"practically required".- Hide quoted text -

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.

This came about because of:

What C++ forgot and Java remembered was the "interface". You can
achieve nearly the same thing with multiple inheritance, but that
leads into all sorts of difficulties.

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

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

Martin