C is better !!!!

[parkzone]

If you are writing code, there is no difference between copy paste and inheritance. If that code has to be maintained then there is a huge difference. It is n times worse where n equals the number of copy pastes. That assumes you know where all of the instances are. Single source is always better.

[Lost User]

I know - this was just a quote. And see the joke icon.

[uvatbc]

I love where this is going. Let me summarize: Copy paste must be cited with sources, whereas inheritance is in itself a citation of the original source. Plagiarism at its best! Love the irony! ;P

[Stephen Hewitt]

Why not be a real man and use machine code?

Steve

[kgrunwald]

It depends on the compiler. Most compilers on embedded system don't have good warnings in C++, so you are on your own anyway. You need good optimization on embedded systems, since poorely optimized C++ tends to eat up all the space you have. The STL is useful some times, but if it comes to predictable timing, you cannot rely on it. So using C for embedded projects looks not that bad.

[yp wong]

This question is very much like asking whether a speedboat is better or a ship is better. Many people argue that C is faster, that is just like saying speedboat is faster. I have no experience in embedded system but my guess is C would be better for it. C++ is designed for big system and you simply won't get the real benefit if the system you are developing is small. For big project, C++ is always a better choice, once you know C++, it's not difficult to switch to C if you need to, the other way round would not be so easy. So, a speedboat is certainly faster than a ship for short distance, if you have to travel far, you would probably need to tie a really huge petrol tank behind the speedboat in order to travel long distance, and it sure will get really slow.

[Rick Shaub]

"There are only two kinds of languages: the ones people complain about and the ones nobody uses" -Bjarne Stroustrup

[Peter N Godino]

I taught C++ for several years. One of the things I stressed was that you don't write code for yourself, you write code for the guy who will add to it and maintain it. Many of my students were C programmers. The remainder were mostly first time programmers. By the end of each semester about half of the C programmers were still writing C code and struggling. The first time programmers were writing simpler more compact code than the C programmers. A multi-week project final always showed the difference between those that persisted with C and the C++ programmers. On average what a C++ programmer did in one page of code a C programmer did in over four pages.

peterg

[CDMTJX]

One example where C++ is better - parsing string data. Old app I have to maintain is using char*. Ugh. Yes, I can figure it out, but using the string class is so much easier to code and ensure I'm getting the correct columns for the data. Assign from existing char* to string object, and use string methods to access...

[W Balboos GHB]

Yup. When I coded in C it was always fun. I did what I wanted to do. These other johnny-come-lately languages - like the TV shows designed for short attention spans, they're for coders who don't want to take responsibility for having absolute power. Power. Power! Power !!

/xml>

"The difference between genius and stupidity is that genius has its limits." - Albert Einstein

"As far as we know, our computer has never had an undetected error." - Weisert

"If you are searching for perfection in others, then you seek dissappointment. If you are searching for perfection in yourself, then you seek failure." - Balboos HaGadol Mar 2010

[ghle]

kgrunwald wrote:

on embedded systems, since poorely optimized C++ tends to eat up all the space you have.

I like "Let's use 2 bytes to represent one byte of character data" on a memory-limited, slower CPU device. Gotta love that "optimization". :mad:

Gary

[ghle]

x2

Gary

[ghle]

Balboos wrote:

Yup. When I coded in C it was always fun. I did what I wanted to do.

Agree 100%. C was always fun. If it didn't do everything you wanted, you easily slip down into ASM and git er done. Above all, it was fun. Fun to write, fun to tweak, fun to make faster. Anyone read the book "The C Puzzle Book Puzzles for the C Programming Language" by Alan Feuer? Now THAT was a thought-provoking book.

Gary

[Theraot]

C better?, sometimes I have to admit, but with no standard way to clear the console / terminal and no standard way to set the cursor position in that console / terminal, and no standard windows / frames API... I can only find place for C or C++ to make libs for calculations, libs for real time operations and for video games (with OpenGL). Making enterprise solution? I would rahter go standard and portable with Mono / .NET and C# 2.0. Not that you can't in C, just saying that my opinion is that C# is better, I think people will also say Java, well, I prefer C# over Java, but again, it's my opinion.

[Stefan_Lang]

Most of the holes originally present in C compilers have been fixed with the newer C standard, so the advantages of C++ over C are mostly limited to the additional syntax, and you will notice improvements only if you understand and correctly use it. The problem with that is you cannot really appreciate these advantages if you don't know a couple of tricks that make your own and other people's life easier. The most prominent advantages IMHO are 1. avoiding redundant code: often code segments that vary very little are copied and pasted to other functions, instead of using polymorphism and inheritance to avoid unneccessary duplications. Thanks to templates you can even use the same code for objects of different types! 2. make programmer interfaces more safe to use: there are lots of options such as templates, polymorphism and others that allow a programmer to severely restrict the way a particular interface they implemented can be used. This way another programmer calling on this interface has an easier time to detect and avoid usage errors at compile time, rather than at runtime. The Standard Template Library heavily uses these concepts. 3. catch erors at compile time rather than at runtime: more options to explicitely specify types via inheritance, templates and polymorphism gives the compiler more information it can check, and thus the compiler will detect more semantic errors that are encoded in C++ syntax than it ever could in plain C code. 4. information hiding speeds up the development process: while you can do this in C as well, inhertitance makes it a lot easier to hide implementation details from other parts of the source code. This means if you change the implementation locally, there is a good chance very few files will need to be recompiled. As I said, this can be done in C just as well, but C++ enforces it to some degree, whereas in C you need to personally take care of everything. 5. No more need of MACROS! This is one of my pet-peeves that not everyone might share, but in C++ there is absolutely no more reason to #define your own macros. Those used to define some literal can be implemented as const values, those representing functions can be implemented as template functions. Anything else shouldn't exist in the first place neither in C, and much less in C++ code. I can think of quite a few more reasons, but most might be considered irrelevant by many others, or they require some more advanced understanding of C++ programming techniques. Anyone interested in such stuff might take

[Stefan_Lang]

If that code is from an external library that you cannot (or should not) change, then I can understand the need. It is the same as copying code from a book or some library from an external source, in that it will be present in your application only once. But if it's code you have full access to, it can always be adapted to meet the previously existing needs as well as the new one you are trying to fit in. C++ is all about reusability, and if you notice some code isn't quite fulfilling that paradigm, you should try and fix it, not copy and paste. Copy and paste is a recipe for future headaches, furthers code bloat, increases maintenance cost, and the risk of hidden errors. I do realize that often it takes a lot more work to adapt existing code to prevent redundancy, than just copy/paste/adapting it for the new use you have in mind. But if your application has an expected lifecycle of several years at least, you will still win out in the long run! Not to mention that new people joining your team will have a much easier time understanding your code if it's only half the size, and doesn't have three or more versions of each function spread over the whole of the codebase. (some of which might even be obsolete and forgotten)