Natale Fietta wrote:
> On Fri, 24 May 2002 18:03:11 GMT, Howard Gardner <usenet@hgardner.com>
> wrote:
>
>
>>The point of the exercise is, in fact, to allow safe inheritance of the
>>implementation of std::basic_string (and all the containers too).
>
> [cut]
>
>>The fact that the version with the virtual destructor and the version
>>without the virtual destructor aren't related isn't of great concern to
>>me. The point of the exercise (as far as I'm concerned) is to leverage
>>the existing implementation when creating a new type: I never expected
>>the type to be substitutable for std::string.
>
>
> Sorry, now i am really confused, if you are not interested in
> polimorphic behaviour why do you want to virtualize anything ?
>
> Maybe i misunderstood the problem you want to solve, can you make a
> pratical example ?

The object of the exercise is to reduce the amount of effort required to
create new types based on the library types. Right now, it's more
painful than it should be.

Say you want to add a "Proper Casing" feature, which makes sure that the
first letter of every word in a string is uppercase. As things sit, you
might write a free function to do it, and that function might accept an
std::basic_string<...> &.

You might prefer to have a type proper_string<...> that has a
"ProperCase" function, though. If it were possible to virtualize the
destructors in std::basic_string<...>, then proper_string<...> can
publicly inherit from it and all you have to do is write the function
ProperCase. As things sit, in order to reuse the implementation of
std::basic_string<...>, proper_string<...> has to be a class full of
forwarding functions, and it's strictly because std::basic_string<...>'s
destructor isn't virtual.

You might prefer to have the "Proper Case" behavior built into the
assignment operator of proper_string<...>. The ability to
retro-virtualize ANY function in std::basic_string<...> would enable
that choice.

The story is much the same for the containers. They are remarkably
useful things, but they would be even more usefull if it were possible
to make some or all of the functions virtual. This discussion has
recurred often. I think that the approach I'm outlining would satisfy
most of the parties. I think that it can be done without breaking
existing code.

I've got to tell you, though, that I would prefer the "using
inheritance" approach that is being discussed in other threads.

--
I <3 Comeau C++: 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Fri, 24 May 2002 18:03:11 GMT, Howard Gardner <usenet@hgardner.com>
wrote:

>The point of the exercise is, in fact, to allow safe inheritance of the
>implementation of std::basic_string (and all the containers too).
[cut]
>The fact that the version with the virtual destructor and the version
>without the virtual destructor aren't related isn't of great concern to
>me. The point of the exercise (as far as I'm concerned) is to leverage
>the existing implementation when creating a new type: I never expected
>the type to be substitutable for std::string.

Sorry, now i am really confused, if you are not interested in
polimorphic behaviour why do you want to virtualize anything ?

Maybe i misunderstood the problem you want to solve, can you make a
pratical example ?

Regards,
Natale Fietta

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Natale Fietta wrote:
> On Fri, 17 May 2002 18:49:26 GMT, Howard Gardner <usenet@hgardner.com>
> wrote:
>
>
>>>Another little pitfall is the fact that some_class<virtual_destructor>
>>>and some_class<no_virtual_destructor> are unrelated class, but i
>>>suppose this is not a serious problem.
>>
>
>>Yet another paragraph or subsection in tutorials on the STL. At least
>>the explanation would be shorter than the "publicly inheriting from a
>>standard container is perilous" discussion.
>
>
> I've changed my mind... :-/
> it IS a serious problem.
>
> AFAIK the primary reason we want a virtual destructor in std::string
> (or others std classes) is to (publicly) derive another string class
> (call it UserString) so that UserString IS_A std::string.
> we want this to be able to use UserString polimorphically in each
> situation a std::string is used. (OK, i admit there is another
> possible reason we want this also whitout polimorphic behaviour: to
> have the same interface of std::string whitout the manual forwarding
> of each member function, but i think this is not a sufficient reason
> to use public derivation, for this situation i like better the "using
> derivation" proposed in the thread "Proposal for a new type of
> inheritance").
>
> The proposed "virtualization" tecnique solve the problem whitout
> forcing a virtual destructor for non polimorphic uses of std::string,
> so we are all happy...
>
> Wait a moment ! something do not work. In our scenario std::string (i
> suppose for backward compatibility the default string type is the non
> polimorphic) is a typedef for std::basic_string<no_virtual_destructor>
> (i omit other template parameters for clarity), UserString instead is
> derived from std::basic_string<virtual_destructor> so we have gained
> nothing, UserString is still unrelated to std::string... :-(
>
> An attempted solution can be to have implicit conversion operators
> betwen string<virtual> and string<no_virtual> (or maybe is sufficent
> implicit conversion from string<virtual> to string<no_virtual> whitout
> the opposite ?), but this can cause slicing of UserString...
>
> Please tell me there is a solutions i overlooked, i like the template
> derivation trick.

The point of the exercise is, in fact, to allow safe inheritance of the
implementation of std::basic_string (and all the containers too).

If allowing retro-virtualization (deriving publicly from the template
parameter ala Loki)is supportable, then it would be possible to overload
the existing members: some people might find that useful.

The fact that the version with the virtual destructor and the version
without the virtual destructor aren't related isn't of great concern to
me. The point of the exercise (as far as I'm concerned) is to leverage
the existing implementation when creating a new type: I never expected
the type to be substitutable for std::string.

I like the "using inheritance" too, but it is not necessary to address this.

--
I <3 Comeau C++: 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Howard Gardner <usenet@hgardner.com> wrote:

>Natale Fietta wrote:
>> On Fri, 17 May 2002 18:49:26 GMT, Howard Gardner <usenet@hgardner.com>
>> wrote:
>>
>>
>>>>Another little pitfall is the fact that some_class<virtual_destructor>
>>>>and some_class<no_virtual_destructor> are unrelated class, but i
>>>>suppose this is not a serious problem.
>>>
>>
>>>Yet another paragraph or subsection in tutorials on the STL. At least
>>>the explanation would be shorter than the "publicly inheriting from a
>>>standard container is perilous" discussion.
>>
>>
>> I've changed my mind... :-/
>> it IS a serious problem.
>>
>> AFAIK the primary reason we want a virtual destructor in std::string
>> (or others std classes) is to (publicly) derive another string class
>> (call it UserString) so that UserString IS_A std::string.
>> we want this to be able to use UserString polimorphically in each
>> situation a std::string is used. (OK, i admit there is another
>> possible reason we want this also whitout polimorphic behaviour: to
>> have the same interface of std::string whitout the manual forwarding
>> of each member function, but i think this is not a sufficient reason
>> to use public derivation, for this situation i like better the "using
>> derivation" proposed in the thread "Proposal for a new type of
>> inheritance").
>>
>> The proposed "virtualization" tecnique solve the problem whitout
>> forcing a virtual destructor for non polimorphic uses of std::string,
>> so we are all happy...
>>
>> Wait a moment ! something do not work. In our scenario std::string (i
>> suppose for backward compatibility the default string type is the non
>> polimorphic) is a typedef for std::basic_string<no_virtual_destructor>
>> (i omit other template parameters for clarity), UserString instead is
>> derived from std::basic_string<virtual_destructor> so we have gained
>> nothing, UserString is still unrelated to std::string... :-(
>>
>> An attempted solution can be to have implicit conversion operators
>> betwen string<virtual> and string<no_virtual> (or maybe is sufficent
>> implicit conversion from string<virtual> to string<no_virtual> whitout
>> the opposite ?), but this can cause slicing of UserString...
>>
>> Please tell me there is a solutions i overlooked, i like the template
>> derivation trick.
>
>The point of the exercise is, in fact, to allow safe inheritance of the
>implementation of std::basic_string (and all the containers too).
>
>If allowing retro-virtualization (deriving publicly from the template
>parameter ala Loki)is supportable, then it would be possible to overload
>the existing members: some people might find that useful.
>
>The fact that the version with the virtual destructor and the version
>without the virtual destructor aren't related isn't of great concern to
>me. The point of the exercise (as far as I'm concerned) is to leverage
>the existing implementation when creating a new type: I never expected
>the type to be substitutable for std::string.
>
>I like the "using inheritance" too, but it is not necessary to address this.

  Not necessary, but sufficient... if it were adopted, of course.

--
Steve Heller
http://www.steveheller.com
Author of "Learning to Program in C++", "Who's Afraid of C++?", "Who's Afraid of More C++?",
"Optimizing C++", and other books
Free online versions of "Who's Afraid of C++?" and "Optimizing C++" are now available
at http://www.steveheller.com/whos and http://www.steveheller.com/opt

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Fri, 17 May 2002 18:49:26 GMT, Howard Gardner <usenet@hgardner.com>
wrote:

>> Another little pitfall is the fact that some_class<virtual_destructor>
>> and some_class<no_virtual_destructor> are unrelated class, but i
>> suppose this is not a serious problem.

> Yet another paragraph or subsection in tutorials on the STL. At least
> the explanation would be shorter than the "publicly inheriting from a
> standard container is perilous" discussion.

I've changed my mind... :-/
it IS a serious problem.

AFAIK the primary reason we want a virtual destructor in std::string
(or others std classes) is to (publicly) derive another string class
(call it UserString) so that UserString IS_A std::string.
we want this to be able to use UserString polimorphically in each
situation a std::string is used. (OK, i admit there is another
possible reason we want this also whitout polimorphic behaviour: to
have the same interface of std::string whitout the manual forwarding
of each member function, but i think this is not a sufficient reason
to use public derivation, for this situation i like better the "using
derivation" proposed in the thread "Proposal for a new type of
inheritance").

The proposed "virtualization" tecnique solve the problem whitout
forcing a virtual destructor for non polimorphic uses of std::string,
so we are all happy...

Wait a moment ! something do not work. In our scenario std::string (i
suppose for backward compatibility the default string type is the non
polimorphic) is a typedef for std::basic_string<no_virtual_destructor>
(i omit other template parameters for clarity), UserString instead is
derived from std::basic_string<virtual_destructor> so we have gained
nothing, UserString is still unrelated to std::string... :-(

An attempted solution can be to have implicit conversion operators
betwen string<virtual> and string<no_virtual> (or maybe is sufficent
implicit conversion from string<virtual> to string<no_virtual> whitout
the opposite ?), but this can cause slicing of UserString...

Please tell me there is a solutions i overlooked, i like the template
derivation trick.

Regards,
Natale Fietta

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]