Thread: Why do you find C++ better than C?

I hate having to labour a point...

> C is a smaller language than C++, and is therefore more usable on machines with very little memory.

This is only an issue when you're compiling the source code, since, as I said, a C++ compiler should generate the same code as a C compiler. There hasn't been a PC in the last fifteen years (at least) incapable of running a C++ compiler. Therefore, it's not a strength worth mentioning. You can implement a Basic interpreter in 4k; does that mean you'd use that dialect of Basic to write a modern commercial application?

The Atmel and Philips processors I often work with have as little as 2k of Flash, yet I would use a C++ compiler for them (were it available). The compiler doesn't run on that processor, but who cares about that?

I've worked with small processors (Motorola I believe) that used C interpreters, because in the application they were used in, there was not much room for extra memory, so the size of the language was important.

I use C mostly, but that is because I have had to. C++ just allows for more flexibility in program structure. Esss is right though, C++ isn't 100% all OOP. You can use an OO approach to programming through C++, but then again you won't always be doing so.

When you progress to writing and maintaining large programs, in which there is a significant amount of overlap between sections, you will understand the utility of object-oriented programming principles

OOP was designed with large programs in mind, and the difficulties associated with large programs. IMHO, it is a lot easier to design a large program using an OO approach (C++), as opposed to a proceedural approach (C).

The technical term they use for C++ is 'multiparadigm'. In other words, you can mix programming styles (OO and procedural) so that each is used to where it is stronger than the other style.

There is no virtue in using iostreams over C streams

well,Esss I have do disagree with that comment strongly..... I would only use printf and scanf if i was writing straight c. There is a big virtue of using iostreams over stdio. The reason being that you can overload << and >> to output and input values however you need for your own classes. Also iostreams are 'type-safe'. So with type-safety and extensibility being cornerstones of the c++ language I can see no reason ever to use stdio again. In fact the only function from that family that get a regular airing in my code is the windows version of sprintf... wsprintf.

> There is a big virtue of using iostreams over stdio. The reason being that you can overload << and >> to output and input values however you need for your own classes. Also iostreams are 'type-safe'. So with type-safety and extensibility being cornerstones of the c++ language I can see no reason ever to use stdio again.

And for this you would reject all speed concerns? iostreams are significantly slower than C streams, swell your executable size to a significant degree, make localisation next to impossible, and break a fundamental tenet of OOP (namely, 'make the operator do something analogous to its un-overloaded incarnation'). To be bluntly honest, what is the type safety for, when you can't do

Code:

cout << L'W';

?

> In fact the only function from that family that get a regular airing in my code is the windows version of sprintf... wsprintf.

Ah, but there are strstreams. So why do you use sprintf?

A modern application doesn't use printf() or scanf(), or cout and cin. GUIs often have to put placeholders in strings, however, and iostreams are not the place to do this. Similarly, reading and writing from files is usually done with binary writes (fread, fwrite), OLE compound document facilities or with XML writers - none of which have any use for iostreams. So why bother with them in the first instance?

> iostreams are significantly slower than C streams <

Most are, but the SGI iostreams which I have used are much faster.

Hello,

I wish to add my comments. I've been studying C++ for a couple months although I've been distracted by other stuff and I still do not have a lot of experience with it.

I have a few questions. I find it very dissapointing to hear that operations such as 'operator overloading' and 'iostream' use are not valuable. At this point I don't know if that is a fair analysis. I only have limited experience using these feature but indeed I am beggining to use the C++ language and for example, I personally find operator overloading valuable when used to expand the ability of complex types. it also makes the language much more readable. So what exactly is the issue with incorporating it?

I still have not truely invested my time and skill into C++. I have soem great resources, many of the best books including 'The C++ Programming Language'. I wanted to fully study that book as well as books on the STL. I suppose I'm asking for advice. I think this is the right thing to do and infact soon I'll have the opportunity to create a situation where I'll have about four months which I can use to learn a great deal about C++.

At the same time, I am not ignorant of some of the new technology. I intend to learn C++ using VS.NET. As soon as the full release of this compiler is available I'm going to purchase it. I see value in learning an managed language, but I seriously wonder if it is not more important to invest in a very broad and standardized langauge like C++. I have an opportunity to be slightly more skilled than the average programmer, therefore I'm not in too much of a rush to learn a managed language although indeed I will learn C# or Java. I'm leaning toward C#.

What areas of C++ are you suspicious of, and what is your advice. In regard to the original question of this thread, I've found C++ to be a lot broader than C in terms of program design. I feel much more assured by working with classes and dividing files into header, cpp, and implimentation.

I find that the most frustrating thing is arranging the time that is needed in order to get quality study time. I absolutely hate to take up a subject unless I can get deep into practiceing and fully learning. What do you all think about this? Is C++ worth expending a lot of effort and valuable time in order to fully learn the langauge, or should I skip it and go into and API or something like that? What is the honest truth?

Is that all? The problem is the programmer rather than the language? I use operator overloading so that the complex type created in my class can be used like a built in type. So that the code is more readable and infact easier to write.

I've head talk about 'iostream' not being used by professionals, however I've seen whole books dedicated to 'iostream'. I've also read Stroustrup claim that iostream is faster than 'C' and I've heard the opposite. It sounds like there is arguement over this. Is iostream impossible to use with graphics programming? Why don't programmers like it? What is the alternative?

>>> A modern application doesn't use printf() or scanf(), or cout and cin

This is an important point. True, when I'm knocking up a console app to test something I use cout if it is a simple I/O or printf if it is formatted in some way, but in a regular "grey box" application, neither technique is really applicable.

> First off.. I don't see why C can't be used for OOP.

It can, to a certain extent. C makes it hard to do things like inheritance and polymorphism, though, and really, why bother?

> But the benefits of not overloading operators? If you keep using different functions for everything, you can just macro a lot of the operations

You can inline functions and operator overloads in C++. Think of an overloaded operator as a function call with special syntax, and you'll see that there is no penalty to it. In fact, inline functions in C++ have advantages over #define macros, as you should consider next time you want to put a function call in a macro argument.

> In the presence of excess processing power, the advantage of speed isn't that big a deal, but the advantage is there. Of course, all the speed in the world won't help if you can't write the program.

My point still stands: with careful design, OOP programs can be as fast as their procedural equivalents. For example, your code could be written in C++ as:

int i;
double d;
STACK s(1024);
s.push(i);
s.push(d);

string s("abc");
s.GetLength();

which is arguably somewhat more readable - and there is no reason the executable code would be different.

I note that you try to push an int and a double onto the stack... what happens if you want to be able to handle both these data types without loss? Under your system, in C, we have

s.pushInt(i);
s.pushDouble(d);

If you have several of these, you're going to be writing a lot of type information that a C++ compiler would look after for you.

I take exception to iostreams because they're slow, enormous and kill localisation, not for their type-checking. It is possible to reconcile the two camps, but you need language changes for this (see C#'s String.Format - exactly what I want).

>Programming is a hobby to me at the moment.

which allows us to neglect it for extended periods of time...

the thing i like about programming in general [and music, and tennis...etc etc]... is that the more you put into it, therefore, if you can organize and utilize C++ stuff... it's better for you... but if you can't, and it doesn't apply, it doesn't matter...

for example, i use classes for hierarchial [sp] organization of data/functions... but i haven't a clue about too many other OOP concepts merely because i haven't had a question about them... [else i'd ask you guys...] gimme a reason to know what polymorphism is... apply it to my own stuff... and if it's better off, then yippie...