4

I'm reading a C++ tutorial book, and the author says most C++ compilers include a String class library, but even if it does, it is recommended to create your own String class. Unfortunately, the author doesn't state why. Does anyone disagree/agree and why?

I'm using Xcode and the String class that is provided seems fine to me, but then again, I've only been working with it for a few hours, so I wouldn't know the limitations.

Thanks in advance.

John Humphreys
  • 37,047
  • 37
  • 155
  • 255
  • 9
    By no means you should create your own String class, the standard one will do just fine. – K-ballo May 23 '12 at 20:16
  • Isn't `std::string` good enough? It's always fun to make one for enjoyment, but I don't see it being beneficial. – chris May 23 '12 at 20:17
  • 1
    I think it's important for learning purposes – BlackBear May 23 '12 at 20:19
  • The book was published in 1994, it was lent to me by my supervisor. Guess it's time to buy a updated one! Thanks for your answers! – ObjectiveC-InLearning May 23 '12 at 20:22
  • 1
    You need to do two things: 1) burn this book, and 2) get a good one: Stroustrup/Sutter/Meyers/et al – Gene Bushuyev May 23 '12 at 20:24
  • 8
    Using a book on C++ from 1994 is like using a book on driving from 1920 that starts with a chapter on what tools and supplies you need to carry for when you Model T breaks down. – Jerry Coffin May 23 '12 at 20:28
  • Are std::strings safe to cross dll-boundaries on Windows? If not, that would be a valid reason to write your own string class, especially when you are (dangerously) mixing debug and release versions... – André May 24 '12 at 07:33
  • @Andre: it would certainly be a valid reason to have some minimal type, with functions to construct from and convert to `std::string`, and use that in the API instead of `std::string`. Whether you'd want to reproduce the dozens of functions of `std::string` on that type is another matter, especially since `const char*` half fits the bill already -- construct from `string` with `c_str`, convert to `string` with the `string` constructor. Writing hundreds of lines of code to avoid string copies is worth it if your program does a lot of string copies, but not generally recommended. – Steve Jessop May 24 '12 at 09:10
  • @Andre: Assuming Visual C++, yes provided that you use its DLL version of the Standard Library (aka CRT). There's also a static library version of the CRT, which is intended for the case where you build a single self-contained EXE. – MSalters May 24 '12 at 09:19
  • @MSalters: My initial comment was influenced by one of my own questions: http://stackoverflow.com/questions/5661738/common-practice-in-dealing-with-warning-c4251-class-needs-to-have-dll-inter. Right now, I use std::string in my own dll-interfaces, because I know I am always linking against the same CRT. However, I could really use a reference for my colleagues. – André May 24 '12 at 11:57
  • @Andre: Slightly different question, that: They're safe to cross DLL boundaries, but not compiler boundaries. In the case where DLL and compiler boundaries coincide, they're still unsafe. – MSalters May 24 '12 at 12:02

5 Answers5

6

Sounds to me like you have an old book.

The C++ standard library includes the std::string class, and you should be using that instead of inventing your own and fixing bugs that have already been encountered and fixed in a widely used library.

As you are a beginner, yes, you should take a swing at implementing your own as it will teach you quite a bit. Just don't use it in any 'real' project.

Ed S.
  • 122,712
  • 22
  • 185
  • 265
  • Actually, the STL did not include std::string. The std::string was smashed around quite a bit to make it fit with the STL paradigm when the STL was added to the standard library, but the STL did not and does not include one. – Edward Strange May 23 '12 at 20:20
  • @CrazyEddie: I always assumed they were, but I didn't know that the reality was slightly more complicated. I found an SO post which covers it here: http://stackoverflow.com/questions/5972546/is-stdstring-part-of-the-stl – Ed S. May 23 '12 at 20:21
  • Though it wasn't exactly `std::string`, some distributions of the STL did include a `bstring` (basic string). As I recall, Alexander Stepanov said it was just intended to keep some simple examples simple though. – Jerry Coffin May 23 '12 at 20:25
  • It can be beneficial to write a string class as a wrapper for a DLL interface. http://stackoverflow.com/questions/5661738/how-can-i-use-standard-library-stl-classes-in-my-dll-interface-or-abi – Fabian Aug 19 '15 at 05:47
  • @Fabian: Sure; anything which requires a standard ABI must forego the STL – Ed S. Aug 19 '15 at 21:20
3

it is recommended to create your own String class

I believe the author suggests to create your own String class, as a good programming exercise to develop your skills.

It would be absurd (to say the least) to imply to create your own String class for actual production code or non-academic code

John Humphreys
  • 37,047
  • 37
  • 155
  • 255
Cratylus
  • 52,998
  • 69
  • 209
  • 339
3

C++ doesn't have a String class. But there is a std::string class which covers basic string functionality and is guaranteed to exist by the standard. To use it you need to #include <string>.

If you find yourself needing more functionality than provided in std::string, you can always add free functions that operate on the string. There are also third-party string implementations (MS's CString, RogueWave's RWCstring), but I personally don't find them very useful if you're only doing basic stuff.

Luchian Grigore
  • 253,575
  • 64
  • 457
  • 625
1

The standard library's std::string class lacks many facilities common in string classes, including splitting strings, matching with regexes, converting to integer, etc. I don't think it would be a good idea to completely rewrite the std::string class (unless it is fundamentally incompatible with your needs), but subclassing the std::string class to provide some of these features would be nice.

Neal P
  • 599
  • 1
  • 8
  • 16
  • Just make sure you don't introduce any additional fields. Otherwise, you'd get a memory leak if you tried to `delete` a `std::string` pointer that was pointing to the subclass instance. – someguy May 23 '12 at 20:23
  • 2
    `std::string` lacks those features because they don't belong as part of a string class. They can (and are) easily implemented as free functions. – Benjamin Lindley May 23 '12 at 20:46
  • 1
    For the record, you're never supposed to extend a STL container class via inheritance. They were designed to be extended through containment (black-box reuse) and you'll probably get some nasty surprises down the line if you try otherwise. – John Humphreys May 23 '12 at 21:02
  • I know I will get downvoted for that, but there is some truth in that (except for subclassing string!!). To make robust programming environment with string you must write your own helper functions, or you must use boost helpers. – marcinj May 23 '12 at 21:12
  • @luskan C++11 provides some pretty useful string funcitonality, as well as regular expressions. – juanchopanza May 23 '12 at 21:16
  • If you can use C++11 then you are lucky:) – marcinj May 23 '12 at 21:24
  • `istringstream(str)` and get all the standard library's text-to-anything (and ostringstream for the reverse) facilities, and of course all the iterator-based algorithms in the library work on strings. – jthill May 23 '12 at 21:25
  • Agree with other comments. Almost the whole of `` works on strings, too. You really don't need to duplicate those as members. – MSalters May 24 '12 at 09:21
0

There are some reasons you might want to create your own string class, for example you might want to create an immutable string class with functions optimized for creating new derivative strings rather than modifying existing strings because they can sometimes play nicer with heavily multithreaded code. However this certainly is not something you'd need to do if you are reading a beginner's book and should probably reconsider at least three times anyway.

As people have said, std::string is the thing to use for 99.9% of things.

jcoder
  • 29,554
  • 19
  • 87
  • 130