C++ is really C 'under the bonnet'
Printable View
No, it is not. At least for now, C++ is not a true superset of C, and neither are C++ programs compiled to C programs (even though the first C++ compiler actually did that).Quote:
Originally Posted by esbo
Well C produces assembler code as does C++ at the end of the day.
Anything in C++ can be inplemented in C, it might take a few more lines, and C++ will
do some of the work and 'syntax checking'.
I certaintly C++ *could be* C 'under the bonnet'. Yes once you have your first C++
compiler written you can write more complilers in C++. It's not likely you would write it
from assembler anyway.
I think my program actually use a lot of C++ concepts, but I had to implement them in C.
A window might be a class for example. I had different types, fixed size, display only etc..
but they were all based upon one multipurpose window, with usually functionality taken away. Of course I have to do the checking if I am going to modify a display only window
not the compiler. I just don't try to modify it, that's all.
Some of it is actualy like Basic too. For example you can add strings I believe eg, S1+S2+S3 which is basically a strcat and a strcpy.
I think you're putting the focus on the wrong element (how C++ is compiled) rather than accepting that C programs are treated differently by C++ compilers. Use a C99 feature, and compiled as C++, your program could fail to compile. Even if you don't use C99 stuff (or by some miracle C99 stuff is proffered by your C++ compiler vendor), you have to wrestle with C++'s type system to get it compilable. You can't even do
p = malloc( size );
without a complaint.
In this case, it would be more important to consider that C programs, if they are not already valid C++ programs, can be modified to become valid C++ programs, since behzad_shabani intends to write a C++ program but you have a C program that does something similiar.Quote:
Originally Posted by esbo
However, I do not see how this makes C++ "really C 'under the bonnet'".
It may then be better to give behzad_shabani ideas on the design rather than the implementation of the program.Quote:
Originally Posted by esbo
I think the main point of comparison is that C++ is a generic object oriented language, whereas C is imperative/procedural. As a result of this the process of designing programs in these two languages is drastically different.
Now sure, you can write procedural programs in C++, and you can contort C into supporting object oriented and generic programming, but that not how people generally use the languages.
A few compilers still compile C++ to C. (The version of Comeau I have does this. An embedded compiler, which doesn't support templates, I use does this.)Quote:
At least for now, C++ is not a true superset of C, and neither are C++ programs compiled to C programs (even though the first C++ compiler actually did that).
If you don't consider static polymorphism in all its glory then you are only comparing a subset of C++ to C.Quote:
Anything in C++ can be inplemented in C, it might take a few more lines, and C++ will do some of the work and 'syntax checking'.
The C macro processor simply isn't capable of all the same feats as templates. (As the C++ template mechanism isn't capable of all the same feats as macros.)
Your "can be implemented in C" may as well be "can be implemented in $(language)".
Your "few more lines" may as well be "infinitely many".
For all the work you would have to perform manually your "C++ is really C 'under the bonnet'" may as well be "C++ is really assembler 'under the bonnet'".
So while the statement may be true, it is meaningless.
Soma
The only template feat I can think of than can't be done with macro's is recursive templates.
You probably need to explicitly declare every instance and do away with type safety. And debugging would be virtually impossible. But In principle I submit it could be done.
Not that anyone should every try to do such a thing.
I just had the idea yesterday of porting std::vector to C. At first I thought that you'd simply need to pass the vector as a parameter rather than it being the this pointer. But there's WAY more to it than that. "A few more lines" just wont cut it. You've got to also provide to the vector a function that performs each of construction, copy-construction, copy-assignment, destruction. You've got to give it the size of the object contained, and get the type in there somehow too, probably via macros. The syntax will look awful due to no operator overloading, and overall, nobody is going to want to use it.
It'd be like saying that you could clean a large mansion's floor with a toothbrush. Well no actually, you can't. First it'd take more than one toothbrush, and second, before you get half of it done, the other half has gotten dirty again.
C really cannot do what C++ can do. Therefore C++ is much much more than C.
To be honest with you C++ comes across to me as a lot of mumbo jumbo and waffle that I don't need to write a program. There is nothing there I need nor want.
How come?
What makes C++ so special from C?
Are you really that clueless?Quote:
To be honest with you C++ comes across to me as a lot of mumbo jumbo and waffle that I don't need to write a program. There is nothing there I need nor want.
O_oQuote:
The only template feat I can think of than can't be done with macro's is recursive templates.
This rules out recursive templates, mutually recursive templates, nested templates, and determinism through template expansion.
So... yea... saying that macros are capable of everything templates can do except what they can't do isn't particularly useful.
O_oQuote:
To be honest with you C++ comes across to me as a lot of mumbo jumbo and waffle that I don't need to write a program. There is nothing there I need nor want.
So? It is your problem if you want to stay with C. That doesn't mean that C++ is "C under the hood". If you didn't have this ridiculous and naive opinion you might wish to use C++.
Soma
C++ is newer and accepted by plenty, and used by all famous programming companies, so you use it, end of story xP
Why light a fire with stones, when you can use a lighter? :P
What problem is this fixing? In some very poor parts of India, a man might douse his wife with kerosene if he is unhappy with her. It is a cheap, effective and widely available weapon. Fortunately, it is not often so premeditated that a man would seek out an appropriate base, such as Styrofoam, and instead launch a napalm cocktail at his former lover. Although I'm sure such incidents are occasionally reported.
It's called moving from the old stuff to the new stuff! There doesn't have to be a reason, you just do it!
Usually, we move to new stuff because of a reason. Usually, it is because it provides more benefits, or it's cheaper.
So it is with C++ over C, as well. C++ is very much a all-in-one language, incorporating not one style but many.
I have always argued that C should go away and be replaced with C++, but unfortunately, the world does not always agree.
C is still cheaper to implement than C++, which is probably the biggest reason it's still in existence, especially for embedded systems.
Maybe there is a reason, you just don't have to know it xP
All the sexy people code in C++ >: D
Haha yes, they are plotting in secret to kill C++ and reimplement C as the standard world-dominating language :D
Wow. I had to be bored to death to read this topic. How bored must you guys be replying?
Seriously, why even throw food to the troll?
Call the FBI... We've got a "situtation" here B-|
Well, atleast I'm posting 'cause I'm bored... EVOEx, how did you know? o.o You better not be stalking me!
And what exactly was it from the "C++ part" that you needed to use in C, which C++ could not do better?
And how big projects, exactly, have you worked on? How big the team and how many lines of code?
And why do you go against known industry facts? Is it because that they are untrue to you, as you see it?
Of course, lots of examples here and otherwise show that it's entirely possible to write rubbish code in almost any language. But most people that have experience in working on large software projects.
I currently work with code where the entire code-base including test-code is tens of megabytes - written mainly in C++, but some third party code is using C.
I have also worked on code that is pure C [or at least "not C++"], of similar size.
Neither language makes the task straightforward or simple - there is a need to know what a lot of code does - but C++ certainly has some features that IMPROVES the ability to write large programs in the language - for example, the fact that you can keep portions of a class private and access it through setter/getter functions (or similar) makes it possible to know if changing the class is going to affect a lot of code or not - which is more than you can say if you are trying to make the same decision about a struct in C - you have to literally search for the struct member [and then from the search results sort out which are REAL hits and which aren't, as searching for "address" as a member of a struct may of course find all sorts of other things named "address".]
But there are certainly successful, large projects written in C too - it just is a bit harder version of "not easy".
--
Mats
You can design and write bad code in any language, I don't really see what makes C++ so special.
Yes, that is repeating, roughly what I started out with.
However, my point is that the purpose of object oriented programming is the form of encapsulation and extension that the class structure provides.
It is admittedly possible to do in C too, but it's much harder and the language doesn't "help" in this aspect. In more traditional (procedural/functional) programming, any encapsulation done has to be achieved by the programmers direct effort, there is no provision for the compiler to tell the programmer "Look, you are doing it wrong here, you should not use struct X's member variable Y" - C++ has "private" which means that a member variable is not accessible outside of the class - so you can't by mistake "forget to call the appropriate access function".
This only matters if you are writing code that is relatively large (more than a few hundred or thousand lines of code).
Reliability (such as keeping track of memory allocations and other resources) is made easier thanks to the form of constructor/destructor policy that classes provide. There is no need for the programmer [in general] to write a lot of code to handle this. C does not make life so easy here either.
And of course, if you have stupid people, you will end up with stupid code. I have seen a fair number of examples of that in both C and C++ - there is no silver bullet.
--
Mats
I'm with esbo. Who needs all this new stuff anyways. Why bother driving a fancy car with all those confusing knobs & buttons when you can just rid a horse instead. Why build houses out of bricks, wood & concrete when we can just find a nice cave to live in & rub sticks together to make fire... :D
Exactly! All teh sexy pplz live in caves NEway!
Does C have vector ?
And I've seen some C code, looks bad :P looks old xP But I don't know about any specifications and stuff
The days when new meant better are long gone, but we have been conditioned over the
years into thinking new means better so people accept it blindly and trott out the namecalling caveman arguemet rather than have to justify the 'new'.
For example the new method of 'light touch' regulation for banks has not done us any favours and new anti biotics have left us with filthy hospitals full of superbugs.
There is plenty of appalling software written these says with 'new' C++.
Yes I believe vector is apelt a-r-r-a-y in C, one less letter, so it is more eficient :)
Also the term actually describes what it is rather than use a word which describes something totally different.
In the old days a fire was called a fire, now it's called a spoon, thats progress for you.
No problems with that part from a few burnt lips. :)
recursive templates, mutually recursive templates: Standard C++ only guarantees 7 levels of instanciation, so this isn't very useful anyway, without compiler extensions.
nested templates: You can nest macros; that would be passing the result of one macro as an argument to another.
determinism through template expansion: Can you give an example of what you mean by this?
Arrays don't resize for you when you need to add one more element to the end. Static arrays dont resize at all, and dynamic arrays require you to reinvent the wheel for every type stored in them.
Linked lists are even worse in C. In C++, you just use the std::list implementation.
Anyay this discussion arose when I gave an example in C but was informed C++ was required, however C is a part of C++ is it not??
Nore are Microsoft apparently ;)
As you and I have said before you can write large unmaintainable and unreliable software in any language. Such problems are generated by the programmers, not the language.
Further more if you also require the code to be highly efficient you are probably going to use C. You can also use assembler, but C is not that far off assember anyway.
OK, if you want an example of how C++ can kick C's butt, here you go:
Which is faster, C's qsort() function or C++'s std::sort() function?
Since std::sort() is a template which can take advantage of inlining, the speed can be substantially faster than qsort().
http://www.tilander.org/aurora/2007/...and-qsort.html
As I noted, C is not quite a subset of C++. The C++ standard refers to the 1990 edition of the C standard in several areas, including the part of the C++ standard library inherited from C, but nonetheless incompatibilities remain. The 1999 edition of the C standard eliminates some of these incompatibilities while introducing others.Quote:
Originally Posted by esbo
C++ can be used in such cases. The C++ standard library is designed to be efficient, and it is possible to dip down into assembler if necessary, or at least write some speed critical portions of code in a C style if that proves to be more efficient in that case.Quote:
Originally Posted by esbo
Careful there. An array is not a vector or vice versa.
A vector is a dynamic array that will automatically expand (reallocate) when there is not enough room. Due to this, there may be some overhead.
If you want to compare C to C++, compare arrays to std::tr1::array instead.
Anyone can write unmaintainable and poor code in any language, true, but the idea is that newer languages give you new and better tools to work with so you can avoid mistakes and write better code.
Well-written C++ code is more maintainable than equivalent C code. That's because in C there were problems, and to those problems solutions were invented and were added to C++. That is called evolution.
And as for the speed question, you are dead wrong. Well-written C++ code can match well-written C code in speed, or even outperform it, just as C can outperform C++ in certain situations.
Read: C is not necessarily faster than C++. They both have advantages and disadvantages and are about equal in speed.
Saying anything else is just not true.
So why is it that you dislike C++ so much, again?
This thread being a waste of space and time is one thing. What's worse is that I find myself actually wasting energy on the big question... who's more pathetic, esbo (Mr. C) or Elysia (Ms. C++)? Why don't you two get married, you seem the perfect fit.
Anyway, both of you do not seem to understand that a programming language is just a tool to solve a problem. And which tool the programmer uses is largely a matter of his personal preference and experience. A C programmer comfortable with C will obviously be biased towards implementing his solution in C, and vice versa for a C++ programmer.
Both of you also seem to forget that there are other programming languages out there. Especially when it comes to the field of scientific computing there is large bias towards Fortran (and there may even be great hostility towards C/C++).
Such threads get people talking, which is good! MWAAAHAAA, you spoilsport...
Relax, you ain't pathetic, nor is esbo xP You both have rights to have your meanings/thoughts/whatever ;) getting people banned is never the right way xP
^_^Quote:
Presenting facts or being biased is one thing, but being rude is another. I should report you and your post.
He is just jealous of all the attention your giving the OP.
Soma
>> Presenting facts or being biased is one thing, but being rude is another. I should report you and your post
A report emails the entire moderating team. Your feelings frankly aren't a reason to use it. I only filed one report in the three years I've been here and that was because someone was rather immaturely talking about penises and vaginas, and apparently trying to sell something. That's the type of crap you report.
The thing esbo doesn't realise is that his grief isn't really with C++, it's really with OOP. He simply doesn't understand the usefulness of OOP.
esbo's also misguided into thinking that his public display of clulessness will instead somehow make others say "OMFG you're right I've been using C++ for so long that I was blind to the fact that it is a waste of time when it can all be done in C!".
Wake up - those that use C++ have been doing so because they've discovered the bennefits of it, and OOP.
Next flame war I'm asking up front what the initiator expects to achieve.
What you don't realise, is that I know how to program end of story.
I don't need to learn about OOP because I already know how to write good programs.
I don't need mumbo jumbo, I can get on and write programs without that.
I mean it is not as if writing good maintainable programs is difficult in the first place.
Afterall if you struggle with a book on C good help you when you pick up a book on OOP.
Basiclally if you need to be taught how to program, you are probably not suited to programming.
Yes, because everybody is born with all programming knowledge... :rolleyes:Quote:
Originally Posted by esbo
Prehaps the irony of the whole thing is that I would bet you a pound to a penny that my (editor) program, written in C, employed more object oriented techinques than the one which was being written in 'object orientated' C++.
There is a lesson in there somewhere I think!!
Obviously not, but as in everything, people has a range of abilities from being naturally
talanted at something to being complete muppets and all shades inbetween.
After all programming is just followig simple rules, but if mess the rules up you will end up with a bad program
whatever language you use.
that's aburd. how would you learn anything without documentation? blindly stabbing away in the dark?Quote:
Originally Posted by esbo
Having looked at your code, it is clear to me that you know how to program, but you do not know how to program well, or simply refuse to do so.Quote:
Originally Posted by esbo
That might be true. On the other hand, learning a breadth of techniques (i.e., not just OOP either; other paradigms like functional programming should be covered as well) helps you to deepen your knowledge of programming.Quote:
Originally Posted by esbo
Your own programs lack those qualities, so you are merely saying that "it is not as if writing programs that I find good and maintainable is difficult in the first place".Quote:
Originally Posted by esbo
Since you need to be taught how to program, you are probably not suited to programming ;)Quote:
Originally Posted by esbo
Considering the tight coupling due to your overuse of global variables, you have lost the bet.Quote:
Originally Posted by esbo
Precisely.Quote:
Originally Posted by esbo
Except it's not. Some people are better programmers than others; they write better programs. For example, there are programming contests, and these contests have winners, suggesting that the winning programs are better than the loser programs.
Do you? By what measure are your programs good? Can you justify your designs? Not likely since you aren't aware of alternatives. Then how can you be sure that your design is the best?Quote:
I don't need to learn about OOP because I already know how to write good programs.
If you knew alternative ways to look at programing challenges, you would be a better programmer. OOP is one of those ways.
The amount of unmaintainable programs out there suggest otherwise. Reportedly, the lack of modularity of older programs is one of the things that makes it hard to maintain, and one of the things that OOP seeks to fix.Quote:
I mean it is not as if writing good maintainable programs is difficult in the first place.
OOP is not harder that C. It is easier in many ways.Quote:
Afterall if you struggle with a book on C good help you when you pick up a book on OOP.
Except that you always mess up. I've never had a program that compiled and worked correctly the first time. Never.Quote:
After all programming is just followig simple rules, but if mess the rules up you will end up with a bad program
whatever language you use.
Furthermore almost always there is more than one way to do any nontrivial task. If you do not realize the options, then your chances of doing things in the most effective way possible is slim. Knowing different programming paradigms helps see challenges in different lights, giving you multiple ways to solve the same problem.
No it's not. Learning syntax is easy. Learning an applying good design principles is trickier, especially because the compiler doesn't tell you when you picked the wrong one. Everything still works, but you've made it harder on yourself and others.
In summary learning multiple programming paradigms gives you more ways to analyze a problem, to come up with what is hopefully the best designed solution. Programs with better analysis of the problem and more attentively designed solution tend to be better programs.
If push comes to shove I'd agree that being self-taught produces the best programmers. But that'd be my ego talking, since I'm also self taught.
You seem like you're rather good at convincing yourself. You really only came here to convince yourself you know all you need to. You don't have to learn OOP or C++ properly, because fortunately probably none of us will ever have you working alongside us in the real world.
Sure, writing good maintainable programs isn't hard. Good, large, extensible, maintainable, reliable and re-usable programs is what you can't really do without OOP. Or to be more general, OOT. (T = technology, which includes Analysis and Design) Probably not something you're particularly familiar with. Perhaps the term "Hocus Pocus" might be putting it more in your own terms.
I've always wondered what happens with people who share your attitude to programming. I'm guessing they either pick another profession, or they eventually realise their mistake, or they end up being a regular character in theDailyWTF stories.
I think that is very similar to what I said about 50 posts ago, and esbo decided that it was quite possible to do in C - not sure what esbo's actual exposure to the commercial side of programming is, but I expect it's not one of dealing with projects that are large than a few dozen files of a few hundred to thousand lines each, if any.
--
Mats
Not my feelings. But one of the rules on the web is to be respectful towards other members, yes? Especially when you are right out rude and typing rude comments.
I know I have violated this rule a couple of times, but I have been in error of judgement, and have reflected upon this and try no to do so anymore.
(You probably know how poorly esbo is liked around here; I've even been right out ride on a couple of occasions, but this time I am and will not be rude towards esbo because it serves no purpose and is a violation of the rules.)
It's also subjective, yes? In C, it is much harder to understand the concepts and making it work right, but in OOP, it can be hard to find a good design.
But I do agree with you, though.
esbo reminds me of those pseudoscientists who investigate cold fusion or perpetual motion. Completely non-dangerous, sometimes obnoxious, sometimes hilarious.
He's harmless and occassionally provides comic relief. I don't know why we have a huge thread about this.
Ah yes, it is always fun to see people jump on esbo, trying to dig or correct, and whatever arguments are put forward, esbo always dismisses them in some way or another! Quite funny!
Brightens the day, with threads like these :)
Because Salem (I think) split the thread, anticipating a flame war, but neglected to close the thread, thus allowing the flame war to happen instead of fading out to answers to behzad_shabani's question.Quote:
Originally Posted by brewbuck
As such, I will rectify the situation, even though it is too late. *thread closed*