Gene Bushuyev <gbush@my-deja.com> wrote in article
<01fb312280812c9CPIMSSMTPE01@msn.com>...

> "Wil Evers" <bouncer@dev.null> wrote in message
> news:01bf47db$75457780$d03240c3@twwie...
> [snip]
> > Right.  C++ doesn't need properties; Borland Pascal needs them because
> > it has no operator overloading.  Like some other oddities, Borland
> > introduced built-in properties into their C++ dialect to get binary
> > compatibility with libraries originally written for Delphi.
>
> The question of what C++ needs doesn't really make much sense. We can
> only speak about what programmers need (and what compiler implementors
> can/want) in order to express some concepts; and this "need" is often
> very subjective.
> Speaking of myself, I find properties much needed.

I didn't say programmers don't need properties.  What I did try to say is
that C++ allows us to implement properties as a library facility; there's
no need to change the language definition for that.

I can't believe that the people who decided to introduce built-in
properties into Borland C++ weren't aware of this; they must have felt that
it was cheaper to change their C++ compiler than to reimplement the VCL in
C++.

I believe that in doing so, they served Borland's interests rather than the
C++ community as a whole, because C++ is big enough without properties.

> There was a number of discussions about properties in the past. There
> were some suggestions of implementation.

Yes.  I was referring to David R. Tribble's example implementation.

> I haven't seen yet an implementation that would have the full
functionality
> of Borland (or even MS VC) properties and have the same efficiency and
> convenience of use.

If we loosely define a property as a device that maps a setter/getter pair
to a named class member, then it can be implemented fairly cheaply in terms
of run-time overhead.

As always, getting the full bag of syntactic sugar is harder without
changing the compiler.  I don't believe that's much of a problem as long as
most of the burden is on the class's implementor, rather than on the
class's users.

When you talk about functionality and ease of use, what exactly are you
looking for?

> If you want to stay with the standard you shouldn't try to implement
> property (class) rather you should use the functions (like Get, Set,
> and maybe other) instead.

Why?

> If you have something new to offer, I would be glad to see that.

Other than the usual C++ bag of tricks, I don't think so, which is exactly
the point I'm trying to make.

Regards,
- Wil

Wil Evers, DOOSYS IT Consultants, Maarssen, Holland
[Wil underscore Evers at doosys dot com]



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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              ]

I'd love there to be something between static and member -- one per class.
Subclasses have a different value. It's where I'd stick things like a class
id #, or table name, that must be accessed and modified by a number of
different functions. If it's read-only, I make it the static member of a
virtual accessor function. But how does one do read-write?

-mi

--
Micha Berger (973) 916-0287          MMG"H for 20-Dec-99: Levi, Vayechi
micha@aishdas.org                                         A"H
http://www.aishdas.org                                    Pisachim 86b
For a mitzvah is a lamp, and the Torah its light.
---
[ 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              ]

Micha Berger wrote:
>
> I'd love there to be something between static and member -- one per class.
> Subclasses have a different value. It's where I'd stick things like a class
> id #, or table name, that must be accessed and modified by a number of
> different functions. If it's read-only, I make it the static member of a
> virtual accessor function. But how does one do read-write?

Make it a static member of a virtual accessor function, of course.
Just remember to return a *reference* to it.

I.e.

class A {
 virtual std::string& ClassId() const
  { static std::string s;return s; }
}

Michiel Salters

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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              ]

David R Tribble <david@tribble.com> wrote in article
<384FE430.E79A6A53@tribble.com>...

> You might want to search comp.std.c++ (DejaNews) for a post I made a
> few months ago demonstrating how to simulate properties in C++ by
> overloading the 'operator=()' and 'operator T()' (thus simulating the
> 'read' and 'write' properties) for a public member variable of type
> 'T' within a class.

Right.  C++ doesn't need properties; Borland Pascal needs them because it
has no operator overloading.  Like some other oddities, Borland introduced
built-in properties into their C++ dialect to get binary compatibility with
libraries originally written for Delphi.

- Wil

Wil Evers, DOOSYS IT Consultants, Maarssen, Holland
[Wil underscore Evers at doosys dot com]




      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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              ]

"Wil Evers" <bouncer@dev.null> wrote in message
news:01bf47db$75457780$d03240c3@twwie...
[snip]
> Right.  C++ doesn't need properties; Borland Pascal needs them because it
> has no operator overloading.  Like some other oddities, Borland introduced
> built-in properties into their C++ dialect to get binary compatibility
with
> libraries originally written for Delphi.

The question of what C++ needs doesn't really make much sense. We can only
speak about what programmers need (and what compiler implementors can/want)
in order to express some concepts; and this "need" is often very subjective.
Speaking of myself, I find properties much needed.
There was a number of discussions about properties in the past. There were
some suggestions of implementation. I haven't seen yet an implementation
that would have the full functionality of Borland (or even MS VC) properties
and have the same efficiency and convenience of use. If you want to stay
with the standard you shouldn't try to implement property (class) rather you
should use the functions (like Get, Set, and maybe other) instead. If you
have something new to offer, I would be glad to see that.

Gene Bushuyev




[ 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              ]

sirwillard@my-deja.com wrote:
> In article <3850FE04.F4E9D617@nowhere.net>, User <void@nowhere.net> wrote:
> > David R Tribble wrote:
> > As the next poster had already stated, this is only a logical problem
> > (viewpoint of the language designer), not a practical problem. In this
> > type of function (virtual static), you would be unable to call other
> > virtual static functions, because you have no "this" pointer, even if
> > the other functions are declared "static", too. I think this is one of
> > the problems why they didn't allowed this kind of function attribute
> > combination; they would form a third class of functions which might
> > be called only by methods (with self-pointer), but can call only
> > static methods (without self-poiner), and cannot call each other (but
> > on the other hand can call themselves!). This is ugly, isn't it ?
>
> "virtual static" methods can call other "virtual static" methods.  The
> only question is whether or not they should do so implicitly.  In other
> words, in the virtual static method should you have to fully qualify
> calls to other virtual static methods, or will the compiler implicitly
> assume the same type and call the function statically?  The implicit
> route may result in (at first) surprising behavior, but it's no
> different than what you'd achieve using the fully qualified method.

Okay, the qualified way works. But not the implicit way. You call a
virtual function and its suddenly no longer virtual, because you have
no 'this pointer' ? This is impossible, that rule would be completely
confusing ! You cannot call virtual functions without an object,
point.


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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              ]

: David R Tribble <david@tribble.com> wrote:

>You might want to search comp.std.c++ (DejaNews) for a post I made a
>few months ago demonstrating how to simulate properties in C++

"david tribble properties" (or "... property", "... simulate") turns up a
few hits, but no demonstration of implementing properties.

Could you be a bit more specific?

Thanks!



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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              ]


[ 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 <3850FE04.F4E9D617@nowhere.net>,
  User <void@nowhere.net> wrote:
> David R Tribble wrote:
> As the next poster had already stated, this is only a logical problem
> (viewpoint of the language designer), not a practical problem. In this
> type of function (virtual static), you would be unable to call other
> virtual static functions, because you have no "this" pointer, even if
> the other functions are declared "static", too. I think this is one of
> the problems why they didn't allowed this kind of function attribute
> combination; they would form a third class of functions which might
> be called only by methods (with self-pointer), but can call only
> static methods (without self-poiner), and cannot call each other (but
> on the other hand can call themselves!). This is ugly, isn't it ?

"virtual static" methods can call other "virtual static" methods.  The
only question is whether or not they should do so implicitly.  In other
words, in the virtual static method should you have to fully qualify
calls to other virtual static methods, or will the compiler implicitly
assume the same type and call the function statically?  The implicit
route may result in (at first) surprising behavior, but it's no
different than what you'd achieve using the fully qualified method.



Sent via Deja.com http://www.deja.com/
Before you buy.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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              ]

David R Tribble <david@tribble.com> wrote:
> [snip]
> >
> > By the same reasoning, C++ could also allow virtual static member
> > variables.
> [snip]

Gene Bushuyev wrote:
> Well, in reality there is no need in introducing virtual static
> variables.  Every compiler that implements properties can handle
> this task with elegance  :-)
> Here is the example of a real (BCB) code that does what you want:
>     class Base
>     {
>     public:
>         static int  xcounter;
>         virtual int Get(){return xcounter;}
>         virtual void Set(int x){ xcounter=x;}
>         __property int counter={read=Get,write=Set};
>     };
[snip]

You might want to search comp.std.c++ (DejaNews) for a post I made a
few months ago demonstrating how to simulate properties in C++ by
overloading the 'operator=()' and 'operator T()' (thus simulating the
'read' and 'write' properties) for a public member variable of type
'T' within a class.

In any case, though, virtual static functions and virtual static
variables probably have their uses.

-- David R. Tribble, david@tribble.com, http://david.tribble.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              ]

David R Tribble wrote:
>J.Barfurth wrote:
>> Lorenzo Bettini <bettini@gdn.dsi.unifi.it> schrieb in im Newsbeitrag:
>>> J.Barfurth wrote:
>>>> 2) Why _can't_ you have a virtual static function?  There must be
>>>> a good reason, but I have no clue as to what that good reason is.
>>> In my opinion I think the reason is quite simple:
>>> a static method is not passed "this", and the (run time) type of
>>> this is used to select a virtual method.

As the next poster had already stated, this is only a logical problem
(viewpoint of the language designer), not a practical problem. In this
type of function (virtual static), you would be unable to call other
virtual static functions, because you have no "this" pointer, even if
the other functions are declared "static", too. I think this is one of
the problems why they didn't allowed this kind of function attribute
combination; they would form a third class of functions which might
be called only by methods (with self-pointer), but can call only
static methods (without self-poiner), and cannot call each other (but
on the other hand can call themselves!). This is ugly, isn't it ?

I would like to have such a feature anyway.

>> Generally you have to select a virtual method first, based on the
>> dynamic type of the object for which the method is invoked, and only
>> then pass it 'this' as an argument. The type of 'this' may be
>> different from both a pointer to the static type and the dynamic
>> (most derived) type of the object. All three pointers could in fact
>> have different values when static_cast'ed to void*. A 'static
>> virtual' method would just be called without passing the this
>> pointer. This would even save any overhead necessary to adjust the
>> value needed for 'this'.
>Exactly. By the same reasoning, C++ could also allow virtual
>static member variables.

Variables are not code, so there is nothing dynamically changeable.
You just want a new instance of them per class, don't you ? I would
really like it if C++ would have a feature like this, declaring code
and variables which are automatically created again for each
subclass, for example:

class object {
public:
 virtual typestatic typesize () const { return sizeof(*this); }
};

Well this is still very ugly. But this way you wouldn't have to
reimplement typesize() in subclasses again - only if you want to.
Many of the class declaration macros of frameworks such as wxWindows
(http://www.wxwindows.org) would become superflous this way !
---
[ 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              ]

----- Original Message -----
From: David R Tribble <david@tribble.com>
[snip]
>
> By the same reasoning, C++ could also allow virtual static member
> variables.
>
>     class Base
>     {
>     public:
>         virtual static int  counter;
>         ...
>     };
>
>     class Der: public Base
>     {
>     public:
>         virtual static int  counter;
>         ...
>     };
>
>     void foo(Base *o)
>     {
>         o->counter++;  // depends on dynamic type of o
>     }
>
>     void bar()
>     {
>         Base    b;
>         Der     d;
>
>         foo(&b);     // increments Base::counter
>         foo(&d);     // increments Der::counter
>     }
>

Well, in reality there is no need in introducing virtual static variables.
Every compiler that implements properties can handle this task with elegance
:-)
Here is the example of a real (BCB) code that does what you want:
    class Base
    {
    public:
        static int  xcounter;
        virtual int Get(){return xcounter;}
        virtual void Set(int x){ xcounter=x;}
        __property int counter={read=Get,write=Set};
    };
    int Base::xcounter=1;

    class Der: public Base
    {
    public:
        static int  xcounter;
        virtual int Get(){return xcounter;}
        virtual void Set(int x){ xcounter=x;}
    };
    int Der::xcounter=10;

    void foo(Base *o)
    {
        o->counter++;  // depends on dynamic type of o
    }

    void bar()
    {
        Base    b;
        Der     d;

        foo(&b);     // increments Base::counter
        foo(&d);     // increments Der::counter
        cout<<b.counter<<"  "<<d.counter<<"\n";
    }

Gene Bushuyev



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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              ]

J.Barfurth wrote:
>
> Lorenzo Bettini <bettini@gdn.dsi.unifi.it> schrieb in im Newsbeitrag:
>>
>> J.Barfurth wrote:
>>> 2) Why _can't_ you have a virtual static function?  There must be
>>> a good reason, but I have no clue as to what that good reason is.
>>
>> In my opinion I think the reason is quite simple:
>>
>> a static method is not passed "this", and the (run time) type of
>> this is used to select a virtual method.
>
> Generally you have to select a virtual method first, based on the
> dynamic type of the object for which the method is invoked, and only
> then pass it 'this' as an argument. The type of 'this' may be
> different from both a pointer to the static type and the dynamic
> (most derived) type of the object. All three pointers could in fact
> have different values when static_cast'ed to void*. A 'static
> virtual' method would just be called without passing the this
> pointer. This would even save any overhead necessary to adjust the
> value needed for 'this'.

Exactly.

By the same reasoning, C++ could also allow virtual static member
variables.

    class Base
    {
    public:
        virtual static int  counter;
        ...
    };

    class Der: public Base
    {
    public:
        virtual static int  counter;
        ...
    };

    void foo(Base *o)
    {
        o->counter++;  // depends on dynamic type of o
    }

    void bar()
    {
        Base    b;
        Der     d;

        foo(&b);     // increments Base::counter
        foo(&d);     // increments Der::counter
    }

-- David R. Tribble, david@tribble.com, http://david.tribble.com --


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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              ]

>>>>> Rick Hollinbeck <rickh@csn.net> writes:

> I would like to see C++ evolve the way FORTRAN used to. Instead of
> "Standard C++", similar to "Standard C" (which was the death bell for C),
> what about "C++ '96", and keep the standards committee going to improve the
> language for "C++ '98" (better hurry before Bill Gates trademarks the idea!)

This is standard procedure.  "Standard C" is also known as C '89 (and some
compilers for that language are called c89), and was in no way the death
bell of C; our friends in ISO WG14 are currently working on the next C
standard.

Jason

Etay Bogner (ebogner@ird.scitex.com) wrote:

: If it can be done by writing code, why add a feature ?

Then again,
 if it can be written in assembly language, why add a language?

The goal is expressiveness and conciseness. This feature might provide both.

But, it may be too late (I'm afraid) to propose this for the current standard.

I would like to see C++ evolve the way FORTRAN used to. Instead of
"Standard C++", similar to "Standard C" (which was the death bell for C),
what about "C++ '96", and keep the standards committee going to improve the
language for "C++ '98" (better hurry before Bill Gates trademarks the idea!)

As a C++ parser writer, I say this with great hesitation <g>,
but I believe it is probably a good idea for the language to continue
evolving in a controlled way.

Since I joined this debate in the middle, I'll be happy if someone will repeate
the behavior and features of virtual static member functions, just to make sure
I didn't miss any such features.

stidev@news.gate.net (Solution Technology) wrote:

>The point of language features is to minimize the amount of detail
>you need to write to get the job done.  Otherwise back to the Turing
>Machine, the ultimate RISC architecture.

My point exactly.

Since I ( I hope ) demonstarted why the user will have to deal with the
initializtion of those "virtual static" data in each subclass, he has to write code
to maintain it even if "virtual static" is a feature.

So, the sentence "minimize the amount of detail you need to write to get the job
done", doesn't apply here.

Let me write that again :

If it can be done by writing some code, why add a feature which will require the
programmer to write code with the same overhead ?

-- Etay Bogner,
-- ebogner@ird.scitex.com ( OLD ),
-- Etay_Bogner@mail.stil.scitex.com,
-- Scitex Corp.
-- Israel.

I joined this debate in the middle, so...

Here is a trivial solution :

struct ClassData {
 ...
 };

class Base {
        ...
        virtual ClassData& sClassData() {
                                static ClassData __sClassData = { ... };
                                return __sClassData;
                                };
        ...
        };

Have this function in each derived class and you'll get "virtual static
data". The Data NAME is as the FUNCTION NAME, in this case "sClassData".

This adds the entry to the vtable, not to objects...

You can do everything you want with it as you would with a "real" data
memeber. The only difference is that you have to use the format
"sClassData()" when reffering to it.

If there were a "virtual static data" feature in C++ then the programmer
had to DEFINE it per subclass, since the programmer may want to
initialize it in different ways for each subclass.

So, an extra work had to be done by the programmer. In this case, an
extra work is done by the programmer by adding to each sub class the
above virtual function ( that could be a macro. NOT ! ).

I don't think that the C++ commitee would except a "virtual static"
feature which would create ( the compiler will, that is ) a static data
instance per subclass ( because of the initializtion problem I just
mentioned ).

If it can be done by writing code, why add a feature ?

-- Etay Bogner,
-- ebogner@ird.scitex.com ( OLD ),
-- Etay_Bogner@mail.stil.scitex.com,
-- Scitex Corp.
-- Israel.

: If it can be done by writing code, why add a feature ?

By that argument we don't need C++, we can write it in C.
I've done it and I don't want to do it again.

The point of language features is to minimize the amount of detail
you need to write to get the job done.  Otherwise back to the Turing
Machine, the ultimate RISC architecture.

Ken Walter

George Mitchell (george@mvp.com) wrote:
|> kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:

|> James>In article <george.804182373@southstation.mvp.com> george@mvp.com
|> James>(George Mitchell) writes:

|> George> I would second this, adding that I'd like static virtual data members
|> George> to be allowed, as well as function members.

|> James>Since there are currently no virtual data members, static or not, this
|> James>would be a major change.

|> In fact, it wouldn't.  Please see below.

|> George> The fact is, a vtable is effectively a static virtual data member of a
|> George> class.  It just happens to be restricted to pointers to member functions.

|> James>It also just happens not to be accessible to the programmer.  In fact,
|> James>there is no requirement in the standard that there be a vtable, and no
|> James>way a standard conforming program can determine whether one is present

|> This is correct, so let me rephrase what I was saying as follows:

|> There currently exists a body of information associated with each
|> class: the addresses of its virtual member functions.

To strengthen your case, you might add RTTI information.

|> This infor-
|> mation is:

|> a. static (associated with the class, rather than with any instance
|>    of the class);

While it *is* static in all of the implementations I'm familiar with,
there is no requirement that it be so.

An obvious (although inefficient) implementation would be to simply put
all of the information in the object itself (instead of just putting a
pointer to the static information in the object).

|> b. virtual (dependent upon the type of the object pointed to);

|> c. data.

|> As it happens, it is also:

|> d. private;

|> e. const;

|> f. of the type pointer-to-function.

|> All implementations of C++ must provide some means of fetching this
|> static virtual data, given a pointer to an object.  If this means did
|> not already exist, there would be no way of calling virtual member
|> functions.

|> So --

|> Why not allow the data to be other types?  It could even be public,
|> or non-const.  It's clear how to implement this for those compilers
|> which use vtables: just put these new static virtual data members
|> into the vtable, with the static virtual private const pointers-to-
|> functions which are already in there.  But even implementations
|> which don't use vtables *already have* static virtual data (in
|> effect).

Well, my system (and I imagine most others) puts vtable's in read only
memory, so I think that what you would want is a pointer to the
variable in the vtable, not the variable itself.

I never said that it couldn't be done; as you correctly point out,
independently of the actual implementation, the compiler does arrange
for the program to find the address of a function (which is, by
definition, static in the sense we use static for data), and so could
just as easily find the address of static data.

The problem is that there is currently no compiler which does this, and
there has been no real proposal (and the associated discussion)
concerning how to do it.  It is new ground, and although it is certainly
not a big extension, it is an extension, and would introduce new
unknowns.  (Example: can you take the address of virtual static data?
What is the type of this address?)

For similar reasons, at the present time, I would probably oppose any
proposal to add static virtual functions to the language, although
unlike static virtual data, I have often had use for them.
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle--
                             --Beratung in industrieller Datenverarbeitung

Wil Evers (wil@ittpub.nl) wrote:

: I think dropping the restriction that says static member functions can't
: be virtual should be considered a simplification of the language rather
: than an addition to it.

I agree - these unnecessary illegal constructs only make C++ harder to teach.
And it seems virtual statics would be very useful and trivial to implement.
Why not strike the prohibition from the standard's wording?

- Rick Hollinbeck

In article <3tpu8c$50o@news-2a.csn.net> rickh@csn.net (Rick Hollinbeck) writes:

> I agree - these unnecessary illegal constructs only make C++ harder to teach.
> And it seems virtual statics would be very useful and trivial to implement.
> Why not strike the prohibition from the standard's wording?

Because there are some ways in which the semantics of a "static
virtual" function are unclear, because it addresses only a minor
convenience issue, and because it would complicate both the
meaning of static member functions and of virtual member functions.
As a practical matter, I think that those considerations are enough
so that, at this late date, there is no chance of the committee
approving this extension.

There are some things that are currently true of all static member
functions that wouldn't be true of "static virtual" functions, and
there are some things that are currently true of all virtual member
functions that wouldn't be true of "static virtual" functions.

In other words, I believe that a "static virtual" function would have
to be neither static nor virtual, but something else.  A better way to
think of it might be as two functions of the same name one of which is
static and one of which is virtual.
--
Matt Austern          matt@physics.berkeley.edu
http://dogbert.lbl.gov/~matt

Loic Tregan@epita.fr (tregan_l) writes:

> I really think there VERY interesting features in Delphi, even if the language
>itself is not as coherent as C++.

Just out of interest, what is it that makes you think Delphi is less
coherent than C++?  C++ has a lot of good qualities, but I wouldn't have
said that "coherence" was one of them ;-)

--
Fergus Henderson
fjh@cs.mu.oz.au
http://www.cs.mu.oz.au/~fjh
"The unexamined life is not worth living" - Socrates.

wil@ittpub.nl (Wil Evers) writes:
>Yes, it seems possible to implement (static) virtual data members. Maybe
>this has been discussed before here, but just out of curiosity, I would
>like to ask:

>- Where will virtual data members be initialized? In some (derived)
>constructor?
Before I answer this question, let me make clear that I am supporting
*only* *static* virtual data members.  I can see a number of problems
regarding non-static virtual data members.  But the static ones would
be initialized like other static data members.

>- Do you think we should have *abstract* virtual data members?
It couldn't hurt -- but there's no obvious syntax for them that doesn't
look like an initialization.

>- What would the initialization syntax look like?
Assuming you are asking about the static, non-abstract case:
class foo {
   static virtual int bar;
};
int foo::bar = 3;

>- Why do you think having (static) virtual data members would be useful?
>Can you give an example?
Yes -- I just had one at work the other day.  We have a base class called
SnmpTableFinder which runs through the SNMP protocol for searching for
an SNMP table, and if it's not found, then creating it (and destroying
it when I'm finished with it).  Derived classes, differing only in the
object ID of the tables to be created, search for and create specific
types of tables (EtherStats, TokenMLStats, Matrix, Host, etc.)  As it
stands, we define a virtual function to return the object ID of the
table to be created and then override the function in the derived
classes.  All the function does it to return the object ID -- a piece
of data which varies from class to class, but which is the same for
all instances of the class, and which is currently stored in a static
data member.  Why not just make that data member directly accessible
virtually?

>- Do you have a view on how having (static) virtual data members would
>affect C++ programming style? Do you see any new idioms they would
>support?
I think the impact would be minimal.  It would avoid a small amount of
clumsiness in a limited number of cases.

>- Do you think they'll introduce any new pitfalls into the language?
Not being too imaginative in this respect, I haven't a clue, as far as
*static* virtual data members go.  Non-static virtual data members, in
conjunction with multiple inheritance, would be subject to all of the
well-known pitfalls of virtual functions, virtual inheritance, which
are already known.

>Thanks.
You're welcome!  I appreciate your interest.

>- Wil
-- George Mitchell (george@mvp.com)

In article <bill_law-2306951038370001@bill-law.taligent.com>, bill_law@taligent.com (William A. Law) writes:
>In article <3sefsf$si6@horus.mch.sni.de>, weidinger.muc@sni.de (Erik
>Weidinger) wrote:
>
>> I don't understand this discussion.
>>
>> When do you expect a static virtual function to be called ?
>> The purpose of virtual functions is to bind methods to calls at runtime.
>> This binding depends on the actual class of the object instance.
>>
>> What could be the purpose of static virtual functions then ?
>
>A static virtual function would be called in the same way a non-virtual
>static function is called.  The call would be "virtual" (i.e., through a
>vtbl depending on the actual type of the object) when invoked via a
>reference or pointer

I don't understand this either!  If you've always got to have a object
around then what's the gain in making the method static?  Why not let
it be a non-static method?

This isn't to say that I haven't wanted virtual static methods.  I have
a base class that defines a enum for status values.  There's also a static
method, StatusName, that maps a status to a string.  Derived classes can define
additional status values.  Now I want StatusName to be virtual!

I wondered if maybe my criteria for choosing between static and non-static
members was screwed up and I should simply settle for non-static method.
I need to think about this more, but I think I'm happy in saying that
what I want is really
   obj->GetClass()->StatusName (status)
(where classes are objects to as in Smalltalk) rather than just
   obj->StatusName (status)

...but, pragmatically speaking, I can achieve what I want using a non-
static method and the second syntax, so again, I wonder, what's all the
fuss?  What would static virtual functions add?

People have also been talking about static virtual data members.  I'm
not sure I've got my head around this yet, but as for non-static data
members, I've heard people say we don't have them, but as far as I
understand what they are, we do.  If I write:

    class BM { ... }; class DM1 : public BM { ... }; ; class DM2 : public BM { ... };

    class B { BM &m_bm; B (BM &bm) : m_bm (bm) {...} ... }:
    class D1 : public B { DM1 m_dm1; D1 () : B (m_dm1) { ...} ... };
    class D2 : public B { DM2 m_dm2; D2 () : B (m_dm2) { ...} ... };

haven't I effectively made m_bm a virtual data member of class B?

-- jP --

In article <george.804368672@southstation.mvp.com> george@mvp.com (George
Mitchell) writes:
>
> [snip]
>
> There currently exists a body of information associated with each
> class: the addresses of its virtual member functions.  This infor-
> mation is:
>
> a. static (associated with the class, rather than with any instance
>    of the class);
>
> b. virtual (dependent upon the type of the object pointed to);
>
> c. data.
>
> As it happens, it is also:
>
> d. private;
>
> e. const;
>
> f. of the type pointer-to-function.
>
> All implementations of C++ must provide some means of fetching this
> static virtual data, given a pointer to an object.  If this means did
> not already exist, there would be no way of calling virtual member
> functions.
>
> So --
>
> Why not allow the data to be other types?  It could even be public,
> or non-const.  It's clear how to implement this for those compilers
> which use vtables: just put these new static virtual data members
> into the vtable, with the static virtual private const pointers-to-
> functions which are already in there.  But even implementations
> which don't use vtables *already have* static virtual data (in
> effect).
>
> -- George Mitchell (george@mvp.com)

Yes, it seems possible to implement (static) virtual data members. Maybe
this has been discussed before here, but just out of curiosity, I would
like to ask:

- Where will virtual data members be initialized? In some (derived)
constructor?
- Do you think we should have *abstract* virtual data members?
- What would the initialization syntax look like?
- Why do you think having (static) virtual data members would be useful?
Can you give an example?
- Do you have a view on how having (static) virtual data members would
affect C++ programming style? Do you see any new idioms they would
support?
- Do you think they'll introduce any new pitfalls into the language?

Thanks.

- Wil

In article <DAxp4s.4wJ@tigadmin.ml.com>,
Julian Pardoe LADS LDN X1428 <pardoej@lonnds.ml.com> wrote:

>I wondered if maybe my criteria for choosing between static and non-static
>members was screwed up and I should simply settle for non-static method.
>I need to think about this more, but I think I'm happy in saying that
>what I want is really
>   obj->GetClass()->StatusName (status)
>(where classes are objects to as in Smalltalk) rather than just
>   obj->StatusName (status)
>
>...but, pragmatically speaking, I can achieve what I want using a non-
>static method and the second syntax, so again, I wonder, what's all the
>fuss?  What would static virtual functions add?

They would add the guarantee that the functions wouldn't
use any non-static members of the class even when overridden by the
derived class (and of course nicer syntax).

>    class BM { ... }; class DM1 : public BM { ... };
>    class DM2 : public BM { ... };
>
>    class B { BM &m_bm; B (BM &bm) : m_bm (bm) {...} ... }:
>    class D1 : public B { DM1 m_dm1; D1 () : B (m_dm1) { ...} ... };
>    class D2 : public B { DM2 m_dm2; D2 () : B (m_dm2) { ...} ... };
>
>haven't I effectively made m_bm a virtual data member of class B?

Yes. More precisely, you have made m_bm an abstract non-static virtual
data member.

To get non-abstract (non-static) virtual data member, you have to write:

class B { BM &m_bm; BM actual_bm; B(BM& bm) : m_bm(bm) {...}
                                  B() : m_bm(actual_bm) {...} };

except that this makes it impossible to prevent actual_bm being
constructed when m_bm is overridden. Note that in your example,
deriving from D1 or D2 (and overriding the virtual data member)
also results in constructing the data member twice.

For static virtual data members, I think this does the trick:

class AM; class DAM /* : public AM */ ;

class A
{
  static AM real_a;
  AM& a;
public:
  A(AM& amember=real_a) : a(amember) {}
};

class DA : public A
{
  static DAM real_a;
public:
  DA() : A(real_a) {}
};
Now, you can use "a" as a virtual (in this case:private) data member.
But of course this wastes memory in every object.
--
   Esa Pulkkinen                        | C++ programmers do it virtually
   E-Mail:  esap@cs.tut.fi              | everywhere with a class, resulting
   WWW   :  http://www.cs.tut.fi/~esap/ | in multiple inheritance.

In article <george.804182373@southstation.mvp.com> george@mvp.com
(George Mitchell) writes:

|> bill_law@taligent.com (William A. Law) writes:
|> >Many times in the past half-dozen years I've encountered situations where
|> >static virtual seemed *essential*.

|> >Specifically, they can resolve to the most-derived class's implementation
|> >during the execution of base class constructors.  While static virtual
|> >functions provide some convenience as per your example, they are more or
|> >less essential in order to solve the problem of making object behavior,
|> >during construction, reasonably polymorphic.

|> I would second this, adding that I'd like static virtual data members
|> to be allowed, as well as function members.

Since there are currently no virtual data members, static or not, this
would be a major change.

|> The fact is, a vtable is effectively a static virtual data member of a
|> class.  It just happens to be restricted to pointers to member functions.

It also just happens not to be accessible to the programmer.  In fact,
there is no requirement in the standard that there be a vtable, and no
way a standard conforming program can determine whether one is present
or not.
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In article <bill_law-2306951038370001@bill-law.taligent.com>,
William A. Law <bill_law@taligent.com> wrote:
>
>A static virtual function would be called in the same way a non-virtual
>static function is called.  The call would be "virtual" (i.e., through a
>vtbl depending on the actual type of the object) when invoked via a
>reference or pointer.  One shouldn't forget that static member functions
>can be invoked using the same notation (anObject.staticFn(),
>anObjectPtr->staticFn()) as must be used for non-static member
>functions.

If I understand you correctly, that means that the call behaves differently
if the virtual static member function is called as f() or as x.f() inside
another member function, e.g.,

 struct T {
  virtual static f();
  g();
 };

 // Call g() for a derived object...

 T::g()
 {
  f();  // calls T::f
  this->f(); // calls derived::f
 }

This is not how other member functions work, and it seems like another
source of confusion without much gain.  Maybe you could come up with a
more convincing example.

      -- Dag Bruck
--
Dynasim AB                            Phone:  +46 46 182500
Research Park Ideon                   Fax:    +46 46 129879
S-223 70 Lund                         E-mail: Dag@Dynasim.se
Sweden

In article <3sqt1e$gkj@nils.ideon.lth.se>, dag@net.dynasim.se (Dag Bruck) wrote:

> If I understand you correctly, that means that the call behaves differently
> if the virtual static member function is called as f() or as x.f() inside
> another member function, e.g.,
>
>         struct T {
>                 virtual static f();
>                 g();
>         };
>
>         // Call g() for a derived object...
>
>         T::g()
>         {
>                 f();            // calls T::f
>                 this->f();      // calls derived::f
>         }
>
> This is not how other member functions work, and it seems like another
> source of confusion without much gain.  Maybe you could come up with a
> more convincing example.
>
>                                                 -- Dag Bruck
> --
> Dynasim AB                            Phone:  +46 46 182500
> Research Park Ideon                   Fax:    +46 46 129879
> S-223 70 Lund                         E-mail: Dag@Dynasim.se
> Sweden

I did not offer an opinion as to whether static virtual functions invoked
"implicitly" via the "this" pointer should be staticly or dynamically
dispatched.  I would prefer the latter.  That is, "f();" is equivalent to
"this->f();" (as is the case for non-static member function invocations).
I suppose it is arguable that this is a change in behavior for unadorned
static member function invocations, since "staticFn();" within a member
function of class X could today be explained as the equivalent of
"X::staticFn();".  However, it could also be explained as the equivalent
of "this->staticFn();" even if nobody thinks of it that way (and without
static virtual functions, there is no reason to).

As to the "gain," I will simply restate my desire to be able to reuse base
class constructor logic.  In GUI libraries, for example (a reasonably
important class of C++ libraries), there is typically lots of code behind
simple object definitions (synchronizing creation of C++ objects with
creation of GUI system windows, etc.).  One would like to be able to reuse
that code for derived classes without adding complex and error-prone
mechanisms (more complex and more error-prone than static virtual member
functions, I might add) to defer construction until entering the
most-derived class's constructor.

As further evidence, simply consider class methods in Smalltalk.  These
are equivalent (in most respects) to static virtual C++ member functions
and certainly have demonstrated their utility in that context.

Bill Law

>>>>> William A Law <bill_law@taligent.com> writes:

> I did not offer an opinion as to whether static virtual functions invoked
> "implicitly" via the "this" pointer should be staticly or dynamically
> dispatched.  I would prefer the latter.  That is, "f();" is equivalent to
> "this->f();" (as is the case for non-static member function invocations).
> I suppose it is arguable that this is a change in behavior for unadorned
> static member function invocations, since "staticFn();" within a member
> function of class X could today be explained as the equivalent of
> "X::staticFn();".  However, it could also be explained as the equivalent
> of "this->staticFn();" even if nobody thinks of it that way (and without
> static virtual functions, there is no reason to).

Yes, there is.

struct A {
  static void f ();
};

struct B: private A { };
struct C: public B {
  void g () { f(); } // equivalent to this->f(); ill-formed
  void h () { A::f(); } // OK
};

(not that I am in favor of static virtuals, mind you)

Jason

In article <3sqt1e$gkj@nils.ideon.lth.se> dag@net.dynasim.se (Dag
Bruck) writes:

|> In article <bill_law-2306951038370001@bill-law.taligent.com>,
|> William A. Law <bill_law@taligent.com> wrote:

|> >A static virtual function would be called in the same way a non-virtual
|> >static function is called.  The call would be "virtual" (i.e., through a
|> >vtbl depending on the actual type of the object) when invoked via a
|> >reference or pointer.  One shouldn't forget that static member functions
|> >can be invoked using the same notation (anObject.staticFn(),
|> >anObjectPtr->staticFn()) as must be used for non-static member
|> >functions.

|> If I understand you correctly, that means that the call behaves differently
|> if the virtual static member function is called as f() or as x.f() inside
|> another member function, e.g.,

|>  struct T {
|>   virtual static f();
|>   g();
|>  };

|>  // Call g() for a derived object...

|>  T::g()
|>  {
|>   f();  // calls T::f
|>   this->f(); // calls derived::f
|>  }

Actually, *if* static virtual functions were to be accepted, I would
expect them to be virtual except when called with a scope resolution
operator.  Thus, in g, above:

 T::g()
 {
     f() ;               //  virtual call
     this->f() ;         //  virtual call
     T::f() ;            //  non-virtual call
     this->T::f() ;      //  non-virtual call
 }

--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:

James>In article <george.804182373@southstation.mvp.com> george@mvp.com
James>(George Mitchell) writes:

George> I would second this, adding that I'd like static virtual data members
George> to be allowed, as well as function members.

James>Since there are currently no virtual data members, static or not, this
James>would be a major change.

In fact, it wouldn't.  Please see below.

George> The fact is, a vtable is effectively a static virtual data member of a
George> class.  It just happens to be restricted to pointers to member functions.

James>It also just happens not to be accessible to the programmer.  In fact,
James>there is no requirement in the standard that there be a vtable, and no
James>way a standard conforming program can determine whether one is present

This is correct, so let me rephrase what I was saying as follows:

There currently exists a body of information associated with each
class: the addresses of its virtual member functions.  This infor-
mation is:

a. static (associated with the class, rather than with any instance
   of the class);

b. virtual (dependent upon the type of the object pointed to);

c. data.

As it happens, it is also:

d. private;

e. const;

f. of the type pointer-to-function.

All implementations of C++ must provide some means of fetching this
static virtual data, given a pointer to an object.  If this means did
not already exist, there would be no way of calling virtual member
functions.

So --

Why not allow the data to be other types?  It could even be public,
or non-const.  It's clear how to implement this for those compilers
which use vtables: just put these new static virtual data members
into the vtable, with the static virtual private const pointers-to-
functions which are already in there.  But even implementations
which don't use vtables *already have* static virtual data (in
effect).

-- George Mitchell (george@mvp.com)

The examples to this subject show that the ambigous notation in C++ is the
reason for the desire of static virtual functions.

Static member functions are class members and not instance members.

In article <3s847j$ktq@engnews2.Eng.Sun.COM> Steve Clamage
(stephen.clamage@eng.sun.com) writes:
> donorgan@ix.netcom.com (Don Organ) writes:
>
> >The draft specifically prohibits static member functions from being
> >virtual (class.static.mfct - Section 9.5.1). The ARM also has such a
> >prohibition(section 9.4).
>
> > ...
>
> >However, I don't see any conflict with static virtuals - I believe
> >they would be implemented in an obvious and natural way:
> >    1) the function body (definition) is implemented as a static (has
> >        no "this" pointer).
> >    2) it has a vtbl entry for all objects of the class.
> >If called using the :: syntax (i.e. class::function()), then the
> >'virtual-ness' of the function is unimportant. If an object exists,
> >the it can be called using the . or -> operators - via the vtbl.
>
> There is no technical reason (that I know of) why virtual static could
> not be added to the language. Virtual data could also be added.
> Both have been suggested informally before.
>
> As explained in D&E ("Remember the Vasa!"), not every neat feature
> can be added to C++. Each suggestion has to be evaluated for
> cost and benefit, including the overall cost in complexity and
> in documenting and teaching C++. This is one of many items that
> were not judged important enough to add. Reasonable people may
> disagree about any particular evaluation, of course.

I think dropping the restriction that says static member functions can't
be virtual should be considered a simplification of the language rather
than an addition to it. The implementation seems trivial, and each special
case that can be removed from the language definition actually decreases
the cost of documenting and training C++. What's more, there are examples
that show static virtual member functions could be a useful thing to have.

- Wil

Erik Weidinger (weidinger.muc@sni.de) wrote:

|> The examples to this subject show that the ambigous notation in C++ is the
|> reason for the desire of static virtual functions.

|> Static member functions are class members and not instance members.

|> From the object-oriented point of view a call of a class method results
|> in a message to a class and not to an instance, even if the notation in
|> C++ can use a reference to an instance to specify the class and thus looks like
|> a message to the object instance. In fact, no instance plays a role in a
|> class method call (except if You regard a class as another object instance).

That is exactly what we are arguing about.

Before RTTI, virtual functions were regularly used to emulate RTTI.
Since the RTTI as standardized is not really usable for persistency or
transportability, I expect such uses to continue.

Similarly, in container classes, I tend to make the functions to delete
or to construct an element virtual on the container, and not on the
contained elements.  (If you have a container of int's, for example,
this can result in significant memory savings, since the contained
elements do not need a vptr.)

In both cases, the member function is a class member function, *but* an
actual object is used to determine what the class in question is.  In
both cases, the function must be virtual, in order for the correct
function to be selected, but has no need of the this pointer *once*
*called*.

In practice, I work on a Sun; parameters (including the this pointer)
are passed in registers, and it is necessary to load the this pointer
into a register in order to access the vptr anyway.  So, except for the
extremely unlikely case of register pressure in the called function,
there is no run-time overhead just leaving them virtual (and forgetting
the static).

Is this true for all machines, or am I just lucky, and programmers on
other machines are paying for something they are not using.
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle--
                             --Beratung in industrieller Datenverarbeitung

bill_law@taligent.com (William A. Law) writes:
>Many times in the past half-dozen years I've encountered situations where
>static virtual seemed *essential*.

>Specifically, they can resolve to the most-derived class's implementation
>during the execution of base class constructors.  While static virtual
>functions provide some convenience as per your example, they are more or
>less essential in order to solve the problem of making object behavior,
>during construction, reasonably polymorphic.

I would second this, adding that I'd like static virtual data members
to be allowed, as well as function members.

The fact is, a vtable is effectively a static virtual data member of a
class.  It just happens to be restricted to pointers to member functions.

-- George Mitchell (george@mvp.com)

In article <3slq9d$4m9@horus.mch.sni.de>, weidinger.muc@sni.de (Erik Weidinger) writes:
|> The examples to this subject show that the ambigous notation in C++ is the
|> reason for the desire of static virtual functions.

IMO the notation is clear:
'.' and '->' is used for (potentially) dynamic binding (of instancemethods
             and of classmethods - here 'static virtual' fills a hole) and
'::'         is used to force static binding in an context where the
             instance is clear:
   - a->A::m1(): can be a real _instance_ method.
   - A::m2() when being inside the implementation of an instancemethod of A
     or any descendant: can be a real _instance_ method.
   - Else: Can not be a instancemethod but only a classmethod.

|>
|> Static member functions are class members and not instance members.

AFAIK, in the words of C++ there are only 'class memberfunctions' ('static' and
'nonstatic', 'virtual' and 'nonvirtual' ones) and no 'instance memberfunctions'
in C++.

|>
|> From the object-oriented point of view a call of a class method results
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
There is no one-and-only exact definition of what object-orientatoion is.
In common usage you won't notice this but when going into details you'll
find subtile differences.

|> in a message to a class and not to an instance, even if the notation in
        ^^^^^^^^^^^^^^^^^^
The result is that each OOPL makes up it's own model of object-orientation.
And in C++ (and Eiffel etc, in contrary to ST, Self maybe also ObjectiveC etc)
there is no notion of a class(-object) that could be the reciepiant of a message.

|> C++ can use a reference to an instance to specify the class and thus looks like
|> a message to the object instance. In fact, no instance plays a role in a
|> class method call (except if You regard a class as another object instance).

I've no problem in seeing A::m() as a (in terms of ST) message to the class
and a->m() as a message to an instance. If the instance does (statically) not
'understand' the message then the message is forwarded to the class.
In C++ there exists the distinction between static (not to mixup with the keyword)
and dynamic (virtual) binding.

Why should an instance be disallowed
to bind a classmethod to it's dynamic implementation
while it is able to bind a instancemethod to it's dynamic implementation?
[ In terms of C++: ... to bind a static memberfunction virtually
while it is able to bind a nonstatic memberfunction virtually? ]


Ulf Schuenemann

--------------------------------------------------------------------
Ulf Sch   nemann
Fakult   t f   r Informatik, Technische Universit   t M   nchen, Germany.
email: schuenem@informatik.tu-muenchen.de

In article <3sefsf$si6@horus.mch.sni.de>, weidinger.muc@sni.de (Erik
Weidinger) wrote:

> I don't understand this discussion.
>
> When do you expect a static virtual function to be called ?
> The purpose of virtual functions is to bind methods to calls at runtime.
> This binding depends on the actual class of the object instance.
>
> What could be the purpose of static virtual functions then ?

A static virtual function would be called in the same way a non-virtual
static function is called.  The call would be "virtual" (i.e., through a
vtbl depending on the actual type of the object) when invoked via a
reference or pointer.  One shouldn't forget that static member functions
can be invoked using the same notation (anObject.staticFn(),
anObjectPtr->staticFn()) as must be used for non-static member
functions.

Here's a simple example:

struct Base {
static virtual char *className() { return "Base"; }
Base() { cout << "Making a " << className() << endl; }
};

struct Derived {
static virtual char *className() { return "Derived"; }
};

int main() {
  Base b;    // Outputs "Making a Base"
  Derived d; // Outputs "Making a Derived"
  Base::className(); // Calls Base::className().
  B *bp = &d;
  bp->className();    // Calls Derived::className().
  bp->Base::className(); // Calls Base::className()
  return 0;
}

I don't understand this discussion.

When do you expect a static virtual function to be called ?
The purpose of virtual functions is to bind methods to calls at runtime.
This binding depends on the actual class of the object instance.

What could be the purpose of static virtual functions then ?

In article <3scaod$9vs@sunsystem5.informatik.tu-muenchen.de>, schuenem@informatik.tu-muenchen.de (Ulf Schuenemann) writes:

-=)> I see the following 3 kinds of memberfunctions:
-=)>  - normal: reads + writes the instance (this)
-=)>  - const: reads the instance (this)
-=)>  - static: neither reads nor writes the instace (this)
-=)> Besides of the difference in read/write-permissions they are the same.
-=)> The static ones have an additional benifit: as they neither read nor
-=)> write the instace, they don't need and thus don't have the this-pointer,
-=)> and so they can also be called, even where there is no object at all.
-=)> But unfortunately given this IMHO straightforward interpretation,
-=)> there is a hole (un-othogonality) regarding virtual memberfunctions:
-=)>  - normal: reads + writes the instance (this)
-=)>  - const: reads the instance (this)
-=)> (1) For the sake of completness and
-=)> (2) as static virtual memfcts _are_ usefull (see the other articles) and
-=)> (3) as no-one has shown me that it's difficult to implement them and
-=)> (4) as (AFAIK) no-one has claimed that they'd break old code,
-=)> I'd appreciate the introduction of static virtual memfcts.
-=)> Ulf Schuenemann
-=)> --------------------------------------------------------------------

  In Delphi, there are static virtual functions; really useful. exemple :


  BorderStyle = class( ... )
  end;

   BorderStyleClass  = class of BorderStyle;

  BorderStyleNice = class( BorderStyle )
  end;

  Window = class
    constructor Create( BorderStyle border );
    function GetBorderClass : BorderStyleClass; virutal; static;
    begin
      return BorderStyle;  // a class, not an object !!
    end;
  end;

  WindowClass = class of Window;

  WindowNice = class( Window )
    function GetBorderClass : BorderStyleClass; virutal; static;
    begin
       return BorderStyleNice;
    enmd;
  end;


  function MakeWindow( cls : WindowClass ) : Window;
  var
   w : Window;
  begin
     w := cls.Create( cls.GetBorderClass );  // more usefule RTII than C++
     result := w;
  end;



 I really think there VERY interesting features in Delphi, even if the language
itself is not as coherent as C++.
  Of course, you can do that in C++, but even in assembler. Things are easier
with Delphi, and a big lake of C++, when you compare it with Delphi, is the RTII
support.

  Don't you agree ? I would really be happy you give us your opinion, just to
show that C++ programers are not in a sect and they can admit that c++ in not
perfect.

 but don't cry, there is no overloading and no multiinheritance in Delphi...

In article <3s81l8$2ke@ixnews6.ix.netcom.com>,
Don Organ <donorgan@ix.netcom.com> wrote:
>
>My question is "why are static virtual member functions dis-allowed?"

I think that we may, at long last, have found a basis on which to start
building a comp.std.c++ FAQ.

(This particular question seems to be a perennial favorite.  It has
been discussed here many times before.)
--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- E-mail: rfg@segfault.us.com ----------- Purveyors of Compiler Test ----
---- finger: rfg@rahul.net ----------------- Suites and Bullet-Proof Shoes -

In article <3sgi0l$jdf@hustle.rahul.net>, rfg@rahul.net says...
>
>In article <3s81l8$2ke@ixnews6.ix.netcom.com>,
>Don Organ <donorgan@ix.netcom.com> wrote:
>>
>>My question is "why are static virtual member functions dis-allowed?"
>
>I think that we may, at long last, have found a basis on which to start
>building a comp.std.c++ FAQ.
>
>(This particular question seems to be a perennial favorite.  It has
>been discussed here many times before.)
>--
>
>-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting
@@@@@@@@@@@@@@@@@@@@@@@@@@@@

When you start this please add:

 Why isn't the @ sign allowed as an operator in C++?
  Why can't I program...point = 1234 @ 5678;...?

....@ = a method selector in Smalltalk and C+@
....@ = ROTFL in some countries
....@ = Cinnamon Bun in Sweden
....@ = AT&T = (AT)&(T) = (AT) because the second T is redundant...:)

...BTW...check out MCI's...(@BAT, @Fashion, etc...)

Also...we are looking for a name for an Internet C@fe...any suggestions?

--
Jim Fleming            /|\      Unir Corporation       Unir Technology, Inc.
jrf@tiger.bytes.com  /  | \     One Naperville Plaza   184 Shuman Blvd. #100
%Techno Cat I       /   |  \    Naperville, IL 60563   Naperville, IL 60563
East End, Tortola  |____|___\   1-708-505-5801         1-800-222-UNIR(8647)
British Virgin Islands__|______ 1-708-305-3277 (FAX)   1-708-305-0600
                 \__/-------\__/       http:199.3.34.13 telnet: port 5555
Smooth Sailing on Cruising C+@amarans  ftp: 199.3.34.12 <-----stargate----+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\____to the end of the OuterNet_|

In article <3s81l8$2ke@ixnews6.ix.netcom.com>, donorgan@ix.netcom.com (Don
Organ) wrote:

> Several times in the past half-dozen years I've encountered situations
> where static virtual seemed desirable.

Many times in the past half-dozen years I've encountered situations where
static virtual seemed *essential*.

Specifically, they can resolve to the most-derived class's implementation
during the execution of base class constructors.  While static virtual
functions provide some convenience as per your example, they are more or
less essential in order to solve the problem of making object behavior,
during construction, reasonably polymorphic.

My impression is that this extension meets the criteria specified in
Stroustrup's D&E (p 149).  Tbere is of course, the one criteria that isn't
specified therein: can the proposal garner sufficient support of the
committee members to overcome inertia?  Too bad this feature was
arbitrarily prohibited at the beginning.  Had it not, people would have a
much harder time coming up with reasons to remove it.  But that's life.

Bill Law

I see the following 3 kinds of memberfunctions:

 - normal: reads + writes the instance (this)
 - const: reads the instance (this)
 - static: neither reads nor writes the instace (this)

Besides of the difference in read/write-permissions they are the same.

The static ones have an additional benifit: as they neither read nor
write the instace, they don't need and thus don't have the this-pointer,
and so they can also be called, even where there is no object at all.

But unfortunately given this IMHO straightforward interpretation,
there is a hole (un-othogonality) regarding virtual memberfunctions:

 - normal: reads + writes the instance (this)
 - const: reads the instance (this)

(1) For the sake of completness and
(2) as static virtual memfcts _are_ usefull (see the other articles) and
(3) as no-one has shown me that it's difficult to implement them and
(4) as (AFAIK) no-one has claimed that they'd break old code,

I'd appreciate the introduction of static virtual memfcts.


Ulf Schuenemann

--------------------------------------------------------------------
Ulf Sch   nemann
Fakult   t f   r Informatik, Technische Universit   t M   nchen, Germany.
email: schuenem@informatik.tu-muenchen.de

The draft specifically prohibits static member functions from being
virtual (class.static.mfct - Section 9.5.1). The ARM also has such a
prohibition(section 9.4).

My question is "why are static virtual member functions dis-allowed?"

I could find no justification in the ARM, D&E or the Draft. The
statement "a static member function does not have a this pointer"
proceeds the prohibition in both the ARM and Draft. I presume the
thinking was "virtual functions require an object, static member
functions aren't associated with an object, therefore these are
mutually exclusive".

However, I don't see any conflict with static virtuals - I believe
they would be implemented in an obvious and natural way:
    1) the function body (definition) is implemented as a static (has
        no "this" pointer).
    2) it has a vtbl entry for all objects of the class.
If called using the :: syntax (i.e. class::function()), then the
'virtual-ness' of the function is unimportant. If an object exists,
the it can be called using the . or -> operators - via the vtbl.

Several times in the past half-dozen years I've encountered situations
where static virtual seemed desirable. Perhaps half were to solve
problems
that RTTI now solves. Others were related to persistence or to
help/documentation/debug capabilities. Conceptually, I use a static
member function to provide information about a class. It makes sense
that I could issue this request either directly to the class or
indirectly through an object.

I'd like to be able to do the following:

// Illegal in Draft & ARM
struct shape { static virtual void Help(); /* ... */ }
struct circle : public shape { static virtual void Help(); /* ... */ }
struct square : public shape { static virtual void Help(); /* ... */ }

void f(shape *p)
{
    p->Help();
    shape::Help();
    circle::Help();
}

As the Draft stands, I have to do it this way:
struct shape {
    static void StaticHelp();
    virtual void Help() { StaticHelp(); }
    /* ... */
}
struct circle : public shape {
    static void StaticHelp();
    virtual void Help() { StaticHelp(); }
    /* ... */
}
struct square : public shape {
    static void StaticHelp();
    virtual void Help() { StaticHelp(); }
    /* ... */
}

Not a major inconvience certainly. But somewhat tedious, somewhat
error-prone and somewhat more of the Huh? factor for someone reading
the code.
This is one of the few places where C++ has coupled capabilities
that I feel are orthogonal.


Don Organ
donorgan@ix.netcom.com

donorgan@ix.netcom.com (Don Organ) writes:

>The draft specifically prohibits static member functions from being
>virtual (class.static.mfct - Section 9.5.1). The ARM also has such a
>prohibition(section 9.4).

> ...

>However, I don't see any conflict with static virtuals - I believe
>they would be implemented in an obvious and natural way:
>    1) the function body (definition) is implemented as a static (has
>        no "this" pointer).
>    2) it has a vtbl entry for all objects of the class.
>If called using the :: syntax (i.e. class::function()), then the
>'virtual-ness' of the function is unimportant. If an object exists,
>the it can be called using the . or -> operators - via the vtbl.

There is no technical reason (that I know of) why virtual static could
not be added to the language. Virtual data could also be added.
Both have been suggested informally before.

As explained in D&E ("Remember the Vasa!"), not every neat feature
can be added to C++. Each suggestion has to be evaluated for
cost and benefit, including the overall cost in complexity and
in documenting and teaching C++. This is one of many items that
were not judged important enough to add. Reasonable people may
disagree about any particular evaluation, of course.

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

Why are static virtual functions illegal?  This would be useful for
functions such as `virtual int SymbolTable::compare(char *, char *)'.
It's a waste to pass a pointer to `this' to those functions.

And while I'm writing: How about static virtual variables?  These would
be useful for per-class data such as a "description" fields for a class.
Maybe only const variables should be allowed though.
--

Hallvard