Elysian Shadows

Reading on some other forums, people claim c++ should be avoided as a programming language, because it is inherently harder that others, that it makes a poor use of some programming paradigms and that you end up solving issues related to the language itself, rather than the problem you are trying to solve, just to quote a few examples.

what are your thoughts on this subject? some claim people should just move to plain c or something like java.

P.s. I don't want this to become a flamewar, if it does, please delete this thread.

I think that these claims are typically made by people who aren't sufficiently experienced with C++ to make any such accusations. While C++ is not without its faults--no language is--I do not think that it should be avoided as a general rule. If there are other languages better suited to a purpose, by all means, use them over C++. If someone is just starting out with learning how to program, C++ is not the best language. Programming languages are tools, and all tools have their uses. Each tool has its inherent advantages and disadvantages, but I don't think any tool is itself bad. It's a matter of the programming choosing the right tool and using it correctly. C++ is a general-purpose programming language, so it may be one of the right tools in many cases, although it's often not the right tool. People take its general-purpose nature and its relatively steep learning curve as signs that it's a bad language, but the language is fine--they're just using it wrong.

As for ending up solving language problems instead of the problem trying to solve: in my experience, if you end up doing this, your design is fucked to begin with and you should go back to the drawing board. Chances are if the language is getting in your way, any other language you try to implement your system in will get in the way as well, perhaps moreso.

Disclaimer: I learned C++ as my second language (after C), and I've been using it as my go-to language ever since. Ill-formed (I won't say baseless, though I think some criticism is unfounded) criticism of C++ boils my blood. I am a bit biased.

Nokurn wrote:Chances are if the language is getting in your way, any other language you try to implement your system in will get in the way as well, perhaps moreso.

I agree with everything you said except this sentence. In my opinion, chances are if the language is getting in your way you're using the wrong language. That doesn't necessarily mean C++ is the wrong language, it just means that C++ is the wrong language for you, be it inexperience or otherwise.

Never underestimate choosing the right tool for the job (and keep in mind the "right tool" varies from person to person). This is why I think it better to have light experience in many languages than be an expert at one. That said, you still need to understand the core concepts of programming to be able to choose appropriate tools. The nuances of each individual language come with experience.

dandymcgee wrote:I agree with everything you said except this sentence. In my opinion, chances are if the language is getting in your way you're using the wrong language. That doesn't necessarily mean C++ is the wrong language, it just means that C++ is the wrong language for you, be it inexperience or otherwise.

I see where you're coming from. Obviously, that is purely my opinion from experience. In the past I've come up against conflicts between my design and the language of choice and tried to find other languages that would better support what I was trying to do, yet failed to find any. In those cases I ended up scrapping the design and starting fresh. It's entirely possible that I simply wasn't aware of the right language. I make an effort to be at least roughly acquainted with the general concept and syntax of every language I come across (when I stumble upon a language that I think might have some unique advantages I typically make a note to play with it during the weekend), but I make no claims of knowing every language.

Namelessone wrote:Reading on some other forums, people claim c++ should be avoided as a programming language, because it is inherently harder that others, that it makes a poor use of some programming paradigms and that you end up solving issues related to the language itself, rather than the problem you are trying to solve, just to quote a few examples.

Let me start by saying for the record: these people are retarded.

• The inherent difficulty of a language has nothing to do with its effectiveness. If this were the sole criterium for judging a language, we would all be writing code in some super high-level language like Javascript. C++ is a relatively low-level language, and as such, you have to take certain things into consideration that you don't have to with higher level languages (static typing, pointers, manual memory management). It is the nature of computing.
• And how does it make "poor use" of its programming paradigms? I will assume the people flinging this assault are high-level Javaphiles who bitch that C++ does not strictly enforce an object-oriented programming paradigm. That's true, it does not enforce this (at least not the extent of Java or C#). But I would consider that a strength of the language, rather than a shortcoming. OO is nothing more than a paradigm. One programming pattern that serves as a tool to help you get the job done. OO is not always necessarily the best solution. To maintain backwards compatibility with C, C++ still allows you to write procedural code.
• I'm sure they probably also bitch that C++ does not offer certain object-oriented features that Java or C# offer. There is a very good reason for this. These features come at a runtime price of either memory or processing. While this is usually fine in the desktop application world for JIT languages, C++ is meant to be fast. This means that there is no room for language features that introduce a significant amount of overhead.
• Give me an example of spending more time "fighting the language" than writing code. If this is the case, you chose C++ for the wrong job (or most likely, you just suck at it).

Like every language out there, C++ is not the correct solution to every problem (although compared to most languages, I would assert that it is usually at least a decent solution to almost every problem). It was created to fit a particular set of needs, which it does very well. C++ was written to be relatively low level and extremely fast. It is a logical bridge between completely structural low-level C and completely object-oriented C# and Java. It offers the speed and efficiency of C with the high-level programming constructs of Java and C#. It is a very ambitious language, and as such, it can be relatively complex to master.

They mostly repeated some of what is said in here
http://article.gmane.org/gmane.comp.ver ... .git/57918

and this here is something they used as an argument.

http://yosefk.com/c++fqa/class.html

I can't unfortunately, compare, because I have only used basic, C++ and a bit of java for college.

Namelessone wrote:and this here is something they used as an argument.

http://yosefk.com/c++fqa/class.html

That FQA was written by an ignorant C++-hater who clearly doesn't have a deep enough understanding of the language to make half of these claims.. I have a thing or two to say to him.

FQA wrote:How do I create objects? And what happens when they are no longer needed? Is it my job to figure out which ones are unused and deallocate them? Bad.

Calling having to manually manage your own memory "bad" without giving any further justification is pretty goddamn audacious. What does that have to do with anything? What does that have to do with his arguments against C++'s encapsulation? As someone who seems to have a boner for structural C, you would think the guy would appreciate not having the overhead of a garbage collector built into the language. I'm sorry you're lazy, but C++ is a statically compiled language targeted at being fast over being safe.

FQA wrote:What happens if I have bugs? If I have a pointer to an object, can it be invalid (be a random bit pattern, point to a dead object)? It can? The program will crash or worse? What about arrays of objects and out-of-bounds indexes? Crash or a modification of some other random object? You call that encapsulation? Bad.

What the fuck? Once again, how are these even valid criticisms? All of these work the same way in C and any other statically compiled language in existence that allows you to directly access memory. Referencing an object through a pointer or array has NOTHING to do with an object's encapsulation--that pointer and array access are outside of the object's scope. I don't think this author truly understands what "encapsulation" means, and I don't think he understands that C++ is a low-level language. You don't want your code to crash, because the language doesn't offer run-time safety? Stop writing shitty code. With great power comes great responsibility.

FQA wrote:When you need multiple instances and encapsulation in C, you use a forward declaration of a struct in the header file, and define it in the implementation file. That's actually better encapsulation than C++ classes - there's still no run-time encapsulation (memory can be accidentally/maliciously overwritten), but at least there's compile-time encapsulation (you don't have to recompile the code using the interface when you change the implementation).

Excuuuuuuuuse me? Since when did you have to recompile code using an interface when its implementation changes? The only time this is EVER the case is if that interface is inlined. The function is the exact same as it is in C, except it has an implicit "this" pointer. Once again, this guy doesn't know how C++ works.

FQA wrote:By default, struct members and base classes are public. With class, the default is private. Never rely on these defaults!

Never rely on these defaults? They are part of the C++ standard... Since when are we not able to rely on the standard?

FQA wrote:The fact that a crude C technique for approximating classes is better than the support for classes built into the C++ language is really shameful. Apparently so shameful that the FAQ had to distort the facts in an attempt to save face (or else the readers would wonder whether there's any point to C++ classes at all). The FQA hereby declares that it will not go down this path. Therefore, we have to mention this: the forward declaration basically makes it impossible for the calling code to reserve space for the object at compile time. This means that a struct declared in a header file or a C++ class can sometimes be allocated more efficiently than a forward-declared struct.

What. The. Fuck?

He says that a forwardly declared struct cannot be allocated due to the fact that the compiler has no information on its memory layout. Then in the very next sentence, he says that it can be allocated, although sometimes less efficiently than a struct declared in a header file... Not only is this complete bullshit, but you can never allocate a forwardly declared stuct. Once again, this guy has no idea what he's talking about.

FQA wrote:However, this is really about a different tradeoff - safety vs. efficiency, and there's no escape from this tradeoff. Either the caller knows about the details such as the size of an object at compile time - which breaks compile-time encapsulation - or it doesn't, so it can't handle the allocation.

Explain to me how this breaks compile-time encapsulation. The compiler is preventing you from accessing private member variables at compile-time. That is compile-time encapsulation. The author is truly bitching that he doesn't like how C++ implements compile-time encapsulation, not that it doesn't support compile-time encapsulation.

Namelessone wrote:They mostly repeated some of what is said in here
http://article.gmane.org/gmane.comp.ver ... .git/57918

As for Mr. Torvalds, I am not about to argue with a programming superstar who has a lifetime of achievement (even my arrogance knows its bounds), but I cannot help but think he is extremely baised due to his procedural C background.

C makes perfect sense for the OS work Mr. Torvalds has been doing for years and years, but are there thousands of accomplished C++ developers who have differing opinions on the language's efficacy.

As was stated before, every language has its pros and cons.

I would've had way more trouble if I started out with C/++ (I started with Java and C#), but now that I've started learning C/++ I've seen that there are some good things about these languages' low level capabilities as well as some frustrations.

If they don't want to use C++ that's fine, but they shouldn't condemn the language due to their own lack of understanding.

Namelessone wrote:They mostly repeated some of what is said in here
http://article.gmane.org/gmane.comp.ver ... .git/57918

Torvalds doesn't really expand upon his criticisms or go into detail as to why he believes the things he believes about C++. I respect him as a programmer, but I've learned to take his rants with a grain of salt. I would pay more attention to these particular assertions if he were to go beyond simply asserting and offer specific information to back his claims. Additionally, I find his exclusion of C++ programmers to be a bit childish. Harmless preference is hardly a valid reason to explicitly piss someone off. If they're not the project lead and they're pushing for a different language, then you can argue.

Namelessone wrote:and this here is something they used as an argument.
http://yosefk.com/c++fqa/class.html

The author of this article may have been dropped on his head as a child. I don't see how else he could so completely miss the whole purpose of an entire programming language. That's a special kind of stupid.

jmcintyretech wrote:I would've had way more trouble if I started out with C/++ (I started with Java and C#), but now that I've started learning C/++ I've seen that there are some good things about these languages' low level capabilities as well as some frustrations.

Don't get me wrong, I would never recommend C or C++ as your starting language. There is no way in hell I could have grasped either to begin with.

I will always recommend web development and scripting languages to ease you into programming in general. JIT languages like Java and C# are also way easier to start with than the lower-level statically compiled languages. Starting programming with C and C++ is a great way to lose all motivation.

Falco Girgis wrote:

FQA wrote:How do I create objects? And what happens when they are no longer needed? Is it my job to figure out which ones are unused and deallocate them? Bad.

Calling having to manually manage your own memory "bad" without giving any further justification is pretty goddamn audacious. What does that have to do with anything? What does that have to do with his arguments against C++'s encapsulation? As someone who seems to have a boner for structural C, you would think the guy would appreciate not having the overhead of a garbage collector built into the language. I'm sorry you're lazy, but C++ is a statically compiled language targeted at being fast over being safe.

What's the big deal with having to manage memory? I mean I'm kinda lazy and I find absolutely no problem or hassle with managing my memory properly. Being able to manage memory is a selling point in a language for me opposed to being a flaw like this guy is making it out to be.

Manual memory management is the sharp knife of programming. Some people are comfortable working at that level; others prefer safety. I like it when schools start students off with C because, even if they end up using C#/Java/etc. in their careers, they understand that nothing is magic. Strings, in particular, are the silent killers. When developers think that everything is magic, they make poor decisions that murder performance.

Light-Dark wrote:

Falco Girgis wrote:

FQA wrote:How do I create objects? And what happens when they are no longer needed? Is it my job to figure out which ones are unused and deallocate them? Bad.

Calling having to manually manage your own memory "bad" without giving any further justification is pretty goddamn audacious. What does that have to do with anything? What does that have to do with his arguments against C++'s encapsulation? As someone who seems to have a boner for structural C, you would think the guy would appreciate not having the overhead of a garbage collector built into the language. I'm sorry you're lazy, but C++ is a statically compiled language targeted at being fast over being safe.

What's the big deal with having to manage memory? I mean I'm kinda lazy and I find absolutely no problem or hassle with managing my memory properly. Being able to manage memory is a selling point in a language for me opposed to being a flaw like this guy is making it out to be.

I think the TheBuzzSaw really hit on it. It's the school of programmers who are only acquainted with high-level languages and constructs, who take memory management, strings, references, and other layers of abstraction for granted. They think it's all magical, because they have never had to be close enough to the hardware to have to worry about implementing this stuff.