And Responder #3.
Summary: investigate writing your own string_fwd.h header file.
Angus
,--------------- Forwarded message (begin)
Subject: Re: class String : public std::string {}; ????
From: Ivan Vecerina <[EMAIL PROTECTED]>
Date: Wed, 10 Sep 2003 16:43:55 +0000
Hi Angus,
| Could someone explain to me why the Standard conveners chose to typedef
| std::string rather than derive it from std::basic_string<char, ...>?
Two reasons I can see:
- If this were done, template code that uses std::basic_string<ACharType>
would be using a different string class than your non-template code ?
Or some special policy classes would be needed...
- If such derivation was used, std::basic_string would need a virtual
destructor.
| The result of course is that it is effectively impossible to forward
declare
| std::string. (Yes I am aware that some libraries have a string_fwd.h
header,
| but this is not portable.)
True. Note that adding such a header yourself is an option even for
implementations that do not support it...
| That said, is there any real reason why I can't derive an otherwise empty
| String class from std::string? Will there be any hidden surprises? As I
| understand it, the fact that String has no member variables of its own
| means that the non-virtual std::string destructor is not an issue.
It *might* not be an issue in most C++ implementations. But formally,
it still does lead to undefined behavior when used improperly.
The following related discussion might be of interest:
http://www.gotw.ca/publications/mill18.htm
| Nonetheless, I'm wary because I have heard so much about 'std::string is
not
| designed to be derived from'. Nobody has explained the rationale behind
such
| a statement to me however.
The public non-virtual destructor remains the key issue.
Another caveat is the too many member functions of std::string,
which may at some point create conflicts...
Most of the time, people who want to derive from std::string also want to
add some state/data members to it (in which case containment is a better
idea, as it allows to enforce class invariants), or add some member
functions (in that case, non-member functions should be preferred).
Public derivation from std::string has serious caveats,
and is often done by novices for these wrong reasons.
And indeed, I have yet to see a good motivation for deriving from
std::string...
| Below is sample code that appears to work just fine.
From a quick look through the code it seems ok and will not invoke UB.
However, is it worth defining your own class just to be
able to forward-declare it ?
Force any maintainers to use an additional non-standard class,
and deal with (even implicit) conversions ?
Personally, if compile-time overhead was a read problem,
would rather implement a custom <string_fwd.h> header for
each platform I am using...
Regards,
Ivan
--
http://ivan.vecerina.com
Brainbench MVP for C++ <> http://www.brainbench.com
`--------------- Forwarded message (end)
