| |||||||||||||
Why learn Fortran?Why learn Fortran?Posted Jun 29, 2012 0:49 UTC (Fri) by daniel (subscriber, #3181)Parent article: Why learn C? (O'Reilly Radar)
Why not learn every legacy language? C++ completely and utterly obsoletes C except for legacy applications and a few small areas where C is superior, designated intializers for example. Otherwise, C is just for legacy C applications.
(Log in to post comments)
Why learn Fortran? Posted Jun 29, 2012 2:29 UTC (Fri) by dskoll (subscriber, #1630) [Link] In order to learn C++, one must first learn C. The article title is "Why learn C?", not "Why use C and not C++?"
Why learn Fortran? Posted Jun 29, 2012 5:17 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
It might be better to skip plain C simply to avoid picking up bad habits (like using raw pointers).
Why learn Fortran? Posted Jun 29, 2012 15:25 UTC (Fri) by dskoll (subscriber, #1630) [Link] I disagree. You need to learn about pointers or else C++ will be completely mysterious... you won't have a good understanding of what's really going on under the hood.
Why learn Fortran? Posted Jun 29, 2012 17:38 UTC (Fri) by daniel (subscriber, #3181) [Link]
You can learn about pointers and arrays perfectly well in C++. In fact nothing stops you from writing C in C++ to your heart's content. However for the inveterate C programmer such as myself there is just so much more that you will never fully understand without actually doing it.
Why learn Fortran? Posted Jun 29, 2012 22:45 UTC (Fri) by dskoll (subscriber, #1630) [Link] Again: The title of the article is "Why learn C?" I'm a programmer, not a teacher, but it seems to me a pretty reasonable way to learn C++ is first to learn C and then to learn what C++ adds on top of C (as well as the points of difference between the languages.)
Why learn Fortran? Posted Jun 30, 2012 8:35 UTC (Sat) by HelloWorld (guest, #56129) [Link]
> I'm a programmer, not a teacher, but it seems to me a pretty reasonable way to learn C++ is first to learn C and then to learn what C++ adds on top of C
C++ doesn't just add on top of C, it replaces tons of stuff in the sense that while these things still exist, their use is frowned upon due to the presence of better alternatives. Therefore, it actually doesn't make sense to learn C first. Been there, tried that.
Why learn Fortran? Posted Jun 30, 2012 13:24 UTC (Sat) by dskoll (subscriber, #1630) [Link] You cut out the parenthetical part of my statement pointing out the areas of difference. Tell me, are you a teacher or a programmer? Have you taught anyone to program? I am not a teacher, but I have taught a few people to program, and IMO learning C first and then C++ makes a whole lot of sense, especially if it's a non-programmer doing the learning.
Why learn Fortran? Posted Jun 30, 2012 13:52 UTC (Sat) by HelloWorld (guest, #56129) [Link]
> You cut out the parenthetical part of my statement pointing out the areas of difference.
That's because the issues I am referring to aren't an area of difference. Malloc exists in C++ and works the same as in C, so clearly there is no difference in that regard, and yet, malloc shouldn't be used in most C++ code. There are areas of difference between C and C++ (such as the implicit conversion from void* to foo* and a few others), but that really isn't the issue.
> I am not a teacher, but I have taught a few people to program, and IMO learning C first and then C++ makes a whole lot of sense,
Why learn Fortran? Posted Jun 30, 2012 21:30 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
Good programmers should learn many programming languages, as such the first one they learn should not need to be the one they will be using to make a living.
C has the advantage that it's small enough that you can teach the complete language in a short time (when was the last time you saw a language book as small as the K&R C book?, or even one only double it's size?)
That's a huge advantage for a first language.
The fact that other languages work differently just means that when you move on to those languages, you should be learning the new stuff, but already have a solid grounding in the basic stuff.
My High School computer classes started by teaching Basic, then had a class in algorithms, and then covered assembly, and only then branched out to other languages. It resulted in a much more solid grounding, and much more flexible thinking than would come out of any of the College programs I have seen.
Why learn Fortran? Posted Jul 1, 2012 10:45 UTC (Sun) by HelloWorld (guest, #56129) [Link]
> Good programmers should learn many programming languages, as such the first one they learn should not need to be the one they will be using to make a living.
> > C has the advantage that it's small enough that you can teach the complete language in a short time (when was the last time you saw a language book as small as the K&R C book?, or even one only double it's size?) The Little Schemer, the Lua 5.1 Reference Manual. If the goal is to learn programming in general, I'd say that these language make much more sense than C -- no need to bother with memory management, mysterious bugs due to out-of-bounds memory access or C's idiosyncratic syntax and the preprocessor.
On the other hand, if your goal is to learn C++, learning C first doesn't make any sense either due to the reasons mentioned earlier. So unless you actually want to read or write C code, I don't see a reason to learn C.
Why learn Fortran? Posted Jun 29, 2012 16:33 UTC (Fri) by tshow (subscriber, #6411) [Link]
A colleague of mine and I once spent a week building a memory allocation annotation system to track down a heisenbug that turned out to be a C++ class miscast. C++ will not save you there.
C vs. C++ vs. ... Posted Jun 29, 2012 11:14 UTC (Fri) by dps (subscriber, #5725) [Link]
C vs.C++ is a flame war I try to keep out of... but the idea that C++ makes C obsolete is nonsense. In my experience a modern C program executes faster than a modern C++ program, due to the extra scaffolding of the latter. C is also probably easier for compilers to optimise---reasoning a reference count is useless might require global analysis.
Sane use of char * can be *much* faster than std::string if you want to transform a string in in way not built into std::string without preserving the original. This was 30%+ of a real program until I aggressively optimised in a way impossible with std::string and reduced it to under 1%.
The more extreme OO people claim OO makes all other styles of programming obsolete and some even think program should be modelled as communicating concurrent objects. The later is completely stupid: this mathematically much harder to analyse than sequential programs.
When the OO people claim I should use objects like sets, queues, lists, maps, etc to simplify programming I agree. When they say how these are implemented does not matter I part company: once I know what operations are important that is a good clue about the right implementation technique.
I not infrequently end up wanting an extended type, for example a tree with subtree size information, or a fast version of a specialised operation. If you can't use a low level language and have a requirement like this then you lose completely when this happens.
When speed is not critical and a high level language is a big win I often use it. A lot of my time is spent writing python code which makes extensive use of dictionaries. The same program in C or C++ would be unlikely to use dictionaries.
C vs. C++ vs. ... Posted Jun 29, 2012 17:26 UTC (Fri) by daniel (subscriber, #3181) [Link]
"In my experience a modern C program executes faster than a modern C++ program, due to the extra scaffolding of the latter."
Your experience is lying to you. If you write the same program in C and C++ and compile it with GCC you will get the same object code because they use the same code generator and optimizer. Even exceptions these days are compiled so that exception handling generates code only on the throw path, and of course you can compile C++ without exceptions at all. The "extra scaffolding" you speak of does not exist, unless you ask for it and that is entirely up to you.
C vs. C++ vs. ... Posted Jun 29, 2012 17:52 UTC (Fri) by wahern (subscriber, #37304) [Link]
If you're not using C++ features, then don't use C++.
C++ as C sucks. C++'s conversion rules work well for C++ code, not for C. C++'s type tagging works for C++, not C.
If you want to code in C, use C. If you want C++, use C++. If you want Lua, use Lua. Although, for my money I'll take C and Lua/Perl/Python, and just skip C++ altogether. For many of the things that C++ does better, other languages do better still. So I don't bother, but that's just me.
However, it's really annoying when people argue that you can use C++ just like C. No, you can't. They're completely different languages. extern "C" does not drop you down into "C" mode.
And I don't care if g++ can produce the same output some of the time for equivalent constructs. I can make GCC produce the same code, once sitting in my chair and once while standing on my head. But why would I do that?
C vs. C++ vs. ... Posted Jun 29, 2012 21:33 UTC (Fri) by daniel (subscriber, #3181) [Link]
"If you're not using C++ features, then don't use C++"
Wouldn't that be a self fulfilling prophesy?
C vs. C++ vs. ... Posted Jun 29, 2012 18:10 UTC (Fri) by tshow (subscriber, #6411) [Link]
It is not "entirely up to you" unless you're the only person on your project, or unless you're empowered to behead infidels on your team.
Unfortunately, that's exactly the argument I've heard from every C++ evangelist on every project I've ever seen converted to C++. Six months later, the project compile time has gone from 30 seconds to half an hour, the number of lines of code in the project has gone up by an order of magnitude, and the codebase is almost functionally back to where it was when the project was converted from C.
There's nothing intrinsically wrong with C++ when it's used properly. The problem is that all the features that C++ adds to C encourage abuse, and it's hard to find programmers with self control.
On one game console (PS2) project I worked on, for example, the system was converted to C++ partway through the life of the project. One of the guys decided that it would be an excellent idea to wrap the whole project in a class, so he could create an instance of the game and stick all the init code in the constructor. And of course, it had to be a singleton class, so it had extra frippery in it to conform to the design pattern.
It didn't change the functionality at all, it just added crud to the code and the runtime to satisfy someone's broken idea of elegance.
On the same project, we needed to take debug input from the keyboard. There was a small API for that; it should have (and later was) just a matter of calling that API with a little custom command shell. The first crack at it, though, was taken by another of our C++ guys, who decided that the *real* problem was that we needed a key input-handling class hierarchy with templating and several levels of inheritance before we finally got down to a singleton class wrapping the API. I presume if we'd let him continue he'd have given similar treatment to the command shell. Instead, I ripped out (IIRC) 6 files and more than 50K lines of code (before template expansion) and replaced it with about 20 lines of functionally equivalent C.
Even in the hands of good programmers, C++ has nonobvious costs. One of the biggest performance problems on modern hardware is memory access speed; the more you can keep things operating out of cache, the faster things go. C++ template programming and STL encourage a programming style that ignores this. STL in particular is egregious for performance costs due to cache thrashing.
The problem is, someone will go and write a pair of simple programs, one of which does a string sort in C, and one of which does the equivalent in STL. The two will run at about the same speed, if the programmer is competent and honest. The erroneous conclusion that gets drawn from this is that the two have identical performance characteristics.
The C++ program will be larger, and will eat more cache. In a toy benchmark program that isn't particularly noticeable, but once you've scaled up to the size and functionality of a full program it becomes a serious performance hit. Cache thrashing kills you. Making things worse, the problem will likely have metastasized to the point where it's not even obvious what happened. The interwoven class hierarchy and (usually) STL dependency of the project makes it impossible to even contemplate simplifying.
C vs. C++ vs. ... Posted Jun 29, 2012 21:33 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
Stop spraying FUD, please. Almost everything you say is just plain wrong.
C vs. C++ vs. ... Posted Jun 29, 2012 22:48 UTC (Fri) by dgm (subscriber, #49227) [Link]
No way, the guy is right on the spot.
Object orientation is about abstraction and information hiding. When you need pure speed, hiding information gets in your way, because it prevents optimization. When you need maintainability, though, it can become very handy... if used correctly. What he says about abstraction-creep (AKA over-engineering) is absolutely true. I have seen just too many cases of MVC used to handle simple input dialogs that I don't find it funny anymore.
But, as always, the problem is not with the language, which is just a notation. The problem is poor programming. C is no exception here too. Every time I see sprintf used like this:
sprintf(some_struct.some_member, "%s", some_string);
something breaks inside of me.
C vs. C++ vs. ... Posted Jun 29, 2012 22:54 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
Object orientation is not about hiding something, but about organizing things so they stay manageable.
Besides, modern C++ actually encourages separation of data and algorithms.
C vs. C++ vs. ... Posted Jun 30, 2012 7:12 UTC (Sat) by khim (subscriber, #9252) [Link] Besides, modern C++ actually encourages separation of data and algorithms. Which lead to aforementioned phenomenon you've called FUD. As as guy who recently converted our performance-critical piece of code from C to C++ and achieved 10x smaller code and 10x faster execution time (both are NOT exagerration: it's quite literally 10x+ smaller and 10x+ faster... has more features, too) I observe this every day. Our "C++ guys" continue to complain that 1000 lines function with dozens of macroses is just ugly, but for some strange reason their 10'000 of classes spread of dozens of files should be considered as "elegant". I guess it's partially matter of the opinion but 10x difference in speed is objective thus we are proceeding with C++ to C switch (for that particular component) anyway.
C vs. C++ vs. ... Posted Jun 30, 2012 8:23 UTC (Sat) by HelloWorld (guest, #56129) [Link]
Your comment is self-contradictory. Did you switch from C to C++ or vice versa?
If you switched from C++ to C, then the only explanation for that phenomenon is poor developers.
C vs. C++ vs. ... Posted Jul 1, 2012 18:52 UTC (Sun) by khim (subscriber, #9252) [Link] Your comment is self-contradictory. Did you switch from C to C++ or vice versa? From C++ to C, of course. If you switched from C++ to C, then the only explanation for that phenomenon is poor developers. Not really. The difference is subtler. C++ code uses nice, buzzword-compliant "flexible" architecture (similar to the style showed here). C code uses (as I've said) large functions and macroses. Instead of 10 layers of indirect functions is has dozen of flags (which are processed by said macroses). This means that it's impossible to do many things with C module which were possible with C++ module - and this is good thing. Because it means that instead of abusing callbacks to do something strange and exciting people need to change the core - which then means that code will be reviewed by people who know how said core works. Which in turn means that fewer stupid things will be introduced in the system.
C vs. C++ vs. ... Posted Jul 1, 2012 19:16 UTC (Sun) by HelloWorld (guest, #56129) [Link]
> From C++ to C, of course.
Well, you wrote that you converted the code from C to C++.
> Not really. The difference is subtler. C++ code uses nice, buzzword-compliant "flexible" architecture (similar to the style showed here). C code uses (as I've said) large functions and macroses. Instead of 10 layers of indirect functions is has dozen of flags (which are processed by said macroses).
C vs. C++ vs. ... Posted Jun 30, 2012 8:29 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
Uhm. 10000 classes probably mean:
1) Your developers use functors/algorithms implemented as classes and not freestanding functions/lambdas. If they are stateless, then that's just a matter of taste. 2) Your developers in fact do not know how to separate data from algos. 3) Your C code has 10000 structures instead of classes.
C vs. C++ vs. ... Posted Jul 1, 2012 19:03 UTC (Sun) by khim (subscriber, #9252) [Link] Uhm. 10000 classes probably mean: Sorry, I've messed up with relevant sentence. I meant not 10'000 classes (that'll be too extreme of a subsystem to rewrite in one go), but tens of thousand lines (spread over hundred or so small classes in dozen of files). Your C code has 10000 structures instead of classes. Not even close. It has couple of structures - but these are only used for testing. Production code just passes data around using regular variables (on registers if you use -O2). This means that a lot of things are just impossible to do without major refactoring/rewriting of the code (because the data is just not available where you need/want to have it), but why is that such a big deal? As long as the API is internal to this piece of code it's not a problem... and when you want to present API to the "outside world" you often want/need C API anyway...
C vs. C++ vs. ... Posted Jul 1, 2012 19:32 UTC (Sun) by apoelstra (subscriber, #75205) [Link]
The flip side of "data not there when you need it" is that you get much smaller scope (and therefore easier analysis, easier optimization, etc), and you also get guarantees that data will not be modified except by functions who specifically ask for it.
But that is a generic argument against OO-style abstractions, not necessarily an argument specifically for C.
C vs. C++ vs. ... Posted Jul 1, 2012 20:27 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
Again, having code split into small files is just a matter of taste. I prefer my files to be less than 1000-2000 LOCs (especially in plain C), so I can easily navigate them visually. It doesn't affect performance in any way.
C vs. C++ vs. ... Posted Jul 1, 2012 22:36 UTC (Sun) by juliank (subscriber, #45896) [Link]
Of course it does, if you have many internal functions, you can declare them static, if they are in the same unit. If you split them over multiple files, the compiler cannot inline them and/or the program needs to look them up at run-time (unless you use ELF symbol visibility).
C vs. C++ vs. ... Posted Jul 1, 2012 22:13 UTC (Sun) by juliank (subscriber, #45896) [Link]
I even have a problem just with people using sprintf(). They should use snprintf().
C vs. C++ vs. ... Posted Jul 3, 2012 12:39 UTC (Tue) by tshow (subscriber, #6411) [Link]
> Stop spraying FUD, please. Almost everything you say is just plain wrong.
Do you have any actual rebuttals?
C vs. C++ vs. ... Posted Jun 29, 2012 21:53 UTC (Fri) by daniel (subscriber, #3181) [Link] ...on every project I've ever seen converted to C++. Six months later, the project compile time has gone from 30 seconds to half an hour, the number of lines of code in the project has gone up by an order of magnitude, and the codebase is almost functionally back to where it was when the project was converted from C.Anecdotes are wonderful aren't they? Even better than statistics for proving pet points. Interestingly, one of my projects supports modules written in either C or C++. I just ran a compile speed bakeoff between some representative files with equivalent number of lines. Result: gcc compiles 2.4 times faster than g++. I would qualify that with "if you don't go crazy with templates". I believe you will find this result quite reproducible. It is a far cry from the factor of 60 you claim. As for number of lines of code, in every case where I have converted a C program of any complexity to C++, the program has gotten smaller, sometimes by a significant amount like 50% in cases where I was beating my head against the wall hacking up object style inheritance in C. As far as functionality goes, I think it took me roughly a day to convert a good sized C project of 20K LOC to "C in C++", at which point the functionality is obviously equivalent. Of course it did not stay as C-in-C++, it actually began to accrete new functionality at a rate that was hitherto impossible in its C form. I would submit that where your experience is different there is something wrong with the engineering process, not the language platform.
What is Science? Posted Jun 30, 2012 0:59 UTC (Sat) by Wol (guest, #4433) [Link]
JUST A BUNCH OF ANECDOTES!
Which are then studied, analyzed, and used to predict the future.
If the future is successfully predicted, then we have a workable scientific theory.
It really annoys me when people say "that's just an anecdote". No it isn't! It's a data point! It may be an outlier, it may be invalid, it may be wrong, but it is also well known that people will dismiss inconvenient data points without seriously trying to understand them. Feynman gives a very good example of a rogue data point setting quantum mechanics or something like that back 20 years - they didn't bother to see if any data points were rogue, so the "wrong" answer was used and messed up everything else until the problem was spotted - MANY years down the line.
Anyways - my take on this high/low-level stuff? For any given programmer, their productivity measured in LOC is roughly constant regardless of the language. If it takes 10 lines of C or 100 lines of C++, use C. You'll get it done in one tenth the time. On the other hand, if it takes 10 lines of C++ or 100 lines of C ... you get my drift.
Cheers,
What is Science? Posted Jun 30, 2012 1:41 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
>On the other hand, if it takes 10 lines of C++ or 100 lines of C ...
Usually it's the other way around..
What is Science? Posted Jun 30, 2012 8:15 UTC (Sat) by HelloWorld (guest, #56129) [Link]
That can't possibly be true. Everything that can be done in C can be done in C++, and more.
What is Science? Posted Jun 30, 2012 8:27 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
I'm speaking about rewrites in "C++ style", not simple "recompile with g++" rewrites.
They do tend to shrink amount of lines of code quite significantly.
What is Science? Posted Jun 30, 2012 8:39 UTC (Sat) by HelloWorld (guest, #56129) [Link]
You're contradicting yourself. Wol said "if it takes 10 lines of C++ or 100 lines of C", you said "it's the other way around..", and now you're saying that rewrites in C++ style tend to shrink the amount of code.
What is Science? Posted Jun 30, 2012 22:00 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
Yes, rewrites in modern C++ tend to shrink code significantly compared to plain C. There's no contradiction.
What is Science? Posted Jul 1, 2012 10:17 UTC (Sun) by HelloWorld (guest, #56129) [Link]
Uh, yes there is, unless my english parser is utterly broken, but I don't think so.
What is Science? Posted Jun 30, 2012 8:28 UTC (Sat) by khim (subscriber, #9252) [Link] This depends on your design very much. If you've dreamed up nice buzzword-compliant architecture of your project with classes, delegates and other such things then usually C++ code is smaller. If you instead will think about the task on hand and remove all the useless abstractions then often the end result will be less buzzword-compliant yet much smaller. Of course you can write similar code in C++, but it'll not be "ideomatic C++".
What is Science? Posted Jun 30, 2012 8:44 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] Uhm. Why classes are 'buzzword'? They are, like, 30 years old buzzword. In fact, even in languages like Java/C# architects now try to separate data from functionality (Fowler calls that 'anemic domain model'). And I don't understand that bit about 'useless abstractions'. For example, this kind of code:
std::function<void(int,int)> point_callback;
struct dist_summator
{
Double dist;
void add_point(double x, double y, double z)
{
dist+=sqrt(x*x+y*y+z*z);
}
};
dist_summator sum;
point_callback=boost::bind(&dist_summator::add_point, &sum, _1, _2, 123.0d);
...
//Get points
...
//Use sum.dist
Is worse than something like this:
(void)(void*, int, int) point_callback;
void * point_callback_ctx;
typedef struct _dist_summator_with_fixed_z_ctx
{
double sum;
double fixed_z;
} dist_summator_with_fixed_z_ctx;
void sum_x_y(void *ctx_ptr, int x, int y)
{
dist_summator_with_fixed_z_ctx *ctx=(dist_summator_with_fixed_z_ctx*)ctx;
ctx->sum+=sqrt(x*x+y*y+ctx->z*ctx->z); //Whoopsie, forgot about ints here!
}
dist_summator_with_fixed_z_ctx ctx;
point_callback = &sum_x_y;
point_callback_ctx = &ctx;
//Get points
...
//Use ctx.sum
What is Science? Posted Jul 1, 2012 5:50 UTC (Sun) by wahern (subscriber, #37304) [Link]
Both of those examples are really ugly. Arguing that one dog is uglier than the next is kind of pointless.
What is Science? Posted Jul 1, 2012 15:16 UTC (Sun) by hummassa (subscriber, #307) [Link]
Otoh they are close-to-what-I-have-found-IRL many, many times in the last 20 years.
What is Science? Posted Jul 9, 2012 5:27 UTC (Mon) by daniel (subscriber, #3181) [Link]
And the C example is actually prettier than plenty of kernel code that does similar things.
What is Science? Posted Jun 30, 2012 19:28 UTC (Sat) by Kluge (guest, #2881) [Link]
"Feynman gives a very good example of a rogue data point setting quantum mechanics or something like that back 20 years - they didn't bother to see if any data points were rogue, so the "wrong" answer was used and messed up everything else until the problem was spotted - MANY years down the line."
Reference?
What is Science? Posted Jun 30, 2012 23:40 UTC (Sat) by Wol (guest, #4433) [Link]
It's mentioned in "Surely you're joking, Mr Feynman" or "What do you care what other people think"
But it was something like someone did an experiment to determine the spin of some particle. There was one data point that was way out, and actually was sufficient to dominate the result. Unfortunately it was the wrong result.
However many years it was, down the line, Dick looked at what he was doing and said "hey, if that particle was actually the opposite spin, everything would make sense". Then he went back to the original proof and said "hey, I remember thinking that proof was screwy, when it first came out!". Then he actually checked the maths, and said "ooopppsss".
Cheers,
What is Science? Posted Jul 1, 2012 11:15 UTC (Sun) by man_ls (subscriber, #15091) [Link] For any given programmer, their productivity measured in LOC is roughly constant regardless of the language.Easy there. That is one of the foundations of function points, as seen in Casper Jones' "Applied Software Measurement"; and it is also utterly wrong. Otherwise we would all be programming in "5th generation languages", i.e. Excel macros. If you want anecdotal evidence, my productivity (measured in LOC/day) in Perl or in assembly is abysmal. On the other hand, in PHP my productivity is insanely great writing garbage that doesn't work, just great for working code, but if I want to develop tight code then it becomes glacial. In Java it is great but diminishing asymptotically as I approach correct, maintainable code. There are also serious arguments: high-level languages are less important for productivity than high-level frameworks which do everything for you, be it in C, Python or Excel. But the quality of the framework then becomes the dominant factor; if it takes ages to track down frequent bugs then productivity plummets faster than a sheep from a tree. As we have not yet invented measures for framework quality or completeness, the question of productivity remains completely open and mostly independent of the language. In time I have learned to distrust frameworks, especially when they are high level. (By the way, I contend in passing that PHP is a framework rather than a language.)
C vs. C++ vs. ... Posted Jun 30, 2012 2:50 UTC (Sat) by slashdot (guest, #22014) [Link]
The problem seems to be in the hiring process, not in the language choice.
C vs. C++ vs. ... Posted Jul 4, 2012 20:16 UTC (Wed) by ReadWrite (guest, #85472) [Link]
My observation is good quality code written in C++ is more scalable and easy to extend than written in C. where it involves large amount of configuration/parameter data, I would rather use C++. I have seen many examples where there is no intention to improve or re factor badly structured C programs, so that only the original developer knows the code and he /she can only fix any bug in the code, and that provides job security. Engineering or non Engineering managers alike are only interested in the functionality, and are interested in the performance only when it becomes a commercial issue. A well structured good performing code is not rewarded in fact is seen as taking too long to complete for a minor functionality, or if it can be extended, updated by other developers, that implies it was not very complex in first place . As the common saying goes "Bad programmers become Managers",
If performance to the microsecond is not an issue, I Would be tempted to develop in C++, but again I can mix C(for performance) and C++(for extendability).
C vs. C++ vs. ... Posted Jul 4, 2012 21:17 UTC (Wed) by dgm (subscriber, #49227) [Link]
> good quality code written in C++ is more scalable and easy to extend than written in C.
If you reword it like "C++ offers you more tools to write more scalable and easy to extend code", then I agree with you. How do you use those tools is up to you, and mastering them takes time, it's not easy to learn when to chose one option over others.
C vs. C++ vs. ... Posted Jul 9, 2012 5:44 UTC (Mon) by daniel (subscriber, #3181) [Link]
"If performance to the microsecond is not an issue, I Would be tempted to develop in C++"
Having spent a couple of years in the high frequency trading business profiling and optimizing everything to the nanosecond I can state with confidence that the C and C++ code I wrote executed at precisely the same speed, but the C++ was shorter, easier to read, more maintainable and far easier to extend to new functionality.
C vs. C++ vs. ... Posted Jul 1, 2012 15:43 UTC (Sun) by nix (subscriber, #2304) [Link] If you write the same program in C and C++ and compile it with GCC you will get the same object code because they use the same code generator and optimizer.That's wrong: some transformations are done at the language-dependent tree stage, and these can differ between C and C++. Further, the languages have distinct constraints on the optimizer. e.g.: Even exceptions these days are compiled so that exception handling generates code only on the throw pathThat's wrong: C++ code that doesn't use exceptions can still have them thrown through it at any points not marked nothrow (or marked as extern "C" or something similar to indicate the impossibility of exceptions emanating from those points), so not only are cleanup regions required, but a large number of additional abnormal edges are introduced which can and do constrain the optimizer. Thus, you'd often get different code compiling C code as C versus compiling it as C++, even if the optimizers and code generators were completely identical.
C vs. C++ vs. ... Posted Jul 4, 2012 12:52 UTC (Wed) by jwakely (subscriber, #60262) [Link] marked as extern "C" or something similar to indicate the impossibility of exceptions emanating from those points extern "C" doesn't mean any such thing.
#include <stdio.h>
struct E { };
extern "C" void f();
int main()
{
try {
f();
} catch (const E&) {
puts("Caught");
}
}
extern "C" void f() { throw E(); }
C vs. C++ vs. ... Posted Jul 4, 2012 13:37 UTC (Wed) by andresfreund (subscriber, #69562) [Link]
As far as I can see this is undefined behaviour because youre throwing an exception through C linkage which the stack unwinding/exception propagation process doesn't have to be able to do.
C vs. C++ vs. ... Posted Jul 4, 2012 15:10 UTC (Wed) by nix (subscriber, #2304) [Link]
It's not undefined behaviour so much as it might just not work. Some functions in glibc (e.g. qsort()) are explicitly compiled with -fexceptions so as to support C++ exceptions thrown through qsort() from the callback function, but this is very rare: I've never seen it in C code outside glibc, even for C functions that invoke callbacks.
C vs. C++ vs. ... Posted Jul 4, 2012 15:17 UTC (Wed) by andresfreund (subscriber, #69562) [Link]
Why is that a contradiction to being undefined behaviour?
C vs. C++ vs. ... Posted Jul 4, 2012 18:30 UTC (Wed) by jwakely (subscriber, #60262) [Link]
1) I never claimed it had to work, my point is that extern "C" does not mean "cannot throw".
2) It doesn't _have_ to work, but it can work (which would make it closer to implementation-defined or conditionally-supported, not undefined) and does with (at least) GCC, Clang and Solaris CC. There's even a cross-platform standard describing it. For a nice overview of the "personalities" that are used to support mixed-language exceptions to propagate through call frames using different languages see http://llvm.org/docs/ExceptionHandling.html
C vs. C++ vs. ... Posted Jul 4, 2012 15:08 UTC (Wed) by nix (subscriber, #2304) [Link]
Oooh. Interesting. Given that 99% of C libraries are not compiled with -fexceptions and do not specify anything nothrow-related in their prototypes (of course not, they're C), this suggests that G++ is introducing a very large number of unnecessary abnormal edges for exceptions potentially raised in calls to such functions that cannot possibly ever be thrown. I wonder how much this is impairing optimization?
C vs. C++ vs. ... Posted Jul 4, 2012 15:51 UTC (Wed) by scottt (subscriber, #5028) [Link] > Given that 99% of C libraries are not compiled with -fexceptionsNote that Red Hat and Fedora has been building the whole distro with -fexceptions for years: rpmbuild --showrc | grep cflags -14: __global_cflags -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions <...>I suspect other distros do the same.
C vs. C++ vs. ... Posted Jul 4, 2012 18:43 UTC (Wed) by jwakely (subscriber, #60262) [Link]
Doesn't the stack have to be unwound similarly for thread cancellation?
The C frames don't need to do any cleanup (no destructors) and should just let the exception propagate unhindered, until it reaches a frame with the right C++ personality to handle it.
I might be completely wrong, but I don't see any obvious reasons the generated code should be different.
Why learn Fortran? Posted Jun 30, 2012 20:59 UTC (Sat) by cmccabe (guest, #60281) [Link]
> Why not learn every legacy language? C++ completely and utterly
> obsoletes C except for legacy applications and a few small areas > where C is superior, designated intializers for example. Otherwise, > C is just for legacy C applications.
I disagree with your opinion that "C++... obsoletes C."
However, this is all off-topic here, because the article is about "why learn C?" and learning C is a prerequisite for learning C++.
Why learn Fortran? Posted Jul 19, 2012 12:37 UTC (Thu) by philomath (guest, #84172) [Link]
"C++ completely and utterly obsoletes C except for legacy applications"
Thanks for the good laugh, it made my day.
Why learn Fortran? Posted Jul 21, 2012 12:53 UTC (Sat) by hummassa (subscriber, #307) [Link]
Don't sweat it -- many people will think the joke is on you! :-D
|
|||||||||||||