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:
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).
>
> 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.
Oh, so C is better than C++ because it forces you to program in a certain way that happened to be the right way for your specific case? Sorry, but that doesn't really make sense. What is right for your project may not be right in other circumstances. I prefer a tool that lets me chose the most sensible approach instead of forcing its approach down my throat.
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().