char vs string

string is better than using plain chars yourself.
because u dont have to worry about allocations and such.

but string is still not a decent class (most of the STL classes arent in my opinion, but thats why they are called containers)

I agree that the string class, if it can be called that, is easier to use. However when using old APIs it's easier to use char arrays instead of strings because many functions have to be passed char pointers. It depends what you're working with.You can still use strings. You have the c_str() member function, and if the string is writeable, you have std::vector<char>.

In this day and age of C++, rarely, if ever, do you need to use the new[]/delete[] way of creating a string or string buffer.

Regards,

Paul McKenzie

Have your instructor look at this document, written by the inventor of C++, Bjarne Stroustrup. He disagrees with your teacher, and gives reasons why.

http://www.research.att.com/~bs/new_learning.pdf

:eek: ^^^^^^^^^^^^

Impressive Paul, thanks! I read that and got a better idea of just why strings are generally better.

Im not really sure why he thinks char's and char arrays are better. Personally I hate them, lol. And to answer your question JVene, I believe he said something about a string variable not having a null terminator at the end. And also something about the spaces between collective words in a string causing search issues or something. My mind kind of shut off as I quickly realized that this semester may very well be a proverbial hell if he pushes the char datatype onto us and discards anything string.

OFF TOPIC EDIT:
On a side note, I just put honey in my coffee. Its pretty good actually

If he does not discard classes, you could write your own string class and use that.

LOL, I was already thinking about that. I was actually working on a class with a function to compare char arrays to strings but then I was like "Why dont I just demand that I use string? Its me that paying for the education!"
And besides, if he demands that we use char... he's not really teaching us to use things the proper way, is he? Strings from what Ive always known in the past, are just better on many different levels.

the only reason i see fit to use dynamic char arrays and handling them yourself is to learn why string classes are better and how to make them yourself and how to learn how memory works. but if he is using this method to teach you C++ he is seriously wrong in doing so

Teacher: "Go ahead, put your hand on the hot stove. Tell me what you discover!"
Student: "Yum! Tasty! Where did my hand go?"

I knew string was better, I will continue to use it until he tells me to stop (or gives me an F) and then I will bring up the points you guys have told me. Thanks!

I don't use char arrays for anything, the only thing I use the char datatype for is if I have a single character I want to store, and thats it. Other than that, char arrays are too much of a pain to mess with...

I remember him saying something about running into trouble manipulating strings, whereas char arrays wouldn't have problems like that. I cant remember what he was complaining about them for, but he's an old school C programmer so he probably has some sort of a vendetta against using strings for one reason or another. But Ill program my way, the easy and more efficient way, using strings.

... he's an old school C programmer ...

Ouch! I'm an old C programmer!

Though I jumped into C++ within the first year of it's availability and hardly ever looked back.

If you want a bit of a laugh, look up Linus Torvalds (sp?) comments on C++.

He says things like (and I must paraphrase):

"C++ programmers are snobs",
"They should admit they're really writing in C anyway",
"C++ compilers are all crap" (though he later retracted that, saying "they're getting better"),
"You can't write an OS in C++" (see Stroustrup on this point),
"It's slow, buggy..."

After I got through that, I thought to myself "how did this guy ever make an operating system", but then I have to realize that anyone with THAT much invested in C just can't help letting emotions and prejudices overtake judgment, and turn that into rationalizations and justifications.

It can become a religious level argument.

Now, we're talking here about character arrays vs string classes, but under the hood, I submit, you're really talking about the difference between object level solutions and non-object level solutions (or C level solutions).

I suppose that to anyone so dedicated to C (and nothing beyond C), C++ programmers might seem like religious zealots (and the reverse is true).

I briefly joined a debate on the subject of "object oriented techniques in C", but I had to bow out. It seems that someone had decided that objects were a good idea, but they didn't need C++ to implement them, and according to their line of thinking, they had written objects in C long before anyone called them that.

The string class is a primary argument against that notion, but the faithful never let go.

Ouch! I'm an old C programmer!

I wasn't poking fun at it :p What I meant behind that was that if he's teaching a C++ class, he shouldn't be using C style ideals to do it. Its C++, similar to C, sure, but not the same curriculum.

abcdefgqwerty, I think you've touched upon the central theme of the point.

After I posted this, I thought I'd preface: I'm not trying to evangelize on C++, or convince anyone - I just wanted to illustrate my thinking on the subject.

The comparative advantages of strings vs character arrays follows the same lines of thought as the advantage of object oriented design over non object oriented design. The notions of portability, safety, flexibility and leverage come to mind, though I'm sure there are others.

Your point is correct enough. When any character array, allocated on the stack, looses scope, the two basic tenets of containment are demonstrated. There are other factors not so well covered, though.

For one, the size of the array is now fixed. The boundary of the storage can be overridden, unless care is taken to avoid it. That care can be encoded within a good string class, but is 'manual' in the case of character arrays. It may depend on the limit of one's own view of the subject of containment, but I think it's reasonable to propose that containment ought to include such tributary concepts as dynamic extension of the storage, strong limits on the boundaries of storage, perhaps even the mutation of storage type.

The character array isn't applicable to a unicode build, for example. A string class can be presented so as to automatically mutate according to the build configuration. Obviously one may counter with a reply that TCHAR or some similar macro solution does the same, and that's true, but an object solution provides even more flexibility, more automatically, than the imposition of a macro solution.

If, for example, one used a string class throughout application code, and then, for some reason, a change in the presumed use of the string class were declared, a search and replace is sufficient to alter the chosen string object, or perhaps a redefinition of the string class would suffice. I've done that a few times in my career, where existing code was moved from one string class to another, or code written without the assumption of unicode was transformed into unicode compliance rather easily. The use of the class was similar, with respect to indirection of the concept, to the use of TCHAR, which could also be defined according to changing specifications. However, if application code used the default 'char *' or 'char array', it's not quite as straight forward.

Perhaps that doesn't sound like such a big deal. Ok, how about custom allocation substitution for the string class? In two cases I was able to substitute the allocation mechanism for an application without changing the application code, simply because the code used a string class for the work. That is simply not so straight forward if TCHAR or character arrays are used.

With character arrays, one might find mixtures of the use of new and malloc (or calloc), the latter being an older C practice. Switching from ASCII to unicode might not work so well for application code built by several hands mixing these styles. It wouldn't even be possible to cause the problem with string classes. One could counter that malloc should never have been used, and I agree. My point is that with a string class such a problem isn't even possible, as long as the class works reasonably well.

Now, the point you bring up with a stack allocated string is significant. For one, it may well be much faster than a counterpart based on a string class, unless a fixed sized string class is available (and there are a few). There can be important performance arguments that hint that character arrays, or the TCHAR solution, might offer some minor performance advantage. Even here, however, an advanced C++ engineer would loose no advantage through the use of fixed sized string classes. The result is similar to the comparison of arrays and vectors. Considerable debate surrounds that comparison, too, but ultimately the choice isn't well made if the weight of one argument is given too much value, specifically performance over stability or flexibility.

You must observe, too, that a local character array isn't common enough to be the deciding factor in one's choice of practice. A fair guess, I think, is that at least a significant portion (half, perhaps) of string allocations must be dynamic, and will therefore require 'delete' to complete containment. In the presence of exceptions, strings offer a safer alternative against memory leaks.

The application level mutation of string behavior is another notion fairly important to me. When Visual Studio's progression of it's CRT deprecated several familiar string functions in favor of 'safer' versions, application code either required change or continued use of the deprecated versions. The deprecation is based on sound reasoning, but retrofitting application code is expensive for little or no obvious return (assuming one is continuing development on a substantial codebase). Such a retrofit is rather simple in the case of disciplined use of string classes, because the classes offer a point of indirection that is unavailable if the CRT string operations were used.

Indirection of an important subject like this is, in my opinion, one of the strongest reasons to favor a string class. It is true, also, of most object solutions vs non object oriented implementations.

One use I think is novel is language independence. In my own work, dialogs, menus, button labels - everything - comes from a table, loaded into strings. In that case, however, the strings are part of a language portability library, such that I can provide a translation of the prompts, labels and help text, then substitute rather easily. I built the system a few years ago, and I've used it to good effect, supporting languages I've never learned. I design in English, purchase translations in Russian, Greek, French, Spanish, etc...and provide the database at installation. The string classes are compatible, but derived from my 'standard' string class. The application code operates without change, but 'automatically' adopt to changes in language. So far as I've observed, its the easiest means of language portability I've found. One could say that my 'languagestring' class mutates on a switch of human language. I hardly give it much thought anymore.

My underlying motivation was to respond to your point; containment is not the only or even the primary decisive factor in recommending string classes over character arrays. I don't think the subject is so firm that everyone would be convinced of my own view, but the weight of advantages for string classes does appear compelling the more I thought about it over the years.

One hassle I have encountered, though, has been the fact that the STL string class isn't so desirable as others, and no real standard string class ever really appeared. The STL string is, to my mind, a 'default' standard, but I don't use it myself.

That became a nuisance to me when I adopted the use of wxWidgets. They have their own string class (wxString), which, while fair, wasn't compatible with the string class I had used for some time to that point (a CString like class based, somewhat, on the recent style when CString was based on basic_string). I had a large volume of libraries which I dragged from the days of OS/2 forward, through OWL (Borland's framework), MFC, a couple of others I've forgotten by now, and then wxWidgets. My preferred string class blended very well with CString (I could even USE CString instead), so MFC was very easy. OWL, if I recall, didn't rely on a string class, so it was no problem, but wxWidgets accepted wxString as a parameter throughout.

So, I didn't what any practiced engineer might think to do - I replaced wxString in wxWidgets. There was about 30 minutes of fussing to do it, but after that there were no issues.

Now as a response to the comparison of C++ vs C, it's true that one can use either language for any target. Consider, though, that some of the most ambitious applications made are not, at least in current and recent forms, built with C. AutoCAD, ArchiCAD, 3D Studio Max, PhotoShop, and Adobe Illustrator are good examples. I'm not sure if the oldest versions of Illustrator or PhotoShop were built in C, but I do recall that the older versions of AutoCAD and 3D Studio (the DOS version) were C applications.

When the developers considered making a windows version of 3D Studio, they decided on a ground up re-make, rather than any kind of conversion of the DOS application. They choose C++ in order to gain leverage in development.

I've seen that in the 20 years I've written in C++ (though certainly more in the last 15). The volume of work I can produce, and the solidity of that work, is greatly enhanced by the use of objects to provide leverage. I can't gain that leverage with C, though I could write the applications in C. Indirection in the designs, threading, multiplexing - it's difficult to relay in a thread just how, in all that time, I've observed leverage coming as a direct result from thinking and implementing ideas in objects.

At the risk of a full hijack of the original inquiry, my own thread classes are a prime example. Threading in C would be, I'm fairly certain, an entirely 'manual' process. Certainly possible, even viable, but the effort I would have to spend on the subject would be many times greater than in C++, using the objects I developed for threading when OS/2 was new. A quick example (and I've posted on this a few times around here), I can thread with no more than:

class SomeWindow : public BasicPanel
{
private:

QueProcessor Que;

public:

void SomeUIMessage( UIEvent & );

void SomeThreadedFunction();
};

void SomeWindow::SomeUIMessage( UIEvent &)
{
Que.Call( this, &SomeWindow::SomeThreadFunction );
}

void SomeWindow::SomeThreadedFunction()
{
.. this runs in a thread
}

To me, this leverage is irreplaceable in C development. The pseudo code above illustrates all that's required to launch a thread and call a member function on that thread from some message response function. The solution is portable from Linux, Windows and MAC. I don't see how that can be so short or simple in C.

Over time, any problem I've faced that appears even remotely applicable to other application code ends up in my personal library for future use. While I could do that in C, also, the results wouldn't deploy quite so easily as the thread example above.

Ultimately that returns two business level benefits that argue heavily in favor of C++ for application level code; speed and reliability. The threaded solutions always work (they were debugged years ago, but if a bug were ever found, the correction would lend itself to all older application code with a simple recompilation), and they're quick (therefore cheap) to deploy.