Printable View
Everything which can be done in C++ using the OOP concept can be done in C and C programs are way faster than C++ ones. Also C offers procedural execution which is far easier to understand than all that OOP stuff. Why is it then that people find C++ better than C?
maybe because you get to use cout and cin instead of printf and
scanf :P
A good question actually... I use both and don't really have a preference. Programming is a hobby to me at the moment.
Large object-oriented programs are generally easier to understand, and therefore maintain than large procedural programs. C++ is also more type safe than C. The speed difference between C and C++ is more a matter of how the programs are written in C++ than how the languages and compilers are designed and can be reduced greatly by good optimization. Also, most programs do not have the need to be that fast, and the remaining time difference is not terribly important.
Why do you find C better than assembly? Everything you can do in C, you can do in asm, except it will probably be much faster in asm.
The code will be faster, the programming process won't. ;)
C does not support object oriented programming or
generic programming.
Yea I'm sure you can write code that looks like
And linked list which uses #defines to allow a template solution and in assembly the cut, paste and edit solution with your editor.Code:struct Car {
struct Vtbl {
void (*startup)(void);
void (*draw)(void);
};
};
This depends alot more on your compiler than on the language.Quote:
C programs are way faster than C++ ones
C++ operates this way too, there's no deferedQuote:
procedural execution
operations or anything.
Code:Car car("blue"); // constructor called
car.draw(); // after constructor is called, call function to draw a car
> Everything which can be done in C++ using the OOP concept can be done in C and C programs are way faster than C++ ones.
Don't confuse object-oriented programming with C++. For the same code compiled with a C and with a C++ compiler, there is no reason they should result in different code, and indeed they largely don't.
An OOP program that is significantly slower than the optimal procedural equivalent is a poorly designed one. I find no basis for your question.
> Also C offers procedural execution which is far easier to understand than all that OOP stuff.
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. There is no virtue in using iostreams over C streams; that does not mean there is no value in inheritance, polymorphism or separation of interface from implementation.
i prefer c++, it seems more optomized and also supports more features than c, (eg classes)
> Everything which can be done in C++ using the OOP concept can be done in C... <
And those C programs are most likely also C++ programs.
C++ is not always better than C and I think most people agree. This line of questioning eventually results in something like this:
Each programming language is a tool.
The more tools you have in your belt, the better and faster you can get things done.
> Each programming language is a tool.
The more tools you have in your belt, the better and faster you can get things done. <
Excellent point. Thats why the old "whats the best language" argument never gets anywhere. :)
Consider, then, two screwdrivers: identical save that one can accept more stress. Do you consider that there is a time at which one would use the lesser one?Quote:
C++ is not always better than C and I think most people agree. This line of questioning eventually results in something like this:
Each programming language is a tool.
The more tools you have in your belt, the better and faster you can get things done.
C++ offers the same facilities that C does, using the same syntax and the same generated code quality. It offers everything C does, and can be used in its place with no loss of power, functionality or speed. Why, then, should one spurn C++ for C?
There is only one time I would use a C compiler, and that is the case in which there is no C++ compiler available. I'm doing this at the moment with a Mitsubishi single-chip micro, and I miss C++'s abilities. Not the classes; the ability to declare variables other than at the start of a scope, the ability to drop the 'struct' keyword, namespaces. Little things, which don't affect the code quality, but help the programmer.
C grows over time, just as any other programming language does. It can do so because the additions don't change its suitability. If you are able to accept the changes in C, why are you not able to accept the incremental changes in moving to C++?
I repeat: C++ does not imply OOP.
C has its uses. C is a smaller language than C++, and is therefore more usable on machines with very little memory. This isn't a huge strength, but it is one.
I think this post would be better if we perhaps delved into when to use c vs c++.
I use c++ for general programming, but as I was doing a project recently (encoding and decoding) I found it easier to use c for the encoding part and c++ for the decoding. I could just have used one or the other but I chose not too.
I think I'm going to start a new post that gets into more than just c/c++ and when to use a programming language.
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.
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).Quote:
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
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.
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.Quote:
There is no virtue in using iostreams over C streams
> 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?
Operator overloading while not necessary can be useful if used correctly as it can make code easier to write/understand. However, if used incorrectly it can do the opposite.Quote:
I find it very dissapointing to hear that operations such as 'operator overloading' and 'iostream' use are not valuable
What I think Esss is getting at is that operators should be used for user defined types in a way that emulates the way they behave for the built in types and the C++ stream operators don't do this (somebody familiar with C but not C++ might think that a variable cout was being left shifted).
Although some may argue that the >> and << operators are intuitive for insertion and extraction operations.
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.
... about C and OOP...
Okay, I admit, C is my language. It's what I know, it's all I know. I've read a bit about C++, and here are my thoughts...
First off.. I don't see why C can't be used for OOP. Maybe it's just I don't understand what OOP is... but this is OOP, isn't it?
int i;
double d;
STACK s = openStack (1024);
push (s, i);
push (s, d);
Or maybe...
string s = makeS ("abc");
sGetLength (s);
These are pretty much the same as C++, except that you don't overload operators... C++ overloads operators for OOP, C doesn't.
What are the benefis of overloading operators? It keeps the code nice and simple, not having to worry about making a function for every single operation you want to perform on an object.
But the benefits of not overloading operators? If you keep using different functions for everything, you can just macro a lot of the operations, and when speed is what you need, macro implementations win. Especially considering you can get down to macroing inline assembly, which is as fast as anything gets.
There's also the advantage of overloading operators allowing you to perform operations without know what the operands really are. If you don't know what type of the variable you want to print is, then in C++ you can print it, in C you can't... but if you don't know the type then there's a more inherent problem with the code.
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.
> 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...
I program in C++. Both languages (C and C++) have their pros and cons. C++ is OOP, and C is line-oriented(I think). C can be programmed into physical objects. C++ can not. C will work on Gameboy and Gameboy Advance. C++ will not. Windows is made out of C. Not C++. Also...
All the top of the line games are made out of C++. not C. Almost all software is made out of C++. not C. C++ can organize structures like you wont belive. C cannot. I am making sence. I cannot. want a carrot