Hi, Sometime ago there was discussion about an "enhanced" Boost.String (super_string) library from Jeff. Has there been any interest in this as-of lately? Is there possibilility that it will be get included in Boost? It sure will attract the attention of c++ novices. Also Jeff: Are most of the interfaces for string_algo implemented in your super_string library from RC_1.34? Thanks Shams
shams wrote:
Hi,
Sometime ago there was discussion about an "enhanced" Boost.String (super_string) library from Jeff.
Has there been any interest in this as-of lately?
Nope...it's gone quiet.
Is there possibilility that it will be get included in Boost? It sure will attract the attention of c++ novices.
I'm unsure I want to bring it to a review. The discussion over the summer was very divided. I feel strongly that it's useful and I think I swayed some doubters, but there is a hard-core group that opposes the approach. So, I don't want to waste my time preparing something for review that is doomed. So I might prefer to maintain it as an unofficial 'boost extension'...
Also Jeff: Are most of the interfaces for string_algo implemented in your super_string library from RC_1.34?
It's a subset, and yes they are implemented on top of 1.34 RC. Note that some of the functions use Boost.Regex and Boost.format as well. Jeff
shams wrote:
Hi,
Sometime ago there was discussion about an "enhanced" Boost.String (super_string) library from Jeff.
Has there been any interest in this as-of lately?
Personally I think only a few things are actually useful, and I wouldn't want to introduce a new string type just for that. If we had to introduce a new string type, I would prefer it if it didn't inherit from the caveats of std::string. Something more flexible might be an interesting base.
loufoque wrote:
shams wrote:
Hi,
Sometime ago there was discussion about an "enhanced" Boost.String (super_string) library from Jeff.
Has there been any interest in this as-of lately?
Personally I think only a few things are actually useful, and I wouldn't want to introduce a new string type just for that.
Why? What would be wrong if we had a plethora of string types (eg: sgi::rope) to select from to meet our programming needs in different contexts? We have container types galore -- that's very useful. I think this sort of thinking is a contributor to a lack of C++ libraries....
If we had to introduce a new string type, I would prefer it if it didn't inherit from the caveats of std::string.
Super string v2 provides an alternative version that extends the proposed boost::const_string. I did this to mollify the objection that std::string (actually basic_string) with it's mutable interface was an inappropriate base. See: http://www.crystalclearsoftware.com/libraries/super_string/classbasic__const... Honestly though, I think the advantages of using something other than std::string are minor. The main reason is that std::string is widely used in existing interfaces and code. So a core goal of the library is that you can use super_string in some code and then seamlessly pass that instance to existing interfaces written in terms of std::string for zero cost. So you don't have to commit to using super_string everywhere, just where you need it. I actually address that in the FAQ: http://www.crystalclearsoftware.com/libraries/super_string/index.html#why_ba...
Something more flexible might be an interesting base.
Such as? What features would it have that would make it more flexible? Anyway, it's having to fight this sort of 'generic criticism' that makes me reluctant to bring the library to review. I have this feeling that we won't have a true discussion of the interfaces people actually need in a string to get things done. Jeff
"Jeff Garland" <jeff@crystalclearsoftware.com> wrote
Why? What would be wrong if we had a plethora of string types (eg: sgi::rope) to select from to meet our programming needs in different contexts? We have container types galore -- that's very useful. I think this sort of thinking is a contributor to a lack of C++ libraries....
I don't think there is such thing as "a lack of C++ libraries". It's just a few _key_ libraries are missing.
Honestly though, I think the advantages of using something other than std::string are minor. The main reason is that std::string is widely used in existing interfaces and code. So a core goal of the library is that you can use super_string in some code and then seamlessly pass that instance to existing interfaces written in terms of std::string for zero cost.
Not exactly... the cost would be runtime -- to allocate a copy of the string. You wouldn't be able to pass anything other than "std::string" to "const std::string&" without copying it first, would you? Regards, Arkadiy
On 10/12/06, Arkadiy Vertleyb <vertleyb@hotmail.com> wrote:
"Jeff Garland" <jeff@crystalclearsoftware.com> wrote
So a core goal of the library is that you can use super_string in some code and then seamlessly pass that instance to existing interfaces written in terms of std::string for zero cost.
Not exactly... the cost would be runtime -- to allocate a copy of the string. You wouldn't be able to pass anything other than "std::string" to "const std::string&" without copying it first, would you?
Anything derived from std::basic_string<char> would work too. Super String is: template<class char_type > class basic_super_string : public std::basic_string<char_type> So there would be no copies. -- Caleb Epstein
Caleb Epstein wrote:
On 10/12/06, Arkadiy Vertleyb <vertleyb@hotmail.com> wrote:
"Jeff Garland" <jeff@crystalclearsoftware.com> wrote
So a core goal of the library is that you can use super_string in some code and then seamlessly pass that instance to existing interfaces written in terms of std::string for zero cost. Not exactly... the cost would be runtime -- to allocate a copy of the string. You wouldn't be able to pass anything other than "std::string" to "const std::string&" without copying it first, would you?
Anything derived from std::basic_string<char> would work too. Super String is:
template<class char_type > class basic_super_string : public std::basic_string<char_type>
So there would be no copies.
Exactly right. Jeff
"Jeff Garland" <jeff@crystalclearsoftware.com> wrote
Caleb Epstein wrote:
On 10/12/06, Arkadiy Vertleyb <vertleyb@hotmail.com> wrote:
"Jeff Garland" <jeff@crystalclearsoftware.com> wrote
So a core goal of the library is that you can use super_string in some code and then seamlessly pass that instance to existing interfaces written in terms of std::string for zero cost. Not exactly... the cost would be runtime -- to allocate a copy of the string. You wouldn't be able to pass anything other than "std::string" to "const std::string&" without copying it first, would you?
Anything derived from std::basic_string<char> would work too. Super String is:
template<class char_type > class basic_super_string : public std::basic_string<char_type>
So there would be no copies.
Exactly right.
I didn't realise that it's derived from the standard string, sorry. However, this will bring other problems. First, traits designed for std::string will not work for this new class. More importantly, according to the standard, the basic_string class destructor is not virtual, and so basic_string is not intended for derivation. As far as I can remember, deriving from a standard container has always been considered a bad practice... Regards, Arkadiy
On 10/12/06, Arkadiy Vertleyb <vertleyb@hotmail.com> wrote:
More importantly, according to the standard, the basic_string class destructor is not virtual, and so basic_string is not intended for derivation.
Wouldn't this only matter if super_string added data members (it doesn't AFAICT) and was being deleted via pointers to std::basic_string? -- Caleb Epstein
Caleb Epstein wrote:
On 10/12/06, Arkadiy Vertleyb <vertleyb@hotmail.com> wrote:
More importantly, according to the standard, the basic_string class destructor is not virtual, and so basic_string is not intended for derivation.
Wouldn't this only matter if super_string added data members (it doesn't AFAICT) and was being deleted via pointers to std::basic_string?
Yes, not having any data members in the subclass makes the destructor a no-op. Someone has pointed out that *technically* the behavior is undefined by the standard. But in reality what happens is, well, nothing. The empty subclass destructor is not called -- so there is no effect. It works on all C++ compilers that I'm aware of. Jeff
"Jeff Garland" <jeff@crystalclearsoftware.com> wrote
Caleb Epstein wrote:
On 10/12/06, Arkadiy Vertleyb <vertleyb@hotmail.com> wrote:
More importantly, according to the standard, the basic_string class destructor is not virtual, and so basic_string is not intended for derivation.
Wouldn't this only matter if super_string added data members (it doesn't AFAICT) and was being deleted via pointers to std::basic_string?
Yes, not having any data members in the subclass makes the destructor a no-op. Someone has pointed out that *technically* the behavior is undefined by the standard. But in reality what happens is, well, nothing. The empty subclass destructor is not called -- so there is no effect. It works on all C++ compilers that I'm aware of.
Still, does it really seem like a good idea to do what the designers of the STL wanted to explicitly disallow... Why not define additional functionality externally? (I believe there was once a library in the Boost review queue called string_algo, or similar). This would be a better design choice, IMO. Regards, Arkadiy
Arkadiy Vertleyb wrote:
"Jeff Garland" <jeff@crystalclearsoftware.com> wrote
Still, does it really seem like a good idea to do what the designers of the STL wanted to explicitly disallow...
I don't believe any such intent was ever expressed by the standard committee. It's true that they explicitly avoided virtual functions in the standard library -- iostreams excepted. It's really Scott Meyers advice that drives the 'never inherit' from a base w/o a virtual destructor. As much as I generally agree with that advice the 'stateless' functional extension is a useful and portable technique in my experience.
Why not define additional functionality externally? (I believe there was once a library in the Boost review queue called string_algo, or similar). This would be a better design choice, IMO.
Ah, string_algo is part of boost and super_string uses it in the implementation just like it uses boost.regex and boost.format. It might be informative for you to go back and read the earlier email thread. http://lists.boost.org/Archives/boost/2006/07/107087.php Jeff
"Jeff Garland" <jeff@crystalclearsoftware.com> wrote
Arkadiy Vertleyb wrote:
Why not define additional functionality externally? (I believe there was once a library in the Boost review queue called string_algo, or similar). This would be a better design choice, IMO.
Ah, string_algo is part of boost
Oops, my apologies to the authors of the string_algo library :) Regards, Arkadiy
----Original Message---- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Caleb Epstein Sent: 12 October 2006 22:09 To: boost@lists.boost.org Subject: Re: [boost] Boost super_string
On 10/12/06, Arkadiy Vertleyb <vertleyb@hotmail.com> wrote:
More importantly, according to the standard, the basic_string class destructor is not virtual, and so basic_string is not intended for derivation.
Wouldn't this only matter if super_string added data members (it doesn't AFAICT) Not relevent.
and was being deleted via pointers to std::basic_string?
THIS is the relevent point. string* pstr = new super_string; delete pstr; is undefined behaviour. In practise, you get away with it if super_string doesnt do anything in its destructor, and if all additional members don't do anything in their destructors. However, formally it is ALWAYS undefined behaviour. The real question is how often will people create a super_string on the heap, and delete it through pointer to string. -- Martin Bonner Martin.Bonner@Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB24 6WZ, ENGLAND Tel: +44 (0)1223 203894
Martin Bonner wrote:
----Original Message---- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Caleb Epstein Sent: 12 October 2006 22:09 To: boost@lists.boost.org Subject: Re: [boost] Boost super_string
On 10/12/06, Arkadiy Vertleyb <vertleyb@hotmail.com> wrote:
More importantly, according to the standard, the basic_string class destructor is not virtual, and so basic_string is not intended for derivation. Wouldn't this only matter if super_string added data members (it doesn't AFAICT) Not relevent.
It is relevant. If you add data members you now want to ensure the subclass destructor runs in the case below. Detailed completely in Effective C++ #14.
and was being deleted via pointers to std::basic_string?
THIS is the relevent point.
string* pstr = new super_string; delete pstr;
is undefined behaviour. In practise, you get away with it if super_string doesnt do anything in its destructor,
Exactly.
and if all additional members don't do anything in their destructors. However, formally it is ALWAYS undefined behaviour.
The real question is how often will people create a super_string on the heap, and delete it through pointer to string.
No. The intent is that the above new/delete is supported. If it isn't then it's a really bad idea. Jeff
Martin Bonner wrote:
string* pstr = new super_string; delete pstr; is undefined behaviour. In practise, you get away with it if super_string doesnt do anything in its destructor,
From: Jeff Garland
No. The intent is that the above new/delete is supported. If it isn't then it's a really bad idea.
I think we differ on what is meant by "supported". I mean "is guaranteed by the standard". I think you mean "works on all known implementations and most likely future implementations". I'm happy to use code that is formally undefined but works in practise, but in this case I don't think the gain is worth it (but that is a personal judgement call). -- Martin Bonner Martin.Bonner@Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB24 6WZ, ENGLAND Tel: +44 (0)1223 203894
Jeff Garland wrote:
loufoque wrote:
Something more flexible might be an interesting base.
Such as? What features would it have that would make it more flexible?
The ability to build the string type on top of std::string, std::vector, std::rogue, or anything else. Something like flex_string, basically.
loufoque wrote:
Jeff Garland wrote:
loufoque wrote:
Something more flexible might be an interesting base. Such as? What features would it have that would make it more flexible?
The ability to build the string type on top of std::string, std::vector, std::rogue, or anything else. Something like flex_string, basically.
....
std::rope, of course.
sgi::rope I presume. This is a legitimate request. The issue came up during the 1st round of discussions and I prototyped and then dropped the approach. Here was the rationale I posted in July: I dropped the string_type template parameter after actually doing the implementation of const_super_string. The reality is that the implementation relies on the underlying string type and you can't just drop in a new base string type easily. The likelihood of using that parameter seems rather remote. And the extra parameter complicates the documentation and the usage interface -- of which the goal is to make as easy as possible. Now it could be that my view was clouded by the difficulty of the const_string experience. That may have been atypical because it is a mutable/immutable string variation which requires different interfaces. Plus const_string doesn't match all the std::string interfaces. Anyway, I'd be willing to reopen the discussion on this decision if people are really using lots of alternative string types. I still think the usefulness is dubious. Besides, these alternate string types should already have the super_string features...right ;-) Jeff
participants (6)
-
Arkadiy Vertleyb -
Caleb Epstein -
Jeff Garland -
loufoque -
Martin Bonner -
shams