C is better !!!!
-
Well, you could use the C++ compiler as a better "C" (i.e. only use the "C" features). That fixes many of the holes of "C". I'm interested to understand your reasons for excluding "C++" from consideration though.
Fight Big Government:
http://obamacareclassaction.com/
http://obamacaretruth.org/C is limited in its support for complexity management in my opinion. For a very large project, C++ provides the kind of OO facilities necessary to make the project understandable at any level of abstraction.
Fight Big Government!! Big Business Needs Less Competition And Is Not Capable Of Constituting An Oligarchy!
-
Nemanja Trifunovic wrote:
first of all it is build on foundation of a really bad language (C) and it really can't go too far in fixing its flaws without breaking the compatibility. It is hard to learn, full of surprises, and the syntax is so complex that it is very hard to make good tools.
Have you read Ian Joyner's C++ Critique 3rd Edition[^]? It's rather old now (1996) but worth a skim.
Nemanja Trifunovic wrote:
If a job needs to be done I always end up with ugly languages: C++, Perl, JavaScript, C#, VBA
The only one I really hate in that list is Perl. My first experience of it was having to maintain the code of a developer who had left. I would always leave for home at the end of the day in a foul mood. It was quite common to identify a bug, know algorithmically how to fix it but then struggle with the actual Perl implementation! :mad: I'm not especially fond of JavaScript. I like C#. Of the languages I've actually used to at least "Hello World" level the one I've liked most is Eiffel (for which Ada is one influence). I've played with F# a little but find it quite tough. It's not as accessible as Scala. It might just be a superficial syntax thing, and I've not tried either seriously, so maybe Scala becomes equally scary once you get into realistic usages.
Kevin
Kevin McFarlane wrote:
Have you read Ian Joyner's C++ Critique 3rd Edition[^]? It's rather old now (1996) but worth a skim.
Yep - that's one of the best texts on the topic (much better than the popular "FQA"). However, I still disagree with many of the points he makes - he is comparing C++ with high-level OO languages like Java and Eiffel, but that's not where it belongs; pretty much the only real competition to C++ today is (unfortunatelly) C. At the time this text was written, Ada was still a major player so maybe it would have been better to compare C++ with Ada.
-
I dont see a huge difference between them, and the 'benefits' of C++ are questionable, who needs inheritance when you have copy and paste?
Why talk about the OO advantages and so on with respect to languages; OO is a methodology not a language. You can write NON-OO (random function) programs with C++ just as much as you can write OO programs including full inheritance (single and multiple) using C (with not overwhelmingly more effort). The main reason for using C++ over C for OO programs is that your OO structures are syntactically checked by the compiler whereas they are not for C and, of course, you have the battle hardened STL library to use. I've only used C recently once, for a DSP project, where the C++ compiler turned out to be useless.
-
Why talk about the OO advantages and so on with respect to languages; OO is a methodology not a language. You can write NON-OO (random function) programs with C++ just as much as you can write OO programs including full inheritance (single and multiple) using C (with not overwhelmingly more effort). The main reason for using C++ over C for OO programs is that your OO structures are syntactically checked by the compiler whereas they are not for C and, of course, you have the battle hardened STL library to use. I've only used C recently once, for a DSP project, where the C++ compiler turned out to be useless.
-
I dont see a huge difference between them, and the 'benefits' of C++ are questionable, who needs inheritance when you have copy and paste?
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.
-
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.
-
Its also a quote from me. Let me remind the person that plagarism deserves and original source quote.
Morality is indistinguishable from social proscription
-
I have written applications in C/C++ for embedded and C#/VB for enterprises.When it comes to choosing between C and C++ for an application i always go to C, no matter how much much much features C++ has
Behzad
Why not be a real man and use machine code?
Steve
-
Can you please tell me some of holes? I have done embedded coding in C and C++. In C you can use files in which source codes can act as classes and you can write application and do not use OOP features. Once upon a time, i heard from a guy " C++ is C with another syntax!".At the time,for the desktop i was using C# and for a embedded application C++. Now Iam using C in linux and altough IDEs are not as good as VS, i think that guy's opnoin was correct.I love coding in C which i think simplifies thinking; All in all There are some rules you must obey, no matter you use OOP or structured programming, etc.
Behzad
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.
-
i see from someone else's post that you were "quoting" fat_boy. understood. LOL...
Fight Big Government:
http://obamacareclassaction.com/
http://obamacaretruth.org/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.
-
Kevin McFarlane wrote:
I thought you were a C++ worshipper?
Wow! I don't worship programming languages. C++ lets me do my job, but I wouldn't call it a good language: first of all it is build on foundation of a really bad language (C) and it really can't go too far in fixing its flaws without breaking the compatibility. It is hard to learn, full of surprises, and the syntax is so complex that it is very hard to make good tools.
Kevin McFarlane wrote:
So what's your definition of a very good language then?
Don't know the definition, but some of the languages I like (low-level to high-level) are: Ada, Modula-2, OCaml/F#, Haskell, Dylan, Scheme. Mind you, I've never done anything serious with any of them, and I wouldn't pick any of them for any serious project. If a job needs to be done I always end up with ugly languages: C++, Perl, JavaScript, C#, VBA.
"There are only two kinds of languages: the ones people complain about and the ones nobody uses" -Bjarne Stroustrup
-
I have written applications in C/C++ for embedded and C#/VB for enterprises.When it comes to choosing between C and C++ for an application i always go to C, no matter how much much much features C++ has
Behzad
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
-
I have written applications in C/C++ for embedded and C#/VB for enterprises.When it comes to choosing between C and C++ for an application i always go to C, no matter how much much much features C++ has
Behzad
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...
-
I have written applications in C/C++ for embedded and C#/VB for enterprises.When it comes to choosing between C and C++ for an application i always go to C, no matter how much much much features C++ has
Behzad
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
-
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.
-
C is my favorite programming language in existence - bar none. However, there are plenty of times I'd choose C++ over C. I wouldn't want to write a n-tier business app in C for instance.
Jeremy Falcon
-
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
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
-
I have written applications in C/C++ for embedded and C#/VB for enterprises.When it comes to choosing between C and C++ for an application i always go to C, no matter how much much much features C++ has
Behzad
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.
-
Can you please tell me some of holes? I have done embedded coding in C and C++. In C you can use files in which source codes can act as classes and you can write application and do not use OOP features. Once upon a time, i heard from a guy " C++ is C with another syntax!".At the time,for the desktop i was using C# and for a embedded application C++. Now Iam using C in linux and altough IDEs are not as good as VS, i think that guy's opnoin was correct.I love coding in C which i think simplifies thinking; All in all There are some rules you must obey, no matter you use OOP or structured programming, etc.
Behzad
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
-
no, not really. Sometimes when you need the functionality of existing classes but with slight tweaks, but that code isn't polymorphic, then you have no choice but to copy/paste.
Fight Big Government:
http://obamacareclassaction.com/
http://obamacaretruth.org/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)