In article <7ih6si$8fu@abyss.West.Sun.COM>,
  stanley@West.Sun.COM (Stanley Friesen [Contractor]) wrote:
> In article <slrn7kj9s8.8j1.ramon@jl1.quim.ucm.es>,
> Ram'on Garc'ia Fern'andez <ramon@jl1.quim.ucm.es> wrote:
> >is less efficient. Futhermore, since there is a virtual function
> >table,
>
> Where does the standard ay there is a virtual function table?
AFAIK, it doesn't.

> You are assuming too much.
No, you are not assuming enough.

The standard doesn't specify the existance of a virtual table,
but it specifies certain behavior required when virtual functions
are called. Reading this, I tried hard to think of any other way
to accomplish the same thing. I failed.

That I personally couldn't come up with an alternative doesn't
prove a thing, of course. But then I came to comp.std.c++ and
asked the experts. This is about a year or two ago -- check
Deja.com. Do an author profile; my name at the time was
allanw@my-dejanews, without the underscore before the w.

The experts had lots of ideas for different ways to hide the
pointer to the virtual table, but it couldn't be done away
with completely. One person thought of putting the entire
list of pointers inside every object thus apparently replacing
the virtual pointer with a copy of the virtual table. (There
is no practical reason to do this; it's only to prove that there
are some alternatives.) But even this doesn't work, since there
needs to be some "master" data somewhere to initialize new
instances.

An interpreter would look up the data by function name, of
course. But all this does is to disperse the virtual table
across several per-function entries. A similar idea is to
move the virtual function mechanism into the prologue of
every virtual function. That is, let the main logic call
Base::virtfunc(), and let Base::virtfunc() determine that
*this is actually a Der and that Der::virtfunc() exists.
However, this requires that the definition of Der is known
when Base::virtfunc is compiled. Even then, how will
Base::virtfunc find the address of Der::virtfunc? That's
right, it looks it up in a table. The table still exists.

Even this doesn't prove (in the mathematical sense) that
virtual tables are a de-facto requirement. Call it a theorum,
again in the mathematical sense: It seems unprovable, but
even after extensive searches nobody has ever found an
exception, so we believe it until such time as more
information is available.

Stanley Friesen, can YOU suggest a workable mechanism that
compilers could use to call virtual functions correctly,
other than the existance of virtual tables? If not, please
don't tell Mr. Fernandez (or anyone else) that they haven't
thought the issue through.

--
Allan_W@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in newsgroups only, sorry.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7j9d64$n5d$1@nnrp1.deja.com> AllanW <allan_w@my-deja.com> writes:
>suggest a workable mechanism that compilers could use to call
>virtual functions correctly, other than the existance of virtual tables?

I'm unclear exactly what you are looking for, (and I suspect you might say
this is still a virtual table/virtual pointer), but how about a "tagged"
pointer along with a dropped in if statement at the point of a call.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- New Release!  We now do Windows too.
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.com ***


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7jfidf$orp$1@panix.com>, comeau@comeaucomputing.com wrote:

> In article <7j9d64$n5d$1@nnrp1.deja.com> AllanW <allan_w@my-deja.com> writes:
> >suggest a workable mechanism that compilers could use to call
> >virtual functions correctly, other than the existance of virtual tables?
>
> I'm unclear exactly what you are looking for, (and I suspect you might say
> this is still a virtual table/virtual pointer), but how about a "tagged"
> pointer along with a dropped in if statement at the point of a call.

For every class that implements a virtual function, have a static function
"virtual_function" that takes a function index and calls one of the
virtual functions of that class using something similar to a large "if"
statement. In the object, store a pointer to "virtual_function". A
"Pointer to member function" could use the same function index.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Barry Margolin <barmar@bbnplanet.com> wrote in message
news:wLy23.14$KM3.21@burlma1-snr2...
> >Well, the real difference in execution time is very small.
>
> Then why does C++ have public member variables at all?  You could replace
> them all with calls to member functions, which would access private member
> variables.
Make your own experiments.
struct A

  int d;
  A():d(1){}
  virtual int v() { return d;}
};
On my home computer (it's not the state of the art) without any optimization
(I verified assembler code) big loops produced 16 ns time for single j+=a.d
operation and 33 ns for j+=p->v() operation. Taking into account that in
real life there is much more code than just single int addition, you will
hardly notice the difference.

> Although the data is bound to a class, the class is bound dynamically to
> instances.  Templates work using the declared type of the object, not the
> actual type.
>
That's my mistake, I'd better read the whole thread  next time before
posting. Yes, in this case virtual function call is all that needed as the
previous authors already explained.

Gene.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <YiW23.50$KM3.15733@burlma1-snr2>,
Barry Margolin  <barmar@bbnplanet.com> wrote:
>In article <7ih6si$8fu@abyss.West.Sun.COM>,
>Stanley Friesen [Contractor] <stanley@West.Sun.COM> wrote:
>>You are assuming too much.
>
>While there doesn't have to be a virtual function table, there has to be
>something with equivalent functionality.  Is there a practical way to
>implement dynamic dispatching without something like that?  Whatever
>specific mechanism is used, that's a place where virtual static data could
>be stored.

Not necessarily.  One possible implementation uses jump code in "stub"
functions.  This does not generalize to data all that easily, except by
implementing stubs that return an address of the data.  But that is simply
a virtual functions that returns a pointer to local static data, so why not
simply do that explicitly?
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7ih6si$8fu@abyss.West.Sun.COM>,
Stanley Friesen [Contractor] <stanley@West.Sun.COM> wrote:
>In article <slrn7kj9s8.8j1.ramon@jl1.quim.ucm.es>,
>Ram'on Garc'ia Fern'andez <ramon@jl1.quim.ucm.es> wrote:
>>is less efficient. Futhermore, since there is a virtual function table,
>
>Where does the standard ay there is a virtual function table?
>
>You are assuming too much.

While there doesn't have to be a virtual function table, there has to be
something with equivalent functionality.  Is there a practical way to
implement dynamic dispatching without something like that?  Whatever
specific mechanism is used, that's a place where virtual static data could
be stored.

--
Barry Margolin, barmar@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 22 May 1999 16:32:40 GMT, Steve Clamage <stephen.clamage@sun.com> wrote:

>Although I think there's an implied smiley on James's post, I
>second his comment without a smiley. This newsgroups serves as,
>among other things, a sounding board for new ideas. Even if
>many ideas get shot down in flames, quite a number of comments
>from this newsgroup have found their way into the standard.

Even if our proposal gets shot down in flames, we at least learn
why C++ is the way it is.

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ram'on Garc'ia Fern'andez a    crit dans le message ...
>Even if the C++ standard is now closed, I want to discuss two new features
>that I would like to see.
>
>One is 'virtual static' data members.

Tell me if I am wrong, but virtual methods can't be static. It would be the
same for "virtual data members", if they were introduced in the C++
standard.




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7i6m0g$91q$1@engnews1.eng.sun.com>,
  stephen.clamage@sun.com (Steve Clamage) wrote:
> This newsgroups serves as,
> among other things, a sounding board for new ideas. Even if
> many ideas get shot down in flames, quite a number of comments
> from this newsgroup have found their way into the standard.

That's so nice to be heard from Steve.

I think we should first propose language changes to correct its known
defects, in a backward-compatible manner.

One thing that comes to mind is the <> separators for templates, which
led to so darn many problems... incredible! The typename keyword was
introduced only to correct that mistake (and make things so much
complicated: should I put typename here or not? Yuck!!!)

Another one, less annoying but also simple to correct: template
typedefs.

Back to the first issue, which seems really nasty to me, what about the
following. Some time ago, someone (I think Steve himeself) proposed the
separators "<|" and "|>" for templates. I don't remember exactly, maybe
they actually were "|<" and ">|", but I prefer the first ones. Let's
take a look:

vector<list<deque<int> > > blah;   // old way
vector<|list<|deque<|int|>|>|> blah;   // proposed way

This would add two new tokens to the language and obviate the need for
the typename keyword. The sequences are meaningless in a legal existing
C++ program, so there is backward compatibility.

In order for the change to be smooth, the old <> separators
and "typename" can be still usable but deprecated, as it is now with
the auto keyword or the implicit int in variable declaration.

There are many other small things like this that are simply language
design mistakes (C or C++). Everyone acknowledges that. We should
correct them first, and later on jumping into variable template
parameters or the typeof keyword (uh-oh)...

Best,

Andrei


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Biju Thomas <b_thomas@ibm.net> wrote:

: Ram'on Garc'ia Fern'andez wrote:
: >

: >         virtual bool is_a(const char *type) {
: >             return !strcmp(name, type) ||
: >                     parent::is_a(name, type);
                                    (type)

This will not work as expected.  When type is "A", it calls A::is_a
with a B* this.  Virtual data or function as below will still
be "B".  You need

                        static_cast<A*>(this)->is_a(type);
: >             }

: Wouldn't a virtual function with a local static variable do the job?

Yes it would.  That's called an objection ( opposite of functor :).

: const char* A::name ()
: {
:   static const char* itsName = "A";
:   return itsName;
: }

May as well just return "A"; in this simple case, but your solution
is the general case.

Unless I am missing something, the static data without the virtual
nonsense works fine.  In a B function name is B::name and the code
above would work.

I guess that the real desire is to use p->name and your p->name()
fits fine without virtual static data or data in each object which
was the stated need.

John



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Andrei Alexandrescu <andrewalex@hotmail.com> writes:

>I think we should first propose language changes to correct its known
>defects, in a backward-compatible manner.

>One thing that comes to mind is the <> separators for templates, which
>led to so darn many problems... incredible!

Changing the template delimiters from <> to something else was
discussed extensively in the C++ committee. It was proved that
various other choices would introduce no ambiguities and remove
some problems.  It was decided at that time that changing the
delimiters would break too much code and invalidate too many books
and other documentation. I don't think we considered leaving the
old syntax as a deprecated feature while introducing a new syntax.

At the time, non-type template parameters for functions and the
calling syntax "foo<template_args>()" were not part of the language.
"What-if" is sometimes a pointless exercise, but I suspect that
if that feature had been introduced into the language earlier,
the reasons to change template delimiters would have been stronger.
Except for that feature, I think the problems with <> are minor.

>The typename keyword was
>introduced only to correct that mistake (and make things so much
>complicated: should I put typename here or not? Yuck!!!)

No so. The typename keyword was introduced only to allow
improved error reporting from compilers, not because it
is necessary for parsing C++ code.

Under the original template rules, the compiler cannot parse a
general template declaration until it is instantiated, because the
compiler cannot tell if a name dependent on a template parameter is
a typename or not. That in turn means that even some simple errors
cannot be found when the template definition is first processed,
but must be delayed until some instantiation.  You then can get the
same error message for the same error in each instantiation.

The typename keyword was introduced to allow a compiler to detect
and report errors in template definitions independent of any
instantiation.

--
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 22 May 99 18:31:52 GMT, Biju Thomas <b_thomas@ibm.net> wrote:
>Ram'on Garc'ia Fern'andez wrote:
>Wouldn't a virtual function with a local static variable do the job?
>
>class A {
>  virtual const char* name ();
>};
You are absolutely right. I noticed it, but I forgot to say it. However, it
is less efficient. Futhermore, since there is a virtual function table, and
since using an entry for storing a pointer to data is so trivial, why not
doing it?

Ramon
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 23 May 1999 17:39:21 GMT, John Potter <jpotter@falcon.lhup.edu> wrote:
>Unless I am missing something, the static data without the virtual
>nonsense works fine.  In a B function name is B::name and the code
>above would work.

Of course, but it is less efficient.

>I guess that the real desire is to use p->name and your p->name()
>fits fine without virtual static data or data in each object which
>was the stated need.
No, I do not have any trouble with using p->name(). My trouble is with
performance. If we already have an vtable, why shouldn't the compiler
allow the programmer to take full advantadge of it, and place there a
pointer to arbitrary data? This is the real motivation for my suggestion.

Probably virtual static is not the best possible name. I used "virtual static"
because these data members are shared between instances of the same class
(like static data members) and when they are referenced, the actual referred
data depends on the dynamic type of the object (like virtual functions).

Ramon
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7i9gsf$mo0$1@engnews1.eng.sun.com>,
  clamage@eng.sun.com (Steve Clamage) wrote:
> I don't think we considered leaving the
> old syntax as a deprecated feature while introducing a new syntax.

I think we are in agreement that from now on, virtually all language
changes should be done in this way.

> Except for that feature, I think the problems with <> are minor.

Which (sorry for my newsgroup tone :o)) implies that in the end, the
problems with <> are not minor.

> No so. The typename keyword was introduced only to allow
> improved error reporting from compilers, not because it
> is necessary for parsing C++ code.

Ah, now I got it. Anyway, this doesn't make much of a difference: the
typename keyword is required (not optional), and it's a pain for the
programmer to figure out when it's to be put and when not. The postings
on csc and clcm are witnessing on this.

Another problem with <> is that sometimes you suddenly have to specify
"template" in the middle of some code, which is a hassle for those who
don't know it. I don't know exactly when the need appears; could you
dwell on it a bit?
(That's actually a poisoned invitation, a German gift(*), because then
I'll reply saying how nasty all this is :o).)

I would happily start using other separators than <>.

Andrei

(*) In German, Gift means "poison". Hence the saying: don't accept a
gift from a German.


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ram'on Garc'ia Fern'andez wrote:
>
> Even if the C++ standard is now closed, I want to discuss two new
> features that I would like to see.
>
> One is 'virtual static' data members. A virtual static data member
> would be shared by all instances of a class, but child classes could
> choose not to share it. It would be useful for implementing
> user-defined RTTI. For example:
>
> class A {
>         virtual static const char *description;
> };
>
> const char * A::description = "This is class A";
>
> class B {
>         virtual static const char *description;
> };
>
> const char * B::description = "This is class B";
>
> The implementation is not very difficult. Just place a pointer to the
> data in the sample place where you would place a pointer to a virtual
> function.

This seems eminently sensible to me. The virtual table is just a bunch
of pointers, so why restrict them to pointing to member functions? Why
not allow them to point to data, or even nonmember functions?

Allowing nonmember functions (i.e., virtual static functions) is
probably less useful, since the only saving is not passing the needless
"this" pointer to the function. But virtual data could be particularly
advantageous, when compared to a virtual function that returns some
data, because it avoids the function call.

> Another feature that I would like to see is a method for determining
> if an object inherits from another. dynamic_cast<T> requires the
> programmer to know the type T at compile time; sometimes this is not
> possible. Futhermore I believe that it shouldn't require much effort
> for the implementation to provide this operation if it is already
> providing dynamic_cast.
>
> What I am requesting is something like:
> bool is_a(typeinfo& parent, typeinfo&child);

This is something I desperately want. As Valentin mentions, this
function, or something like it, already exists internally, in order to
support exception handling. The statement "throw x;" where x is of type
T, inevitably involves throwing both a copy of x and a type_info (or
anaglogous internal object) for T. Each catch clause is also associated
with a type_info, and the process of matching a throw to a catch
involves making exactly this sort of comparison. What I'd _really_ like
to see is:

void* do_dynamic_cast(void* obj, const type_info& from,
 const type_info& to);

This would interpret "obj" as a pointer to an object of type "from", and
either dynamic_cast it to a pointer of type "to", or fail by returning a
null pointer.

Some may grit their teeth at this sort of thing, but I find the
mechanism extremely appealing as a way of handling polymorphic lists.
Consider what exception handling really involves: it implements a map of
handlers that are named by their type. Throwing an exception involves
finding the last (most recent) entry in the map that matches the type,
according to the normal rules of inheritance.

This technique of cataloging objects by type is more generally useful.
I'd like to be able to attach properties to objects, where a property
could be any object of any type. Then, I'd like to ask for the last
(most recent) property of a particular type. Wrapped in a template, I
could write:

 foo* f = property_find<foo>(some_object);

where some_object has as one of its bases the sort of map described
above. This can be done using current technology if you're satisfied
with an exact type match, using "map<type_info,void*>". It can also be
done in a completely different manner if the type your looking for is of
class type. However, you can't do it in the general case, allowing both
for nonclass types, and inheritance of class types. What I want built
into property_find is exactly what exception handling does when it looks
for a matching handler.

--

Ciao,                       Paul D. DeRocco
Paul                        mailto:pderocco@ix.netcom.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <slrn7kj9s8.8j1.ramon@jl1.quim.ucm.es>,
  ramon@jl1.quim.ucm.es (Ram'on Garc'ia Fern'andez) wrote:
> >class A {
> >  virtual const char* name ();
> >};
> You are absolutely right. I noticed it, but I forgot to say it.
However, it
> is less efficient. Futhermore, since there is a virtual function
table, and
> since using an entry for storing a pointer to data is so trivial, why
not
> doing it?
Well, the real difference in execution time is very small.
You can also use another code. Since your data are bound to class and
not to instance, it's a perfect candidate for template function. Making
the latter inline will let you avoid any function call penalties
(though really insignificant in practice):

template<class T> inline const char* name(){return "unspecified";}
template<> inline const char* name<A>(){return "A";}
template<> inline const char* name<B>(){return "B";}

It's certainly possible to add data portion to vmt, but it doesn't
really achieve anything what you cannot easily achieve by existing
means.

Gene


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7icljh$njg$1@nnrp1.deja.com>,  <gbush@my-dejanews.com> wrote:
>In article <slrn7kj9s8.8j1.ramon@jl1.quim.ucm.es>,
>  ramon@jl1.quim.ucm.es (Ram'on Garc'ia Fern'andez) wrote:
>> >class A {
>> >  virtual const char* name ();
>> >};
>> You are absolutely right. I noticed it, but I forgot to say it.
>However, it
>> is less efficient. Futhermore, since there is a virtual function
>table, and
>> since using an entry for storing a pointer to data is so trivial, why
>not
>> doing it?
>Well, the real difference in execution time is very small.

Then why does C++ have public member variables at all?  You could replace
them all with calls to member functions, which would access private member
variables.

>You can also use another code. Since your data are bound to class and
>not to instance, it's a perfect candidate for template function. Making
>the latter inline will let you avoid any function call penalties
>(though really insignificant in practice):

Although the data is bound to a class, the class is bound dynamically to
instances.  Templates work using the declared type of the object, not the
actual type.

--
Barry Margolin, barmar@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <slrn7kj9s8.8j1.ramon@jl1.quim.ucm.es>,
Ram'on Garc'ia Fern'andez <ramon@jl1.quim.ucm.es> wrote:
>is less efficient. Futhermore, since there is a virtual function table,

Where does the standard ay there is a virtual function table?

You are assuming too much.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> One thing that comes to mind is the <> separators for templates, which
> led to so darn many problems... incredible!

A number of syntaxic complications, yes, but nothing really deep.

And not everyone agres that it was an error.

--

Valentin Bonnard


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ram'on Garc'ia Fern'andez wrote:
>
> Even if the C++ standard is now closed, I want to discuss two new features
> that I would like to see.

Why should you be any different? The closure of the standard has done
essentially nothing to reduce the frequency with which new features are
proposed on this newsgroup.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper <kuyper@wizard.net> writes:

>Ram'on Garc'ia Fern'andez wrote:
>>
>> Even if the C++ standard is now closed, I want to discuss two new features
>> that I would like to see.

>Why should you be any different? The closure of the standard has done
>essentially nothing to reduce the frequency with which new features are
>proposed on this newsgroup.

Although I think there's an implied smiley on James's post, I
second his comment without a smiley. This newsgroups serves as,
among other things, a sounding board for new ideas. Even if
many ideas get shot down in flames, quite a number of comments
from this newsgroup have found their way into the standard.

Lots of smart and insightful people cannot (or do not wish to)
participate directly in the standards process. This newsgroup
provides a way for anyone to present ideas and suggestions.
Many members of the C++ committee read this newsgroup regularly,
so you get at least some vicarious participation.

The newsgroup FAQ (see below) provides some suggestions regarding
proposals.  If you read and follow the suggestions, chances are
increased that your proposal will be considered seriously.

--
Steve Clamage, stephen.clamage@sun.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ram'on Garc'ia Fern'andez wrote:
>
> class A {
>         virtual static const char *name;
>         virtual bool is_a(const char *type) {return !strcmp(name, type); }
> };
> static const char * A::name = "A";
>
> class B: public A {
>         typedef A parent;
>         virtual const char char *name;
>         virtual bool is_a(const char *type) { return !strcmp(name, type) ||
>                                                 parent::is_a(name, type); }
> };
> static const char * B::name = "B";
>

Wouldn't a virtual function with a local static variable do the job?

class A {
  virtual const char* name ();
};

const char* A::name ()
{
  static const char* itsName = "A";
  return itsName;
}

class B : public A {
  virtual const char* name ();
};

const char* B::name ()
{
  static const char* itsName = "B";
  return itsName;
}

--
Biju Thomas
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 18 May 1999 23:12:42 GMT, Valentin Bonnard <Bonnard.V@wanadoo.fr> wrote:
>
>Ram'on Garc'ia Fern'andez wrote:
>
>But then, why not use a virtual function instead ? You must show
>us why it is useful, not just what it does and why it is easy.
>Not that I would be opposed to static virtual functions, BTW.
No, they are not static virtual functions. I am proposing virtual static
data members.

On most situations, you can replace a virtual static data member by
a pointer to the appropiate data, and be careful to initialize it
to the target data during construction. However, this approach adds
a new data member to the object. In fact, it adds a new one every time
that you make a new derived class. Some systems have many objects, and
the additional pointer becomes an important overhead.

So you wish an example. Here is one.
Many object frameworks have user-defined run-time type information,
because they have special needs. For example, in CORBA each object
has a method bool is_a(type&), which accepts a (implementation defined)
information about the CORBA type and returns true if this object is of
the given type. To implement it, a object implementation could have
a data member that points to some structure that reports on the type of
the object. Let us consider that the type information is stored in a
const char *. An implementation without virtual static data members
could be:

class A {
 const char *type_name;
};

Since this info is the same for all objects of type A, it shoud be shared for
them, but it should be different for objects of derived types, which must
have different type information. So we should have something like:

class A {
 virtual static const char *name;
 virtual bool is_a(const char *type) {return !strcmp(name, type); }
};
static const char * A::name = "A";

class B: public A {
 typedef A parent;
 virtual const char char *name;
 virtual bool is_a(const char *type) { return !strcmp(name, type) ||
      parent::is_a(name, type); }
};
static const char * B::name = "B";


Recall that one of the goals of distributed objects is that no overhead should
be added to local objects. I do not like ORBs where the size of any object,
even a local one, is at least 80 bytes. If you program a system where you
have lots of lightweigth objects, such as a word processor, you need to
keep the size of each object as small as possible. So having virtual
static data members help a lot.

There are many examples possible. For example, Microsoft Fundation Classes
have user defined run-time type information. And many others.

Ramon
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Even if the C++ standard is now closed, I want to discuss two new features
that I would like to see.

One is 'virtual static' data members. A virtual static data member would be
shared by all instances of a class, but child classes could choose not to
share it. It would be useful for implementing user-defined RTTI. For example:

class A {
 virtual static const char *description;
};

const char * A::description = "This is class A";

class B {
 virtual static const char *description;
};

const char * B::description = "This is class B";

The implementation is not very difficult. Just place a pointer to the data
in the sample place where you would place a pointer to a virtual function.


Another feature that I would like to see is a method for determining if an
object inherits from another. dynamic_cast<T> requires the programmer to
know the type T at compile time; sometimes this is not possible. Futhermore
I believe that it shouldn't require much effort for the implementation to
provide this operation if it is already providing dynamic_cast.

What I am requesting is something like:
bool is_a(typeinfo& parent, typeinfo&child); // Returns true if child inherits
                        // from parent


Ramon
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ram'on Garc'ia Fern'andez wrote:

> Even if the C++ standard is now closed, I want to discuss two new features
> that I would like to see.

I say `completed', or `done', not closed. <g>

> One is 'virtual static' data members. A virtual static data member would be
> shared by all instances of a class, but child classes could choose not to
> share it. It would be useful for implementing user-defined RTTI.

> The implementation is not very difficult. Just place a pointer to the data
> in the sample place where you would place a pointer to a virtual function.

But then, why not use a virtual function instead ? You must show
us why it is useful, not just what it does and why it is easy.
Not that I would be opposed to static virtual functions, BTW.

> What I am requesting is something like:
> bool is_a(typeinfo& parent, typeinfo&child); // Returns true if child inherits
>                                              // from parent

I believe that every implementation of exceptions already supports
that internally.

--

Valentin Bonnard


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]