Was that in response to my post?Quote:
Originally Posted by Elysia
Printable View
Was that in response to my post?Quote:
Originally Posted by Elysia
More type safety? How?Quote:
Originally Posted by FillYourBrain
Garbage collection is... well, garbage. That's one reason I choose C++ over C# & Co.
Binary cross platform capability means no need to recompile for each target machine? If so, then I don't rally care. Not my area of need.
Reflection is not something I know what it is...
Yes.Quote:
Originally Posted by robwhit
>> C is not advanced enough. It's an old language unfit for today's commercial needs (and
>> due to its lacking functionality, also a poor choice for private software).
Your DNA is old; that doesn't make it unfit for keeping you alive. Are you positively certain that today's budding fields like nanotech, biotech, and robotics have no room for C? Or let's make it even worse, assembler? Please think about studying some of these topics in your spare time, they can be an eye opener. These fields will have programming needs that managed languages cannot address.
I think Mario (or someone) had it right when they expressed their opinion that C is the primordial ooze of programming. You might not need it for a lot of applications programming, but when you're doing something new, you might be forced to use a feature light, procedural language.
I defer to my earlier post in lieu of further comment.
I was not arguing whether the whole language was suitable. Please reread my question.Quote:
Originally Posted by Elysia
I also express my concerns that C is not needed since we have C++, which is an evolution of C, still close to the hardware, backwards compatible, yada yada.
The two languages have been known to actually cause harm (or at least delays) in each other's standards.
Even so, even if C was made the only language from small systems such as embedded systems, it still doesn't justify people using it for applications programming for modern systems, which some tend to do.
This is also what I tend to try to make public, as well. Use the right tool for the job.
Use C where applicable, where a modern language such as OOP C++ or managed just can't work.
But DON'T use C where you can use a modern language such as C++, Java, C#, etc.
>> Even so, even if C was made the only language from small systems such as embedded
>> systems, it still doesn't justify people using it for applications programming for modern
>> systems, which some tend to do.
Keep in mind that no one claimed this yet. Your assumption was that we somehow all came to the defense of C in response to the original topic. The original topic concerned with how students were learning to program for the first time. It was a fine discussion until, with little provocation, you suggested that C be eliminated from the general curricula due to it's idiosyncrasies.
Many people took offense.
Myself in particular because you seemed to be confused about what was really wrong with the language. You mixed up the definition of a fundamental term (function invocation/calling), then it grew into something else entirely. You seemed to doubt that C was a human work with any purpose, because it was old. I disagree with this course of action because of the need procedural programming fulfills in other academic disciplines.
And as I said, I don't care which procedural language they use to teach. C still may be used in the workplace though, so I reckon that people will still be learning C. So excuse me and the rest of the board for not joining your book-burning campaign (Fahrenheit 411).
Your comments on this topic are very off-topic. If you really take exception to the fact that the boards will discuss C, you are welcome to leave.
[/thread]
C is a fine choice if you are comfortable with C. Don't get so high and mighty about any imperfect language.
I second this motion.Quote:
Originally Posted by citizen
The right tool for the job is not the same as the best tool for the job. Something that is never advertised, and you insist in not understanding. The right tool is a measure of your own personal knowledge and the requirements of the task at hand.Quote:
Originally Posted by Elysia
If my knowledge of C is far superior to your knowledge of C++, I'll put you in a shoe on about every type of application I develop. Conversely, many programmers in C# can produce better and faster even with only moderate knowledge than I can in C++. The quantum leap from C++ to C# is huge, much more than from C to C++, as much as it pains me to admit.
Your crusade against C or any other language for that matter is a measure of your ignorance. As a programmer you should know. The fact you don't grasp this simple concept is revealing. And I feel compelled to write you a cease and desist letter:
...
Elysia,
Every tool is right for the task, it's programmers that are wrong. At the core of the programming task there is only place for humility, not ego and not faith.
Any attempt to politicize programming languages makes you look dumb. And it is also a dangerous thing since you are passing on the wrong message to those who can't tell right from wrong. As once I had the opportunity to say, you abuse your knowledge by forcing it in a devious way. You use it to support your own programming language religion down the throats of those who are defenseless and can't tell right from wrong -- It's the makings of a tyrant.
The fact you can't seem to grasp the simple concept that no language is fundamentally wrong, every language has its place, and that programming languages can cross over their own domains being only dependent on the programmer ingenuity and intelligence, reveals however your lack of knowledge in all things computer related. It is thus safe to assume you are not in a position to tell anyone what they should do and what they should use.
In a similar fashion, any language provides the programmer with the tools to perform their task and a self-contained environment where they can hone their skills, which will only further their general knowledge of the task of programming.
Because, having before being told this much on numerous occasions, and having repeatedly ignored such requests, I hereby forbid you to ever again try to instruct newcomers on what languages they should or should not use.
You are free to answer such queries with only general non-binding information and let the real answer to those who can do a better job than you. Which is, pretty much everyone else.
The fact you insist in spreading your opinions as mere opinions is no excuse. You are legally bound to your opinions and the consequences when you chose to spread them. Understand this when your next order of business is to spread the opinion every gay person in the world should be shot to death.
Failure to comply to this letter will result in punishment,
Sincerely,
Mario Figueiredo
WTF!?!?! That only holds true if you are a sloppy programmer, in which case anythign you write will be buggy and unreliable. It has nothing to do with the language you impliment it in. Most fo the people I have talked to that feel liek you do were just unable to learn C/C++ because it doesnt spoon feed you solutions. It is far more flexible than other languages and due to its INHERENT EXPLICIT support for custom libraries and API's its functionality is easily extensible. It is the ultimate glue language, always intended to allow the use of libraries written in different languages such as assembly, fortran, pascal, ada, etc. If it lacks some feature you need its not an issue of the language, but that noone has written a compliant library providing that functionality yet.Quote:
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..."?Quote:
Originally Posted by Elysia
That might sound like something.Quote:
Originally Posted by robwhit
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.
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.Quote:
Originally Posted by abachler
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.Quote:
Originally Posted by Elysia
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
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.Quote:
Originally Posted by abachler
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.Quote:
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?
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.Quote:
Originally Posted by Elysia
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.
Ah yes, but I do try to use the "right tool for the right job" as a means of justification.Quote:
Originally Posted by Mario F.
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++.Quote:
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.Quote:
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.Quote:
...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#.Quote:
Originally Posted by Elysia
(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.
Now, there's the problem. It isn't.Quote:
Originally Posted by Mario F.
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.Quote:
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:Quote:
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.Quote:
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?Quote:
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.
Elysia is a very typical ideologue. Usually people grow out of this though. Hopefully he/she is just someone who is young. Otherwise, we're dealing with someone who doesn't learn as they age and will probably terrorize the board for a long, long time.
Seriously, they use it because to them, it's more beneficial.Quote:
Originally Posted by Mario F.
They don't need the raw speed, memory manipulation, raw speed, etc, of C/C++.
They need what C# offers - lots of functionality, lots of security, etc.
And no, I'm not wiser and more knowledgeable.
I agree Mario F :)
It's going to be pretty harsh if you get a job with say Microsoft and tell them to get rid of this C# crap, and use "powerful" C++ instead. You claim C++ is faster to develop than C (or can be), by that logic why wouldn't you choose C#!? Or some other managed language where many, many, many things are provided.
> Assembler is worst possible language possible. It should only be used when you absolutely have no other choice.
By that denomination, you shouldn't be using C or C++. Or if you had a choice, you wouldn't be compiling to assembly from C++? Straight to machine code eh? I'd love to see your compiler.
You CAN have memory leaks with smart pointers... and when you do they're usually 99x harder to find and debug. Because the "smart pointer" thinks it's smarter than you are. Stop bashing C for not having OO features and alike. Sure you like C++, but there is no need to bash C everytime someone mentions it.
> 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.
I do it. For learning, portability. It's also great for teaching, last time I checked CPUs were not object oriented. And I'm not cutting off the group of people that may want to use a library in a C or C++ application.
You seem to have an answer to everything... which is fantastic! I can't wait to see your name in the next "PC" magazine. "Boy revolutionizes the software development industry. No more C#, C, Assembly, etc. C++ the way of the future!"
Pfft. No one is listening.
I don't use/like C# because it's managed. And I have on at least one occasion stated why. The end.
It could be. But it's left to say on the particular case of said stock market exchange one of the biggest requirements is exactly near real-time execution, as is on most banks and financial institutions. So, your speed arguments doesn't fit either. Sorry.Quote:
Originally Posted by Elysia
while I'm not an advocate of C# or Java per se, it is no longer true that virtual machine based languages are inherently slow. Many advocates argue strongly that Java and C# are comparably fast to C++ (I'm not saying that exactly). There is very little down side to C# in reality.
See JIT compilation
Bottom line, choose your language based on personal preference, but don't talk down to me for my choices.
Yes, this is true, but it's still slower on startup and also still slower than C/C++, although not terribly slower, but I simply don't buy that.Quote:
Originally Posted by FillYourBrain
I don't want any cuddly, duddly things that tells me what I can do or can't, plus the fact that the stupid thing is compiled on-the-fly.
If there were lots of security checks in native code, for C++, then I would accept that, but...
C# reminds me of typical stupid or lazy VB programmers, which there are a lot of out there.
reminds you of something you don't like so it makes it bad? That's some great logic... I hope you don't vote.
Do you read?
I don't like it because of several reasons AND it reminds me of something.
I don't like it BECAUSE it reminds me.
I never learned how to read.
On your other point... slower. It's really not. Part of the benefit of garbage collection paradigm is that you have delayed memory release. When the meat of an algorithm is running and the hardware should most be utilized you aren't bogging down your program with dynamic memory issues.
edit:
This makes it faster than C++ on those occasions.
I don't buy garbage collection. I like the old smart pointer style.
then use C++! Good for you, you've made a choice! Your choice however is no more legit than others.
This is kind of like asking "which is the best Operating System" (though that always results in a huge flame war too!) It totally depends on the specific situation, but for an introductory course it's not a huge deal, people! You want to learn the concepts, feel comfortable with SOMETHING, etc...
For the record, I don't deny that everyone has a right to choose their own preference of a language to develop with for specific platforms.
However, it is a good idea, for newbies anyway, to try to learn a language targeted at a specific platform when developing for that platform.
Example, if a newbie wants to design computer software, it would be better to learn C++ or C# rather than C. By doing this, they get a handful of advantages because they would be familiar with a language that is aimed at a specific platform. It would avoid the whole I'm more fluent in X targeted at Y, but I'm developing for Z problem.
This is also one of the reasons I tend to drag C down under.
Of course it's subjective, but at least they will know a little of this and that and can decide for themselves.
What really makes GCed languages faster is allocation, not deallocation. With an unmanaged heap, allocating a block of memory means searching for a free block of sufficient size, splitting a piece off it, and updating the management data to reflect the new situation. All this has to be done under a mutex, of course.Quote:
Originally Posted by FillYourBrain
With a compacting garbage collector like .Net's, allocating is adding an integer to a pointer. Since GCs usually stop the world for the actual compacting, this can be done without a mutex, with a simple atomic CAS loop. Under normal circumstances, this is magnitudes faster; under heavy contention, it's even more extreme.
While a compacting GC may also be faster on release under some circumstances, this difference is far less extreme and doesn't apply in all circumstances. It most definitely doesn't apply to non-compacting, conservative garbage collectors like those you can get for C++ (e.g. Boehm).
Doesn't a memory pool almost do the same, though?
Yes, but it doesn't compact, so it only works if you really can release the whole pool at once.Quote:
Originally Posted by Elysia
... elysia, please shutup!Quote:
Originally Posted by Elysia
Aha, so you can understand why somebody would like C over C++?Quote:
Originally Posted by Elysia
You say that C++ would be be better for a beginner because the language is aimed at a specific platform. But why would that be an advantage? Wouldn't portability be an advantage, as well as being a common base for most other programming languages out there, even if they were not directly derived from C?
Erm, C is the base of C++. C++ is not restricted in such a sense.Quote:
Originally Posted by robwhit
It's better if it's aimed at the platform you're trying to develop, yes. Just as it's better to learn PHP or Perl rather than C/C++ if you're going to do server-side business. Not to say it can't be done, but it would be easier in php/pearl.Quote:
You say that C++ would be be better for a beginner because the language is aimed at a specific platform. But why would that be an advantage? Wouldn't portability be an advantage, as well as being a common base for most other programming languages out there, even if they were not directly derived from C?
And C++ is portable.
I would say that C++ added a level of type safety and the concept of privatization does in fact add a layer of coddlingQuote:
Originally Posted by Elysia
I don't agree.
tells you what you can and can't do
sorry chief, when the argument isn't logical you're going to have a hard time in here.
I've noticed that. But I don't like, for example, having a "garbage collector" by default. That's the language forcing stuff upon me that I'd rather be without.
I'll just call C++ "base line", where all features and things are (mostly) to my liking. Any added features that are forced upon me from there is not to my liking. It's "coddling."
Not bondage and discipline? ;)Quote:
Originally Posted by Elysia
Yeah, I dislike B&D nature.
Not in C it isn't. That was standard practice for decades before C++ required explicit type casting. As stated there are billions of lines of code 'out there' and people arent goign to spend the man hours to fix them all just so they can make the code C++ compliant when they dont use any C++ features. Your conhjecture that C isnt necessary is just plain short sighted, there is no defence for that argument. C is necessary for many practical reasons some of which have been laid out here.Quote:
Originally Posted by Elysia
> Erm, C is the base of C++. C++ is not restricted in such a sense.
So I should cast void pointers just because some C++ guy says?
> It's better if it's aimed at the platform you're trying to develop, yes.
C is aimed at the same platforms as C++, and more.
> Just as it's better to learn PHP or Pearl
Perl
> rather than C/C++ if you're going to do server-side business. Not to say it can't be done, but it would be easier in php/pearl.
I don't see the analogy.
> And C++ is portable.
Not as portable as C.
C++ is by nature just as portable as C. It's less portable in practice because implementing compilers for it is so horribly complex.
Frankly, it's a wonder that C++ enjoys as much success as it does, given how much effort goes into developing even an adequate C++ compiler. (I would contend that a "good" C++ compiler doesn't exist.)
Nevertheless, I will say bad practice (without an explicit cast). Most compilers will warn about it.Quote:
Originally Posted by abachler
A good programmer pays heed to warnings and silences them if the programmer needs the do what he/she does and stop the compiler from warning.
Again, I never said they should convert. Rather, I said they should use C++ on new projects instead and gradually phase out the old language.Quote:
As stated there are billions of lines of code 'out there' and people arent goign to spend the man hours to fix them all just so they can make the code C++ compliant when they dont use any C++ features.
In C++ yes, because void* is not necessarily whatever-type-you-want*.Quote:
Originally Posted by robwhit
But in C, it can be dangerous to do so due to a stupid flaw in the C89 standard and some compilers not complaining about this behavior.
C++ has a clear advantage where it's supported over C, which logically would suggest you choose C++, or some other language, over C for those platforms.Quote:
> It's better if it's aimed at the platform you're trying to develop, yes.
C is aimed at the same platforms as C++, and more.
You mean to imply that Perl is better than PHP?Quote:
> Just as it's better to learn PHP or Pearl
Perl
The language you call "Pearl" is named "Perl".Quote:
You mean to imply that Perl is better than PHP?
Oh I see the typo now. I knew that X_X
>In C++ yes, because void* is not necessarily whatever-type-you-want*.
But why the change? It's already a generic pointer. What does adding a cast give you?
> But in C, it can be dangerous to do so due to a stupid flaw in the C89 standard and some compilers not complaining about this behavior.
If you're talking about implicit function declarations, then we already went over this, and it's not a problem in the real world.
> C++ has a clear advantage where it's supported over C,
not when you're compiling C code or C-style code.
> which logically would suggest you choose C++, or some other language, over C for those platforms.
By what logic?
void* can be anything - it can be int*, it can be be double**, even your_own_struct*****. Therein lies the danger.Quote:
Originally Posted by robwhit
Therefore, it is good that the compiler complains or warns when convert from void* to something else.
An explicit cast tells the compiler you know what you're doing.
So should we start teaching people to cast the return of malloc then? Is that why the FAQ states that you shouldn't cast the return of malloc?Quote:
> But in C, it can be dangerous to do so due to a stupid flaw in the C89 standard and some compilers not complaining about this behavior.
If you're talking about implicit function declarations, then we already went over this, and it's not a problem in the real world.
The problem is that this behavior still exists and some compilers do not complain at all. Casting the return actually masks the problem, which is very bad indeed.
Should all compilers support it, then yes, it would not be a problem and the return should be cast.
IMHO, yes it does. Stricter type security for one.Quote:
> C++ has a clear advantage where it's supported over C,
not when you're compiling C code or C-style code.
But not very much, no. You are correct.
Oh indeed, what logic?Quote:
> which logically would suggest you choose C++, or some other language, over C for those platforms.
By what logic?
Why should we use C# for computer software when there's C?
Hey, it's more portable and faster, so why should we use anything but C, regardless of for what we write it?
The answer of why C# is used over C is the answer to why we should rather use C++ over C where possible.
> void* can be anything - it can be int*, it can be be double**, even your_own_struct*****. Therein lies the danger.
No, there lies the genericity. People know what they're dealing with then they use a void pointer. It's a generic pointer.
>Therefore, it is good that the compiler complains or warns when convert from void* to something else.
An explicit cast tells the compiler you know what you're doing.
But the compiler already knows what you're doing. It's just a matter of implicit versus explicit. As far as I am concerned, you made the choice when you chose the type of void pointer.
> So should we start teaching people to cast the return of malloc then? Is that why the FAQ states that you shouldn't cast the return of malloc?
Actually, I was arguing the opposite.
> The problem is that this behavior still exists and some compilers do not complain at all.
In that case, a compile with another compiler or a static analysis tool should fix it.
> Casting the return actually masks the problem, which is very bad indeed.
I was arguing for not casting, since it is unnecessary and makes cleaner code.
> Should all compilers support it, then yes, it would not be a problem and the return should be cast.
What compilers do not warn about implicit function declarations?
> IMHO, yes it does. Stricter type security for one.
And what benefit does being stricter give? You already declared that you want to use a generic pointer.
> But not very much, no. You are correct.
Thank you. :)I don't see any logic in there. I see a different argument.Quote:
Oh indeed, what logic?
Why should we use C# for computer software when there's C?
Hey, it's more portable and faster, so why should we use anything but C, regardless of for what we write it?
The answer of why C# is used over C is the answer to why we should rather use C++ over C where possible.
Therein lies the danger. It's generic. The compiler has no knowledge of the type it contains.Quote:
Originally Posted by robwhit
A function that accepts a generic point can be difficult since you don't know type, size or how it looks like.
Prone to mistakes. Bad for generic code.
But people make mistakes, you know.Quote:
>Therefore, it is good that the compiler complains or warns when convert from void* to something else.
An explicit cast tells the compiler you know what you're doing.
But the compiler already knows what you're doing. It's just a matter of implicit versus explicit. As far as I am concerned, you made the choice when you chose the type of void pointer.
How is the compiler supposed to know you made it intentionally or if it was a mistake?
I'm not sure I like that sound of that, though.Quote:
> The problem is that this behavior still exists and some compilers do not complain at all.
In that case, a compile with another compiler or a static analysis tool should fix it.
But if you say it's not a problem, then I say cast the return of malloc. It's good practice.
I don't know, I'm just echoing the FAQ, and various other members on the board stating that casting the return of malloc is bad™.Quote:
> Should all compilers support it, then yes, it would not be a problem and the return should be cast.
What compilers do not warn about implicit function declarations?
A generic pointer can be anything, so the compiler is correct to be cautious.Quote:
> IMHO, yes it does. Stricter type security for one.
And what benefit does being stricter give? You already declared that you want to use a generic pointer.
It stops silly mistakes and it prevents some nonsensical code from compiling (I know you're going to want examples, right?).
How so?Quote:
I don't see any logic in there. I see a different argument.
Elysia, there is some value in keeping quiet after you've been reputably corrected by someone else. As the discussion continues, you usually learn more.
But it isn't the compilers responsibility to know. With void pointers, there isn't much you can do without specifying the underlying type. For assignment, it shouldn't make a difference what the type is, because a pointer contains a memory address, and all memory addresses can be expressed in a fixed number of bits. Usually this equates to the size of a word on modern platforms.Quote:
Originally Posted by Elysia
But the point is, the programmer knows. Any function designed to work generically needs parameters to know the size of objects, to be sufficiently robust. You've probably used several examples, like memset, memcpy, qsort... I don't see the danger unless the programmer has forgotten something. If someone forgets that much they probably take a break or take a scalpel to the code. I don't see how C++ is any better in this regard either. Even if you're building something generic, you're bound to have type requirements and if you forget those, you need a break.
You're free to call C's method an ugly hack, but don't misunderstand things. C++ didn't "fix" problems with void *, it reimplemented the whole concept of generic programming. The benefit of templates over void * is that most logical mistakes related to type will be caught by the compiler at compile-time instead of run-time. That's valuable.
Wow, I didn't know we were in the presence of a five star programmer. *awe*Quote:
Originally Posted by Elysia
> Therein lies the danger. It's generic. The compiler has no knowledge of the type it contains.
But that's the point. What type would you have malloc return?
> A function that accepts a generic point can be difficult since you don't know type, size or how it looks like.
Claims without evidence. Also, if you assigned something to a void *, you'd know what type and size it was.
> Prone to mistakes.
Perhaps if you use it wrong.
> Bad for generic code.
Perhaps if you use it wrong. Claims without evidence.
> But people make mistakes, you know.
How is the compiler supposed to know you made it intentionally or if it was a mistake?
Explicit casts wouldn't do much to help that. What would help would be a less ambiguous API. void pointers are a means to an end, not always an end itself.
>I'm not sure I like that sound of that, though.
But if you say it's not a problem, then I say cast the return of malloc. It's good practice.
edit: I messed this up a bit. here's the fix:
Not casting malloc
Cons:Pros:
- ?
This makes 3 advantages and no disadvantages. I'd say that not casting malloc is better, and at the least, a style issue.
- implicit function declarations are exposed
- Cleaner code
- Less to change in case you change the type
> I don't know, I'm just echoing the FAQ, and various other members on the board stating that casting the return of malloc is bad™.
That's not what you were doing above. ;)
> A generic pointer can be anything, so the compiler is correct to be cautious.
It stops silly mistakes and it prevents some nonsensical code from compiling (I know you're going to want examples, right?).
You read my mind. :D
> How so?
I don't see how C# vs C is relevant to C++ vs C. Furthermore, you said that C was faster, presumably giving C the advantage.
Arrrh, for the last time... speed isn't everything :)
This discussion is stupid, seriously. It's like trying to convince a brick wall that it's made of bricks, but it thinks it's better than that...
No, it's made of bricks and mortar.
No, therin lies its usefullness. Keeping track of what the generic pointer actually points to is the programmers job. If you can't remember from one line of code to the next what a pointer points to, then you don't need to be programming anything more complex than a microwave.Quote:
Originally Posted by Elysia
The sheer level of stupidity in this thread is probably already epic. Even I - who can swim around a pool of stupidity and feel right at home - am having trouble keeping up.
How can someone be told by absolutely everyone she's wrong, and still keep a straight face pouring all the that bull? Not only that, but the arguments presented are solid, sound, strong. The sheer display of ignorance is outstanding. But the lack of humility... jeebus! The lack of humility is the most dangerous I've ever met in my entire life.
Someone who can't simply for one second admit, "look folks you are probably right. It's everyone but me so probably the problem is me. I'll think better about all this business". You deserve nothing less than my absolute disrespect because you obviously have nothing but contempt towards everyone in here wasting their breath trying to put some sense into that stupid head of yours. So screw you too.
Yes it is a shame. A long time ago I used to think the same, "C#, and especially Java are crap because they're slow / not powerful". Which is stupid, there are VERY, VERY, VERY few programs out there that are going to gain anything by running 0.0000001 seconds faster.
However, I saw the light :). Mainly because people such as those that can be found on this forum. Listen or you'll end up regretting it later.
What I meant was...Quote:
Originally Posted by robwhit
If you targeted a Windows PC, you could have the choice of using C or C#. Which would be better and why?
Assume it's a company. They want software out there and they want it pronto. Lots of features, and few bugs (or they'd get complaints).
Then put yourself in the chair and assume it was a choice between C and C++. Which would you choose in this case?
And as not everyone seems aware... on a private level, I listen but don't accept because my individuality says not to. It's who I am and full of my opinions and I can't change it. I find code nicer and cleaner with explicit casts even.
On a professional level, I listen closely and absorb, because jobs aren't about choice, they're about doing it and doing it right.
You say it's a choice of what language to choose, the right one for the job. So on a private level, my own individual work, I choose C++, even though it may be inferior to C# because it's what I like, just as you would sometimes choose C for such projects because it's your language of choice. On a professional level, I will simply select the language that gets the software out the door as fast as possible and with as few bugs as possible. Simple.
> Then put yourself in the chair and assume it was a choice between C and C++. Which would you choose in this case?
Depends on what sort of software is to be written :P
Like others (and you) have said, it's not as clear-cut as that. It depends on the availability of skill as well as the type of program, as well as it's expected implementation. C and C++ and C# are all suited for a wide range of programming issues, but it doesn't mean that one is always best for a particular problem, or that you even have to use only one.Quote:
Originally Posted by Elysia
Well, if I ran that company, being the head programmer or something, I would recruit people for C# or C++, but definitely not C, seeing as developing with C++ would be faster than C with less bugs using known implementations.
Which was kindof my point. When developing computer software, expectations are often high, and C does not too well in that regard because of its age and lack of modern features expected from modern languages.
But I digress... all that really matters is that the job gets done. But for me, preferably not C. Just the type I am.
Oh well, carry on.
Yes, personal preference can definitely matter. Personal preference, you could say, is how comfortable you feel with the language, and therefore you might be able to program more effectively with it.
However, don't mistake age for lacking capability. Likewise, don't mistake lacking modern features as necessarily limiting.
C has a wide range of tools and methods to help with producing quality code because of it's age. Memory leak detectors, static analysis tools, code standards, well-known techniques and idioms even in specialized fields, etc.
Also, some people prefer not to use modern features such as exceptions. Either it's not their style, or they're not comfortable with them, or perhaps their coding standards say not to use exceptions because they are more difficult to verify in a code review than conventional return-based code.
I am starting my bachelor in engineering (not software engineering) this year, and there is a mandatory programming course "Introduction to Computation in Engineering Design", and it is in C. We only cover the very basics, though - branching, looping, modularization, and the last unit is on arrays (no pointers except if you consider using arrays and scanf as such, and no dynamic memory). That takes about 2 months (3 hrs/week). And then we will be into things like software/hardware interfacing (reading from switches and writing to LEDs I heard), and "data acquisition" (no idea what that means =P).
As for why C over C++, I don't know. We certainly don't need anything from C++ that's not in C, though.
I heard in CS they are using Java and C++ in the first year.
> I heard in CS they are using Java and C++ in the first year.
Same at my Uni. The CS/SE students don't touch C until 3rd year :D (They teach Java to CS, SE, and actually all IT degrees in first year). However 1st year engineering students don't get to play with it :'(
So if my name were Salem and I wanted to do the world a favor, I would sure be closing this thread about now.
Meh. It is kinda fun watching Elysia make a complete fool of him/herself
I gotta say though, it's kindof nice to finish one of these kinds of threads without it getting shut down.
> I gotta say though, it's kindof nice to finish one of these kinds of threads without it getting shut down.
Your face! ... Ohh shutdown!