2

C++ introduces OOPS, templates and variety of other concepts. But sometimes I am stuck in unmanageable storm of calling convention incompatibilities between methods, convoluted casting between distantly connected classes and struggling with code that forces me think in the level of byte-alignment.

I am very tempted to go back to plain old-C language that is low level enough and simple enough that I can spend much of my time solving a problem at hand, than having to figure out the conceptual implementation and nuances of using C++.

What is your take on such an issue. Using C-language as the first class citizen in my code-base and coating it at the end with a C++ primer make for a better way to manage a conceptual code-base ??

Kate Gregory
  • 18,808
  • 8
  • 56
  • 85
Vishnu Pedireddi
  • 2,142
  • 4
  • 25
  • 34
  • 6
    Smart pointers & STL. Well worth their weight in gold. – Byron Whitlock Jun 18 '10 at 21:01
  • 5
    Get a book that teaches C++ as C++, not as C with other stuff. – Cogwheel Jun 18 '10 at 21:11
  • 8
    Do NOT write C and coat it with C++. Write a library in C and provide a C++ API if you like, but keep the C and C++ parts separate. C is a fairly simple language, C++ is complicated and powerful, and putting a C++ gloss on C code gives you the worst of both worlds. – David Thornley Jun 18 '10 at 21:13

6 Answers6

9

sometimes I am stuck in unmanageable storm of calling convention incompatibilities between methods, convoluted casting between distantly connected classes and struggling with code that forces me think in the level of byte-alignment.

It sounds like you might be doing something wrong. I don't know what sorts of projects you work on, but I've rarely had to deal with any of those things--certainly never in over 99.9% of the code I've written--and I've written a bit of C++ code (though not nearly as much as others here on StackOverflow).

What is your take on such an issue.

You should consider getting a good book on C++ (like one of the introductory books or any of the best practices books listed in The Definitive C++ Book Guide and List) and really learn C++ if you want to use C++.

Community
  • 1
  • 1
James McNellis
  • 348,265
  • 75
  • 913
  • 977
5

I often feel the way you do. C++ compilers are incredibly bitchy about insignificant details and, if you considered them an object, they have appalling encapsulation, and they give horrendously bad error messages. Sometimes, programming C++ feels like fighting against the Standard.

However, I'd never, ever ditch it for C. If you're considering it, you fail C++. Yes, templates and their syntax and some of their semantics can be a bitch, but the power they offer is unparalleled. The things offered like automatic memory management and the power of the STL just can't be matched by C.

In addition, nobody is forcing you to use templates. You could write a whole C++ program using nothing but the pre-provided templates. You could never use polymorphism, or templates, or encapsulation, or object-orientation as a whole, and yes, sometimes none of those solutions are appropriate. But it's plain stupid not to give yourself the option.

And if you're casting classes in C++ (frequently), it sounds to me like whoever wrote the original code flat out didn't know what they were doing. Same for byte alignment.

Puppy
  • 144,682
  • 38
  • 256
  • 465
  • "If you're considering [ditching C++], you fail C++." This is exactly backwards, a chiasmatic failure. When I ditch C++ (and I do, whenever I can), it's because C++ failed me. [More here](http://yosefk.com/c++fqa/). – Tim Schaeffer Jun 18 '10 at 23:05
  • 3
    @Tim Schaeffer: The FQA is a little piece of crap. Excuse my english. It has some truths entangled with completely false statements and a ton of half truths. Then again, someone reads that and trusts the contents... – David Rodríguez - dribeas Jun 18 '10 at 23:35
  • 1
    @TIM: for C. If you moved to say java/c# it can be beneficial. But C is 100% a step backwards – Puppy Jun 19 '10 at 12:51
  • @Rodriquez: Your comment is less than useful; it is a rhetorical kick in the shins, not an argument. – Tim Schaeffer Jun 21 '10 at 13:25
  • @DeadMG: Maybe. In my case (embedded coding on an AVR, 64k flash, 4k ram, no OS) a move to Java/c# is not possible. – Tim Schaeffer Jun 21 '10 at 13:36
  • @Tim: Well, it would take a fool to go from C++ to C, so if you can't go to C# or Java, then you're pretty much stuck with C++. – Puppy Jun 21 '10 at 15:28
  • @DeadMG: Well, there is always ADA ;-) – Tim Schaeffer Jun 22 '10 at 15:10
  • @Tim: Can't say I've ever used ADA, so no comments there :P C++ -> C is stupid, though. – Puppy Jun 22 '10 at 17:02
  • @TimSchaeffer, you have 4k ram and you are using C++ for what? You either code in it like you do with C, or fill your memory by extra information using stl templates. Stick with C if you want my opinion. I have to agree with DeadMG though, except very special cases, it doesn't make sense to move from C++ to C, at the very least you can basically write almost-C in C++ and if you felt like it, take a feature or 2 from C++ – Shahbaz Nov 02 '11 at 23:37
3
  • I've never had to worry about byte alignment unless I was writing binary files.
  • Casting distantly related classes to each other is bad design.
  • I've never worried about calling conventions unless I was writing interrupt routines.
Paul Nathan
  • 39,638
  • 28
  • 112
  • 212
  • 1
    byte-alignment becomes important in large code-bases. After certain thousand lines of execution, it becomes very important to check for byte-allignment. And what about processors other that x86 like ARM ?? Consider using a pure C++ classes being consumed COM classes, you will see an maze of calling convention incompatibilities exposed at runtime. – Vishnu Pedireddi Jun 18 '10 at 22:44
  • 3
    @de costo: "byte-alignment becomes important in large code-bases. After certain thousand lines of execution, it becomes very important to check for byte-allignment. " how so? can you give details? – Paul Nathan Jun 18 '10 at 22:54
  • 3
    Byte alignment in C++ is very rarely an issue of concern (serialization/network protocols), and then again when it is an issue it is just as much an issue in plain C (and Java, and C#, and... name it). – David Rodríguez - dribeas Jun 18 '10 at 23:39
1

If you forced to frequently "cast distantly connected classes" and "think in the level of byte-alignment" - there is something wrong with the architecture of the project. Language is not the problem here.

C++ is heavy. You probably should not use all the features it provides. KISS principle, you know. You can always pretend that C++ is just "C with classes" and exploit templates and other "hard" stuff only when it will provide reasonable improvement in some areas (like code simplicity, as a matter of fact).

Dark
  • 195
  • 7
  • 4
    I strongly disagree. You should use every language feature that you understand, whenever it is appropriate to use each feature, and you should strive to understand features that you don't understand when they would make the task at hand easier. Pretending that C++ is just C with Classes is a terrible mistake: you miss out on most of the most important, useful, and time-saving features of the language and you end up having to write more code than you really should need to write, and more code means more bugs. – James McNellis Jun 18 '10 at 21:47
  • It is usualy better to write a little more "simple" code, than try to implement a "smart" thing, and do it wrong. Although I agree that using right tool for the task is the best, it is not obvious what tool is "right" in C++ because of the multi-paradigm nature of tha language. Some arguments: http://yosefk.com/c++fqa/index.html – Dark Jun 18 '10 at 22:19
  • +Sorowfull fact: if you fully understand the feature you used, it doesn't mean that one, who will maintain your code, is understand the feature on that level too. – Dark Jun 18 '10 at 22:25
  • @James: I do not disagree with you from a project manager's perspective. "You should use every language feature that you understand, whenever it is appropriate to use each feature, and you should strive to understand features that you don't understand" Using many language features in your codebase no doubt make it close to utopia, but from maintainability, usability and understandability would go down. If I were to implement an amazingly efficient scheduler algorithm, the simple the language features i use, the more robust and easy to understand my code is and thus to maintain it. – Vishnu Pedireddi Jun 18 '10 at 22:27
  • 1
    If a language feature does not make the resulting code simpler, then that would be an inappropriate opportunity to use that language feature. There are usually multiple "right" approaches, and usually they involve a combination of various language features and idioms. I always write code assuming that whoever will be maintaining it knows the language at least as well as I do or is at least capable of learning the language and its features. I don't think that is an unreasonable assumption. – James McNellis Jun 19 '10 at 02:11
0

I recently switched back from C++ to C and took a liking in C99. But it certainly depends on what you are doing. For a library of reasonable size, C99 with its advantages over C89, is good enough, and as somebody else said you can easily provide a C++ wrapper, if necessary. C++, I only would go for a big project that has large amount of code reuse (internal or external) with templates.

Things from C++ I missed in C89 have nothing to do with objects or so, but are simple things as declaration of variables inside the for and a well defined inline feature. C99 has that plus variable length arguments for macros, so I am happy with it.

Community
  • 1
  • 1
Jens Gustedt
  • 76,821
  • 6
  • 102
  • 177
  • Just out of curiosity, What would be functional equivalence of object in C++ ? Any data-structure or pattern that is of particular importance ?? – Vishnu Pedireddi Jun 18 '10 at 22:40
  • 2
    How much of your thinking effort goes into resource management? – David Rodríguez - dribeas Jun 18 '10 at 23:42
  • @de costo: I just use C struct with some naming conventions for initializers and other `methods'. BTW, another feature of C99 are named initializers. They make `static' initialization much more convenient. – Jens Gustedt Jun 19 '10 at 06:11
  • @David: reasonable, I think, but if your question targets the lack of destructors, yes, this is the one feature that I am missing. With the lack of constructors you get along, I have some macros for that, but having things deleted automatically would be nice. But in any case during developement I always run my code under valgrind, this is a very reliable quality test for the allocations. – Jens Gustedt Jun 19 '10 at 06:20
0

You are not alone. These are all well-known flaws in C++, a language which forces developers to attend incompatible conventions, to struggle to overcome a convoluted caste system, and to take their code in for byte-realignment every 3,000 lines. Definitely switch back to C.

John
  • 21
  • 5
    Right... after about 3000 lines the objects get bored and move for better views. It is then that keeping them aligned is most important, else anarchy will overtake, and who knows if they will even start partying and drinking. – David Rodríguez - dribeas Jun 18 '10 at 23:43