«

Le 01/11/10 12:26, MartinBroadhurst a écrit :
> On 1 Nov, 11:22, jacob navia<ja...@spamsink.net> wrote:
>>
>> But in C++ you cannot use an abstract class as a parameter type, a
>> function return type, or the type of an explicit conversion
>>
>
> You would use a *pointer* to an abstract base class, just as we're
> using pointers here in C.
>
> Martin

Well, then it corresponds exactly to an abstract structure in C.
(struct foo

Do an abstract class force a performance penalty in C++?

When I call an abstract class, does the generated code have more to do?

Thanks for your contribution.

jacob

On 1 Nov, 11:40, jacob navia <ja...@spamsink.net> wrote:
>
> Well, then it corresponds exactly to an abstract structure in C.
> (struct foo
>
> Do an abstract class force a performance penalty in C++?
>

Yes, because there is an extra level of indirection. When a method is
called on a pointer to an abstract base class, the vtable is retrieved
from the address point of the object, and then the derived class
method pointer is retrieved from the vtable.

> When I call an abstract class, does the generated code have more to do?
>

Yes, for the same reason. In addition, there is some overhead in
constructing objects with virtual functions because the vtable needs
to be set up.

Martin

Le 01/11/10 12:46, MartinBroadhurst a écrit :
> On 1 Nov, 11:40, jacob navia<ja...@spamsink.net> wrote:
>>
>> Well, then it corresponds exactly to an abstract structure in C.
>> (struct foo
>>
>> Do an abstract class force a performance penalty in C++?
>>
>
> Yes, because there is an extra level of indirection. When a method is
> called on a pointer to an abstract base class, the vtable is retrieved
> from the address point of the object, and then the derived class
> method pointer is retrieved from the vtable.

That is exactly what I do:

For instance to call the generic function "newIterator":

Iterator *newIterator(GenericContainer *gen)
{
return gen->VTable->newIterator(gen);
}

I call the vtable of the object. Since the vtables of all
containers contain the function "newIterator" at the same position,
this works.

I do it with ONE indirection, and not two, as you can see.

OK, then if I am at the same level of C++ it is OK.

>
>> When I call an abstract class, does the generated code have more to do?
>>
>
> Yes, for the same reason. In addition, there is some overhead in
> constructing objects with virtual functions because the vtable needs
> to be set up.

Since I do only one indirection, this is not necessary. Derived objects
are just the same as before.

The only thing that the derived object needs to ensure is that all
functions that are part of the interface are at the same position in
their vtables.

After that, there are no constraints, in fact, the existence of the
abstract class is completely transparent to them.

What is relly nice when working in C is the absolute freedom to do as
you want. In this case, not having ANY object oriented framework is a
bonus in some ways since you can lay out your object as you want.

jacob

jacob navia <> writes:

> Le 01/11/10 11:49, Malcolm McLean a écrit :
>> On Nov 1, 12:41 pm, jacob navia<ja...@spamsink.net> wrote:
>>>
>>> I do not know if you can do this in C++. In Objective C you can.
>>>
>> In C++ you make "Container" a virtual base class, that is to say, you
>> give it pure virtual functions set to " = 0 ". The functions must be
>> overridden in derived classes that are instantiated.
>
> Interesting...
>
> In my implementation, the generic functions aren't virtual really
> since they call the container specific function. This costs an
> indirection and an indirect function call in C.
>
> I would be interested to know what the cost of virtual base classes is
> in C++ (if any)

I think you're going to be end up with the wrong view of C++ if you take
your information from this group.

I am not a C++ expert, but I believe Malcolm is wrong about how "you
make" containers in C++. Using inheritance and virtual base classes is,
I think, regarded as how *not* to do it. The STL uses template classes
and though inheritance is used (particularly for types with a lot of
shared behaviour like iterators) there is no ultimate container virtual
base class.

Of course, you have no reason to believe me rather than Malcolm. A quick
post in comp.lang.c++ would get you highly trustworthy information about
C++'s standard containers.

<snip>
--
Ben.

On 1 Nov, 12:28, jacob navia <ja...@spamsink.net> wrote:
>
> That is exactly what I do:
>
> For instance to call the generic function "newIterator":
>
> Iterator *newIterator(GenericContainer *gen)
> {
> * * *return gen->VTable->newIterator(gen);
>
> }
>
> I call the vtable of the object. Since the vtables of all
> containers contain the function "newIterator" at the same position,
> this works.
>

If you want to know how C++ abstract base classes are actually laid
out in memory, get hold of the Windows SDK and look in the Include
directory for a header file that has a corresponding .idl file with
the same name, say oledb.h. Search the file for the string "C style
interface". What you will see is a vtable, and a C struct containing
it, that have been laid out to be identical to a C++ abstract base
class. This is provided so that C programmers can write COM
components.

There is also an article about COM programming in C on MSDN that I
found quite informative here:

http://msdn.microsoft.com/en-us/library/ms809982.aspx

Martin

On 1 Nov, 12:46, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>
> I am not a C++ expert, but I believe Malcolm is wrong about how "you
> make" containers in C++. *Using inheritance and virtual base classes is,
> I think, regarded as how *not* to do it. *The STL uses template classes
> and though inheritance is used (particularly for types with a lot of
> shared behaviour like iterators) there is no ultimate container virtual
> base class.
>

The STL has a concept hierarchy, while Java and the .NET framework opt
for a class (and interface) hierarchy.
I think in both cases the hierarchy is more about classification than
substitutability.

Martin

"jacob navia" <> wrote in message
news:ialt7g$t95$...
> Le 31/10/10 22:48, BartC a écrit :
>> "jacob navia" <> wrote in message

>>> static int Append(SequentialContainer *g1,SequentialContainer *g2)

>> That looks more like a 'Concatenate' function.
>>
>> 'Append' would add the second argument as a single extra element at the
>> end of g1.

> I run a search about append in /usr/share/man and the only place where it
> is used is in curl_slist_append, that adds a string to a list of strings.
> That supports your idea.
>
> The other is that "strcat" (probably from string conCATenate) does the
> equivalent for strings

'Append' and 'Concatenate' are sometimes used interchangeably (and for
strings, they do the same thing), but there is a subtle difference. This is
how I use them:

(10,20,30) concat (40,50,60) => (10,20,30,40,50,60)
(10,20,30) append (40,50,60) => (10,20,30,(40,50,60))

(10,20,30) concat 40 => (10,20,30,40)
(10,20,30) append 40 => (10,20,30,40)

In a general language, both should be available. In your C library where
lists likely have homogeneous element types, appending a list probably isn't
too useful, while you seem to be using 'Add' to append a single item. So
it's just a question of naming.

(In Python, "+" does the "concat" operation I've described for two lists,
while "append" does the equivalent of my "append", although as an in-place
modifier rather than a general operator).

--
Bartc

On 11/ 2/10 01:46 AM, Ben Bacarisse wrote:
> jacob navia<> writes:
>
>> Le 01/11/10 11:49, Malcolm McLean a écrit :
>>> On Nov 1, 12:41 pm, jacob navia<ja...@spamsink.net> wrote:
>>>>
>>>> I do not know if you can do this in C++. In Objective C you can.
>>>>
>>> In C++ you make "Container" a virtual base class, that is to say, you
>>> give it pure virtual functions set to " = 0 ". The functions must be
>>> overridden in derived classes that are instantiated.
>>
>> Interesting...
>>
>> In my implementation, the generic functions aren't virtual really
>> since they call the container specific function. This costs an
>> indirection and an indirect function call in C.
>>
>> I would be interested to know what the cost of virtual base classes is
>> in C++ (if any)
>
> I think you're going to be end up with the wrong view of C++ if you take
> your information from this group.
>
> I am not a C++ expert, but I believe Malcolm is wrong about how "you
> make" containers in C++. Using inheritance and virtual base classes is,
> I think, regarded as how *not* to do it. The STL uses template classes
> and though inheritance is used (particularly for types with a lot of
> shared behaviour like iterators) there is no ultimate container virtual
> base class.

That's a fair summary.

The cost of the C++ approach is it requires some form of generics
(templates) and the benefit is performance. While removing indirect
function calls only contributes a small performance gain, the ability to
optimise away those calls can make significant performance gains.

--
Ian Collins

jacob navia wrote:

> For instance to call the generic function "newIterator":
>
> Iterator *newIterator(GenericContainer *gen)
> {
> return gen->VTable->newIterator(gen);
> }
>
> You see?
>
> If you write
> Iterator *n = iList.newIterator(container);
>
> You call directly the right function, but then you have to know
> that your container is a list.
>
> It costs a function call + indirection + indirect function call.

It costs, apparently: a function call + indirection + indirection +
function call.

Your "notation" makes it seem like it is twice removed whereas it
actually is thrice so.

> I haven't found any way to avoid that extra call.

#define newIterator(generic_cont)
generic_cont->VTable->newIterator(generic_cont)

Macros: the "poor man's" inline function.

Ben Bacarisse wrote:
> jacob navia <> writes:
>
>> Le 01/11/10 11:49, Malcolm McLean a écrit :
>>> On Nov 1, 12:41 pm, jacob navia<ja...@spamsink.net> wrote:
>>>>
>>>> I do not know if you can do this in C++. In Objective C you can.
>>>>
>>> In C++ you make "Container" a virtual base class, that is to say,
>>> you give it pure virtual functions set to " = 0 ". The functions
>>> must be overridden in derived classes that are instantiated.
>>
>> Interesting...
>>
>> In my implementation, the generic functions aren't virtual really
>> since they call the container specific function. This costs an
>> indirection and an indirect function call in C.
>>
>> I would be interested to know what the cost of virtual base classes
>> is in C++ (if any)
>
> I think you're going to be end up with the wrong view of C++ if you
> take your information from this group.
>
> I am not a C++ expert, but I believe Malcolm is wrong about how "you
> make" containers in C++. Using inheritance and virtual base classes
> is, I think, regarded as how *not* to do it. The STL uses template
> classes and though inheritance is used (particularly for types with a
> lot of shared behaviour like iterators) there is no ultimate
> container virtual base class.

Maybe the C++ people rejected the design Jacob is proposing for a good
reason ya think? It's not good enough for C++ but good enough for "second
class" C?