Is this your way of saying "well I agree that implicit function declarations aren't a problem in the real world, but I have other concerns about the C language such as..."?Originally Posted by Elysia
Is this your way of saying "well I agree that implicit function declarations aren't a problem in the real world, but I have other concerns about the C language such as..."?
That might sound like something.
Anyway. I knew this would probably happen. It always tend to do.
Either you are misinterpreting my words and/or I am misinterpreting your words.
Regardless, I think it's better to stop this before it runs out of hand.
To any people I may have offended, I apologize. Realize that I only speak my opinions from my own view and not that of others, and particularly not the industry.
Now let's all have a nice day
> That might sound like something.
LOL you're never gonna just straight out say it are you.
> Now let's all have a nice day
Yes, let's. No hard feelings from over here.
I think we should post a contest that must be written in both C and C++ and the winner of the contest is the one who achieves the same general code readability and efficiency with both versions of the program. I know this is the wrong forum to post this sort of idea on. But I think if we did something like this, it would inspire people to demonstrate how to utilize each langauge's respective strengths to their maximum potentials.
The problem would be that both languages have different strengths.
Take something that C is strong on, and you'll probably have the same code in C++ with small improvements.
Take something C++ is strong on and you'll end up with long, complex C code.
I disagree that 'C is unnecessary because we have C++'. This simply isnt true. Many PLC's, microcontrollers, and other programmable industrial equipment routinely use C, with no need for C++.
Elysia, no offence, but you need to accept that C/C++ are used to program a lot more than just computers.
Last edited by abachler; 10-09-2008 at 04:19 AM.
I understand, but what I don't understand is why there is a language (language A) around when there's another language (language B) that incorporates ALL features of languages A, is safer and has MORE and BETTER features then language A that is fit for other tasks.
If there can be one language, why are there two?
If there is a law that covers something and then another law that covers that of the first and MORE, is there a need for two laws? Wouldn't is cause unnecessary complexity?
Because language B doesnt incorporate all the 'features' of language A. The choice of using C or C++, particularly for embedded/industrial targets can encompass much more than merely the lanaguages features. Development time for custom compilers is a significant issue, compiler complexity can also be an issue. C++ is NOT 100% backward compatible. There is a lot of C code that will simply break or refuse to compile on a C++ compiler. e.g.
I guarantee you that there is a HUGE amount of existing C code out there that does exactly that sort of pointer assignment. It simply isnt feasible to fix billions of lines of code simply to ensure compatibility with compilers that offer features that are not needed in the first place.Code:int Foo = 42; int* pFoo = 0; char* pFoo2 = 0; pFoo = &Foo; // works on both C and C++ pFoo2 = pFoo; // works on C but NOT on C++
Not to mention that a C++ compiler and all the standard libraries is a much larger implementation than a C compiler - and for embedded architectures, "extra" stuff that isn't needed just cost extra money that doesn't give any benefit - we've been here before, and the situation hasn't changed. C++ has LOTS of things that a small project of a few hundred or thousand lines of code doesn't need.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Creating a compiler may be a problem, but it can skip out on certain features such as templates since I know they "may" cause headaches. But then again, as I see it, it has its advantages and disadvantages. Templates can be used to create more generic code, reducing the time it takes to create software for a certain platform.
All of these things would actually go away, if just C would GEAR UP (ie become more modern). Like being more type safe, disallowing stupid things like I've complained about before (calling function without a prototype, assigning one type to another without cast, etc), getting object oriented, more ability for generic code, etc.
Then I wouldn't have anything to complain about.
Unfortunately, that's BAD code and bad practice. It should be used with a cast, preferable not done at all.C++ is NOT 100% backward compatible. There is a lot of C code that will simply break or refuse to compile on a C++ compiler. e.g.
I guarantee you that there is a HUGE amount of existing C code out there that does exactly that sort of pointer assignment. It simply isnt feasible to fix billions of lines of code simply to ensure compatibility with compilers that offer features that are not needed in the first place.
Regardless, I'm not suggesting C be yanked out or pulled out, but rather deprecated. Meaning that future projects should not be done with C, but with other languages. In time then, C could safely be removed.
This deprecated technique is used elsewhere, so I don't see how it wouldn't be feasible, but then again, what do I know?
Last edited by Elysia; 10-09-2008 at 04:42 AM.
The problem is not so much the differences is both languages. The problem is actively campaigning against a programming language. Is this behavior I cannot understand. There is no excuse for it except a twisted view of what these tools are meant to be: Problem solvers.
Even if what you say is true -- and I can concede that on several problem domains it is indeed -- you are still presented with the issue that it is not everywhere. So a sound knowledge of C can be essential if you are presented with a problem this language can solve. Note that problem here is not a question. C++ can answer basically the same questions as C. But something like realizing the sqlite c api you are using for your project contains a bug and you need to fix it in order to proceed with your, already late, most important C++ project that will buy you a new BMW. Or be given the chance to work on legacy code for an hefty pay, or be given the chance to work on some device not supporting C++, or be given the chance to participate on a new multi-million dollar worth kernel and OS layer.
If the issue is restricted to advertise one doesn't need C to learn C++, I couldn't agree more. But to dismiss C as irrelevant because C++ tackles the same issues is completely wrong. Using your own arguments, that would make C# a superior language to C++. And as much as you try to dismiss this consequence, that's the simple fact. Using C#, I can (or better yet, someone else does, since I'm yet to start my apprenticeship on this language) answer most of the challenges faced by C++ in only a fraction of the time and with cleaner code. And you can shuffle around in the mud all day long trying to find a way out of this simple fact, but you can't.
But is C# superior to C++? Certainly not. But neither it is inferior. It's a tool and goes by the exact same rules that clearly define a screwdriver is in no way inferior to a wrench.
Notice that its not even a matter of what one can do the other can, or how much more one can do the other can't. You can scratch my entire post so far, if that makes you feel better. But you can't avoid the simple fact it's also a matter of what is available for you to work with. Because you may like C++ as much as you want, and you may profetize its use as much as you want, but if the company you work for doesn't want to use it, you are not going to use it... and left to find another job since you just lost this one because you were unqualified.
Last edited by Mario F.; 10-09-2008 at 04:43 AM.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
Ah yes, but I do try to use the "right tool for the right job" as a means of justification.
I say, don't use C for computer software, because C isn't the right tool here. And this is true, and unfortunately, there are many who learn C and does not learn what it is good for and use it to make computer software.
This behavior I would like to be rid of. And I'm sure that everyone else would want more time to be spent on functionality and such instead of ironing out bugs and leaving memory leaks in the software.
One thing I must note here is that I believe C is a part of C++. Learning the basic understands of memory management, pointers, and all that - it is part of C++, a part of what you should learn when you learn C++.Even if what you say is true -- and I can concede that on several problem domains it is indeed -- you are still presented with the issue that it is not everywhere. So a sound knowledge of C can be essential if you are presented with a problem this language can solve. Note that problem here is not a question. C++ can answer basically the same questions as C. But something like realizing the sqlite c api you are using for your project contains a bug and you need to fix it in order to proceed with your, already late, most important C++ project that will buy you a new BMW. Or be given the chance to work on legacy code for an hefty pay, or be given the chance to work on some device not supporting C++, or be given the chance to participate on a new multi-million dollar worth kernel and OS layer.
What I don't like is the C language. I have little or no problems with writing C code and compiling it with a C++ compiler.
However, if another language can do the same, do everything, that the other language can, and it is less error-prone, like more type safe, then the first language is inferior to the latter if you ask me.But is C# superior to C++? Certainly not. But neither it is inferior. It's a tool and goes by the exact same rules that clearly define a screwdriver is in no way inferior to a wrench.
It's like if there's a screwdriver that can screw one type of screw (an old type) and a screwdriver that can screw BOTH old AND new screws, AND it's easier to use and less error-prone (perhaps because the old screwdriver lacks a magnet and the new one has one?), then the old screwdriver is inferior to the new one.
Of course, both screws need to exist, however.
I have conceded that I acknowledge this. If I work in a company and they decide to use C for something instead of C++, I will comply. Possibly complain about it on some level, but nevertheless, do it....Because you may like C++ as much as you want, and you may profetize its use as much as you want, but if the company you work for doesn't want to use it, you are not going to use it... and left to find another job since you just lost this one because you were unqualified.
But as long as I do not work for a company, I can do as I want.
... that language would be C#.
(bold text inserted by me) Sorry to be a pain Elysia, but I want you to reconsider this whole idea you have.
You see, that's exactly what C# is. So, following your argumentation, C# is superior to C++. And you have the problem solved. But do you?
C++ is indeed safer than C in some aspects. But certainly introduces its own new world of pain and doesn't really tackle many of C safety aspects you seem to worried about either. Because as you know, of backward compatibility.
Exactly where is the value of your argumentation? And what do you say of Assembler? Scratch the idea of safety. Concentrate perhaps on code complexity. I may agree more.
But again there is a whole world out there who won't. You cannot dictate the terms of what is the right tool for the job, Elysia, except for your own sake. Assuming a project that can go both ways, If I'm more fluent in C than I can ever hope to be in C++, the best tool for the job will be C. Can you understand this?
There's an helluva of application software out there that was developed in C and on which you depend every single day of your life, be it in your own computer or on your day-to-day outside of it. And new application software continues to be built on C.
And do you really, really, believe that C code is more bug filled than C++? You can't say this. You have no idea if it is. There's no measure, no statistical studies, no accepted way to perform them, and most important... no interest in doing it. Only your theoretic observation that doesn't coincide with mine, not because I think the other way around, but because I simply assume what you should in the first place; I don't know if it is, nor I care.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
Now, there's the problem. It isn't.
With the addition of all that managed crap, it's a managed language and not a native one.
C# simply can't do what C and C++ can, what with memory manipulation, raw speed, etc.
Assembler is worst possible language possible. It should only be used when you absolutely have no other choice.Exactly where is the value of your argumentation? And what do you say of Assembler? Scratch the idea of safety. Concentrate perhaps on code complexity. I may agree more.
Working from logic here:But again there is a whole world out there who won't. You cannot dictate the terms of what is the right tool for the job, Elysia, except for your own sake. Assuming a project that can go both ways, If I'm more fluent in C than I can ever hope to be in C++, the best tool for the job will be C. Can you understand this?
No, I cannot. It doesn't matter HOW good you are at C, it doesn't matter HOW fast you do it, C++ will always be better, more reliable and faster if you do it right.
I don't care if you use C functions, or pointers instead of references, as long as you use smart pointers, possibly templates and OOP, simply because it makes it more reliable and less code for more purposes.
And in my very humble opinion, they should not, and people who does that are morons, unless they have a very, very, very good reason, and I cannot find one.There's an helluva of application software out there that was developed in C and on which you depend every single day of your life, be it in your own computer or on your day-to-day outside of it. And new application software continues to be built on C.
Perhaps I know from experience?And do you really, really, believe that C code is more bug filled than C++? You can't say this. You have no idea if it is. There's no measure, no statistical studies, no accepted way to perform them, and most important... no interest in doing it. Only your theoretic observation that doesn't coincide with mine, not because I think the other way around, but because I simply assume what you should in the first place; I don't know if it is, nor I care.
I used to work with new/delete before I invented my own smart pointer (this was before I knew there was existing implementations of the idea). From that day forward, I did not have to worry about memory leaks or track down memory related bugs.
Smart pointer aren't available in C, nor can they be made in any viable way I see. Huge disadvantage and I don't like it. I know for a fact that Firefox is full of memory leaks. So what if they had just used smart pointers? No memory leaks! Dang! Such a HUGE problem solved. Then they could spend time on fixing other things.
C is a plague for computer software. It is my opinion and it will always be. I'm sure there are similar naysayers out there, but I do not have proof and can only speculate, though.
>> C# simply can't do what C and C++ can, what with memory manipulation, raw speed, etc.
One of the largest stock martkets in the world disagrees with you.
As does NASA, the US Military, many banks across the world and other financial institutions, hospitals, and entire governments.
But you are wiser and more knowledgeable. They will listen.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
