Although the language itself isn't truly, truly bad, the only thing that made it tolerable was a library like Qt. STL and Boost are so shocking it isn't even funny, as well as the attitude amongst many that they are some kind of 'standard'. That's where C++ really did go off the rails.
Doesn't mean that it doesn't suck big time. TR1 sucked. The STL sucks. Templates suck. The original goal of c++ - c with classes - was good, but come on - this has gone way too far off track.
I think this is exactly backwards. I've been using C++ for 20 years, and in my experience, it's the inclusion of Simula-style classes which was the clear mistake in retrospect. Almost every well-written C++ program uses the class system as a module system, and limits inheritance to abstract base classes only.
The STL is one of the few things that makes C++ worth using. The template syntax sucks, but that's explainable by all the good syntax already being taken.
Well, you can read it and form your own opinion, too. I think it's a very well written article, and does point heaps of easily identifiable logical fallacies in the original rant.
Here's a thought - why don't YOU try to debunk part of it, by playing the devil's advocate.
I have no problem using C++. I have a HUGE problem with templates, TR1, and the STL. Ever run into a programmer who claims a decade of C++ experience, but if it's not in the STL or a class available online, they're lost? These are the same jokers who can't figure out when to use inheritance and when to use composition/aggregation. They're painful to work with.
Just one example to start with. The gets() argument is
Here's a thought - why don't YOU try to debunk part of it, by playing the devil's advocate.
Because I agree with it. To play devils advocate I'd have to engage in logical fallacies and sophistry for the sake of it. I have no desire to do that.
I have a HUGE problem with templates, TR1, and the STL
So you keep saying, but you've never said why.
but if it's not in the STL or a class available online, they're lost?
Programmers who don't really get programming and rel exclusively on libraries and stack overflow cod
I already debunked the gets() argument. Maybe I'll do the others. Maybe not. It's not a priority of mine. For what it's worth, c isn't perfect either. Far from it. I've always said Java sucks as well, but that doesn't stop me from using it. Perl is line noise, but I use it as well. There are parts of c++ I like. But there's a god-awful ton of stuff that's been larded onto it that should properly NOT be shoved into the standard.
So, your one debunking about C++ is an ancient C library function that was grandfathered in and is long deprecated even though it's not actually been removed. Funnily enough it's not part of the standard library generally referred to as the STL (i.e. the SGI derived stuff).
So basically you have yet again failed to provide any substance to your claims, instead resorting to misdirection.
So all I know is according to you the "STL sucks", but I have not the slightest clue why you think that. Your unwillingness
The article you quoted gave that as an example, so I debunked it. Not happy? That's not my problem. You set up a challenge under YOUR terms, I complied, and now YOU'RE all butt-hurt?
BTW:
Here's a thought - why don't YOU try to debunk part of it, by playing the devil's advocate.
Because I agree with it. To play devils advocate I'd have to engage in logical fallacies and sophistry for the sake of it. I have no desire to do that.
You refuse to engage in even the appearance of trying to find holes in your logic - they must love you at church, where you accept everything without question. But you'd fail any course in philosophy or critical thinking, or even debugging 101. And you'd get an F in science, since they all involve challenging your assumpt
The article you quoted gave that as an example, so I debunked it.
I've been trying to get you to elaborate on "STL sucks" with something more profound than your usual "lol stl si teh sux0rZ11!!11 trolololoollolol sux lolol!!!" line of argument.
So far in order to prove the STL sucks, you've picked on an ancient, long deprecated C library function grandfathered into C++ from it's C heritage and ignored the STL (i.e. SGI STL derived portions of the standard library) entirely.
As I said before, the reasons (excuses, really) to refuse to play devils advocate are bogus and indicate someone who is not capable of critical thinking. You're still a poseur.
So far in order to prove the STL sucks, you've picked on an ancient, long deprecated C library function grandfathered into C++ from it's C heritage and ignored the STL (i.e. SGI STL derived portions of the standard library) entirely.
No - the link YOU chose did that, - did you even read it????
You can't rebut my arguments and so your new tactic is to demand that I rebut my own because REASONS (i.e. ad-homenin attacks).
okeydokey. How about no. You see a debate is generally between at least two people, one person arguing one side and then the same person arguing the other side.
No - the link YOU chose did that, - did you even read it????
Your responses in this thread are so garbled and meandering that I literally have no idea what you are even talking about any more.
GCC is on the way out. Everyone sees the writing on the wall - except you, I guess.
Uh, well I don't know what the future of GCC has to do with what it's like now. You claimed that the commercial compilers are better: a fact which is objectively untrue by many measures. But yet again you twist and squirm and try to avoid having to support the point you made.
Honestly, I'd rather go back to writing in assembler than be stuck with the STL.
And you you haven't even given a single reason beyond "I don't like it" w
Search for c++ barf bag. Others have already gone into it at great length. However, it's obvious you've been trolling all this time if you finally admit the stl is flawed.
As I said before, I don't like it. It's fugly. If you like it, that's your business. I don't have to subscribe to your world view.Templates are ugly as well, but that's another issue. Template meta-programming was an accident. That it's been leveraged to what it is today, well, that's not my problem.
Let's reverse the question - what is so good about it that it should qualify as a part of the language standard?
The entire concept based design is extremely elegant. The idea of separating data and algorithms based purely on small sets of semantics of the data and datastructures is an extremely elegant idea and pretty revoloutionary when it was introduced.
The result it a standard library which is elegant to use partly because you can extend it with your own containers and yet it still interacts wit
In the end, it's your opinion. If you think that someone who can't write their own resizable vector, map, or set should be allowed in the playpen, you're entitled to it. However, I agree with Linus on this one. C provides a barrier to entry, as does C++ without templates or the stl. I've seen programmers who can't write a simple string or bchunk class, or a linked list on their own. They're just one step above "google cut-n-paste" coders.
That's just my opinion, but let's face it, if you can't write them y
It is, but you've yet to provide a reason for your own. The reasons you provide below are essentially against any lanuage ever from having any kind of standard library. That applies equally well across the board.
If you think that someone who can't write their own resizable vector, map, or set should be allowed in the playpen, you're entitled to it.
Well, you can make up opinions that you believe I have if it suits you. It doesn't make you correct however. I never claimed that a
I have no problem with a language having a minimalist standard library. The current c++ goes well beyond that. There's no need for more - people can share their own creations that do the necessary jobs and only the necessary ones, without creating a huge tangled web of dependencies that make debugging harder.
That was the original vision. It's been perverted. We've seen this pushed to the extreme with Java. I have no problem with it being an option, chosen by the end user, same as Boost was; but to push it
I have no problem with a language having a minimalist standard library
Alright then, where do you draw the line?
Can you comment on my remark about the effective complexity of having eac hprogrammer with their own library?
I have no problem with it being an option, chosen by the end user,
It pretty much is in C++: it sticks to the "don't pay for what you don't use" principle. Using std::vector won't introduce iostreams. Using std::map won't bring in std::sort.
how much do you want to bet that the average STL us
I did form my own opinion, this rant from Linus is fairly old and I discussed it many times with colleagues and friends. When I discuss it with friends, opinions varies alot about STL, some are pro-STL and some others are anti-STL. Some mention boost and how C++11 improves or not things,... etc.
I agree with you that the article has many valid points, I just want to see a reply to this article.
I just do not want to join this flamefest. If I knew you, I would not mind discussing it but just read the comments here: I do not want to be flamed.
The short version of my opinion is that C++ has a lot of libraries and I see many people who do not understand how the STL is implemented or even read any kind of documentation. Because in some places you can get by, if you are not curious by nature you might end up writing poor code. Also, in some places, for some reason people use C++ even though they should
Befor you correct me: this can happen in any language but for some reason it seems that C++ was the first language of many sub par programmers and I see bad and costly to maintain C++ code at work than in any other language.
I just do not want to join this flamefest. If I knew you, I would not mind discussing it but just read the comments here: I do not want to be flamed.
I do try to avoid flaming people who are reasonable but I disagree with. It's just the "lol C++ sux" people that annoy me because they post nothing but emotional fluff culled from internet rants.
For some reason, newcomers to C++ are prone to over engineering and complex classes hierarchy with multiple inheritance.
Although the language itself isn't truly, truly bad,
Any language that allows the programmer to override the '=' operator is truly, verily, bad. That makes the language over-programmable and a write-only language when trying to maintain other developer's code. Java may have fewer features, but that doesn't stop the developers from getting stuff done.
Although the language itself isn't truly, truly bad,
Any language that allows the programmer to override the '=' operator is truly, verily, bad. That makes the language over-programmable and a write-only language when trying to maintain other developer's code. Java may have fewer features, but that doesn't stop the developers from getting stuff done.
Why is overriding '=' bad? If I've defined a class for a thing for which equality means something other than the usual, e.g. a mod 11 class where 'a = 13' should result in 'a==2', I would want to override '=' to do the right thing.
It's bad because someone can think of a niche case where it can be abused. In my experience, it never happens. You tend to find that those smart enough to know how to overload say the = operator are also smart enough to only do it for a good reason.
I've seen bad developers utterly abuse just about every language out there, if there's a language feature then it can be abused. C++ just happens to have a lot of features.
It's bad because someone can think of a niche case where it can be abused. In my experience, it never happens. You tend to find that those smart enough to know how to overload say the = operator are also smart enough to only do it for a good reason.
I've seen bad developers utterly abuse just about every language out there, if there's a language feature then it can be abused. C++ just happens to have a lot of features.
Fair enough. In return for not being able to overload '=', please can I have the ability to define infix operators? So I can have 13 is_congruent_to 2 == True.
Why is it so bad to just define something that describes what you are actually doing instead of hiding important details in overloaded operators?
When someone else defines a class for which equality means something other than the usual and your like... WTF 2 == 13... who wins? What is the upside other than less typing for those still using vi to write code?
Because typing mod11_assign(&a,13) sucks compared to a = 13.
If you're doing finite field arithmetic, the rules are the rules and having a programming language that is too stupid to anything beyond elementary school arithmetic is counterproductive.
Any language that allows the programmer to override the '=' operator is truly, verily, bad.
This is, to my mind, the most fundamental problem with C++: it is impossible to look at a page of code in isolation and know what it does, with confidence. Any of the operators could have been redefined to do anything. This is not a theoretical problem, I encountered a code base of horrors that a nerd who though he was God's gift to nerd-dom dreamed up, which had numerous standard operators reassigned to make the code he wrote "look elegant". It was impossible to analyze or maintain.
When the meaning of a simple programming construct is indeterminate, the language that supports it has failed disastrously.
The ability to overload operators makes it possible to write human-readable code. A class of matrix math, or non-standard length floats, results in code with a few operator symbols instead of a mass of function calls or macros.
There are advantages to using C++ wisely. If comments don't make it clear what's happening, it hasn't been used wisely.
You can abuse the C pre-processor as well. The early versions of the Bourne Shell are, essentially, written in Bourne Shell through the use of a mess of C macros. When I was working at a Unix vendor I was assigned to track down a bug in the shell and that was just...wrong. Some time around Sys V somebody un-macro'ized the code.
On the other hand in a language like C or java any code that needs to work with a custom numeric type (complex numbers, integers modulo something other than a power of 2, integers larger than the compiler supports, matricies etc) becomes a horrible mess of function calls (or macros in the case of C) that obscure the maths you are trying to write/read.
Given a page of C code that calls functions not on the page, the meaning is indeterminate.
Stroustrup explicitly decided not to leave stuff out just because it was abusable. If there was a good reason for a feature to be in (and he was pretty strict on that), he wouldn't reject it because somebody would do something stupid and confusing with it. You may disagree with that, but there are advantages, in that it's possible to have non-buiilt-in arithmetic types (like matrices or vectors or complex numbers)
Big, big difference between explicit function references (known to have definitions elsewhere) and redefining the meaning of arithmetic primitives.
Stroustrup explicitly decided not to leave stuff out just because it was abusable. If there was a good reason for a feature to be in (and he was pretty strict on that), he wouldn't reject it because somebody would do something stupid and confusing with it.
And C++ stands as a monument to what you get when you follow that philosophy.
Notice that other languages since have tended to focus on a tighter coherent set of core features.
Operator overloading is just a special case of polymorphism. By your reasoning, it is impossible to look at a page of code written in any OO language in isolation and know what it does, with confidence.
Java may have fewer features, but that doesn't stop the developers from getting stuff done.
This is a stupid argument. You could just as easily say, "Assembly language may have fewer features, but that doesn't stop the developers from getting stuff done."
In C++ (and C), '=' is the assignment operator. Is it your opinion that assignment from one class instance to another should be specified by the language? What do you do when an object has a pointer to allocated memory? Copy the memory? Only copy the ponter? What should the language define? Or should it be impossible to use '=' to assign a value to a user-defined type, so you can use an ugly and unintuitive function instead?
Java solved it correctly -- just copy the pointer, instead of overloading the '=' operator. When you you see a simple statement like shown below in C++, a = b;
you may be unaware that an assignment operator overloaded function may be lurking in there and the side effects that are caused by it. It would be worse if b were part of a function/method's arguments. It's just poor design -- add hacks to solve a problem and end up creating more problems.
Java solved it for some cases, and if you're dealing with pointers in C++ you can do the same copy.
I am very aware that an assignment may be an overloaded assignment operator, since I write those things frequently. What I don't see is what the problem is, provided the program is written reasonably well. The assignment operator will do the right thing (whatever that might be), as efficiently as you'd expect, with no surprising side effects.
In order to keep this going effectively, you do need a culture
QT is awful. Any helper library that also needs its own preprocessor has definately lost the plot somewhere. QT also enocurages bad programmers to use endless amounts of signals and slots that break encapsluation and obscure program flow, where a normal function or method call would have been used before. Good luck trying to figure out program flow with heavy use of those abominations.
You're completely off base. Code generation is a vital productivity tool. Properly applied, it lets you produce code quicker and with less defects. If you're developing a large scale project and are not using various code generators to ease your job in repetitive tasks, you're doing it wrong. Qt's use of moc is exactly what code generators are supposed to be used for. I lament that they haven't taken it far enough, in fact.
>> You're completely off base. No you are. neenner.
>> Code generation is a vital productivity tool. except maybe for generating event handler stubs for GUI code, or throwaway protoype apps, I strongly disagree.
Auto-generated code is often unmaintainable and supporting it long term is way more of a time-consuming pain in the ass than it saves. Generally, if you need a program to write code for you, chances are you have other problems.
I'm sorry, you're really doing it wrong, and I'm not trying to pull a "no true scotsman" on you. moc output code doesn't have to be readable, even though it's not an outright mess. For other code that you'd be writing generators for, it's on you to make it readable, and with the right approach it can work wonderfully. The 0mq folks use their own tool, gsl, and even though their own use of code generation inside of gsl is an abominable mess, you can actually use gsl to generate some very nice, readable code.
Out of interest, what do you use? Something stricter like Ada?
Don't get me wrong, I like C++ a lot, especially for scientific computation. It allows me to tackle much larger projects single handed than any other language would. But I can see why avionics people might want to steer clear.
We use C or C++ with provisos depending on what Design Assurance Level (A-E) the product is, (See FAA standard DO178B that covers software development for avionics). We have to comply with our processes based on DO178B so depending on the DAL of the project we may or may not be able to use mechanisms that lead to unpredictable code paths such as exceptions, recursion, inheritance etc. IMHO the actual effect of that is to make the risk of potential problems worse.
About 80% of my work is embedded. You still writing out those state machines by hand? Tsk tsk tsk. I can't even begin to imagine being productive in embedded work without lots of code-generating tools. With a proper high-level language used to define communications protocols, for example, I can do in a day what would probably take me two weeks after all bugs are out. I have many such examples. I only use code generation because it works. And the code it produces can be as pretty, readable and comprehensible
i'm sorry, but most compilers use another language as an intermediate representation. gcc uses several of these, including a couple of abstract trees and platform-specific assembly. c-front used C, as did ghc. moc uses code as an intermediate representation. it's common practice in the industry. get. over. it.
No you get. over. it, Your statement is clueless. The compiler is not doing anything creative or original at all so it is definately not WRITING code. It is simply compiling it which most usually includes intermidiate steps such as conversion to lexemes, then to trigraphs, then to assembly, then optimized assembly, then target-specific binary. Each step is simply converting the output of the previuos step to another logically equivalent form. There is no create input so It is not writing (i.e. creating) anyt
moc generates C++ code. gcc generates.as code. they both generate code, and they both use that code as an intermediate form. mov "converts the output output of the previous step to another logically equivalent form". as does gcc. with moc, you use a tool (gcc) to include the intermediate form in your final output. with gcc, you use a tool (as/ld) to include the intermediate form in your final output.
I don't know why you want to modify strings in-place. Seems like you are complaining that it is not C-like. It would be much better if values were returned, for instance your "mystring.replace("from","to")" would not change mystring, but instead return a new string with the replacement done.
One of the biggest mistakes in std::string is that operator[] returns a non-const reference. This is so all those people raised on Visual Basic could capitalize by doing a[0]=toupper(a[0]). It also means that efficient c
auto copy = string{mystring}.replace("from", "to"); and move semantics avoids the extra copy.
The string constructor does an unnecessary copy. You are correct that move semantics avoids yet another copy from the result to "copy". I have not found any way to do this except by having two different functions, one which does an in-place modification and another that returns a newly constructed string. This produces questions about how to name them, as only one of them gets the "good" name.
Thanks for your comments about UTF-16 and Windows. You are correct that wrapper functions are about the only solution on Windows. Microsoft refuses to make the multibyte api accept UTF-8.
"Bond reflected that good Americans were fine people and that most of them
seemed to come from Texas."
- Ian Fleming, "Casino Royale"
Ahhhh, C++ (Score:3, Insightful)
Re: (Score:3)
Doesn't mean that it doesn't suck big time. TR1 sucked. The STL sucks. Templates suck. The original goal of c++ - c with classes - was good, but come on - this has gone way too far off track.
Re: (Score:2)
I think this is exactly backwards. I've been using C++ for 20 years, and in my experience, it's the inclusion of Simula-style classes which was the clear mistake in retrospect. Almost every well-written C++ program uses the class system as a module system, and limits inheritance to abstract base classes only.
The STL is one of the few things that makes C++ worth using. The template syntax sucks, but that's explainable by all the good syntax already being taken.
Re: (Score:2)
The STL sucks.
You've been doing this a lot recently: just making bald statements with nothing to back them up. So go on, share: why does the STL suck.
(a clue: it doesn't).
Re: (Score:2)
Re: (Score:2)
Well, I'm beginning to suspect you're simply a troll. You make bald, contraversial statements with nothing but very glib comments to back them up.
Linus's comments on C++ have been thoroughly debunked:
http://warp.povusers.org/OpenL... [povusers.org]
Do you actually have an opinion of your own that you can back up with any sort of reasoned argument?
Re: (Score:1)
Although I use C++ myself, I would like to see someone reply to the debunk link you posted.
Only when there has been a thorough exchange going both ways, we can affirmed that each of his point has been debunked properly
Re: (Score:2)
Well, you can read it and form your own opinion, too. I think it's a very well written article, and does point heaps of easily identifiable logical fallacies in the original rant.
Re: (Score:2)
Here's a thought - why don't YOU try to debunk part of it, by playing the devil's advocate.
I have no problem using C++. I have a HUGE problem with templates, TR1, and the STL. Ever run into a programmer who claims a decade of C++ experience, but if it's not in the STL or a class available online, they're lost? These are the same jokers who can't figure out when to use inheritance and when to use composition/aggregation. They're painful to work with.
Just one example to start with. The gets() argument is
Re: (Score:2)
Here's a thought - why don't YOU try to debunk part of it, by playing the devil's advocate.
Because I agree with it. To play devils advocate I'd have to engage in logical fallacies and sophistry for the sake of it. I have no desire to do that.
I have a HUGE problem with templates, TR1, and the STL
So you keep saying, but you've never said why.
but if it's not in the STL or a class available online, they're lost?
Programmers who don't really get programming and rel exclusively on libraries and stack overflow cod
Re: (Score:2)
Re: (Score:2)
So, your one debunking about C++ is an ancient C library function that was grandfathered in and is long deprecated even though it's not actually been removed. Funnily enough it's not part of the standard library generally referred to as the STL (i.e. the SGI derived stuff).
So basically you have yet again failed to provide any substance to your claims, instead resorting to misdirection.
So all I know is according to you the "STL sucks", but I have not the slightest clue why you think that. Your unwillingness
Re: (Score:2)
BTW:
Here's a thought - why don't YOU try to debunk part of it, by playing the devil's advocate.
Because I agree with it. To play devils advocate I'd have to engage in logical fallacies and sophistry for the sake of it. I have no desire to do that.
You refuse to engage in even the appearance of trying to find holes in your logic - they must love you at church, where you accept everything without question. But you'd fail any course in philosophy or critical thinking, or even debugging 101. And you'd get an F in science, since they all involve challenging your assumpt
Re: (Score:2)
The article you quoted gave that as an example, so I debunked it.
I've been trying to get you to elaborate on "STL sucks" with something more profound than your usual "lol stl si teh sux0rZ11!!11 trolololoollolol sux lolol!!!" line of argument.
So far in order to prove the STL sucks, you've picked on an ancient, long deprecated C library function grandfathered into C++ from it's C heritage and ignored the STL (i.e. SGI STL derived portions of the standard library) entirely.
So far all you've debunked is the id
Re: (Score:2)
So far in order to prove the STL sucks, you've picked on an ancient, long deprecated C library function grandfathered into C++ from it's C heritage and ignored the STL (i.e. SGI STL derived portions of the standard library) entirely.
No - the link YOU chose did that, - did you even read it????
Re: (Score:2)
This is hilarious:
You can't rebut my arguments and so your new tactic is to demand that I rebut my own because REASONS (i.e. ad-homenin attacks).
okeydokey. How about no. You see a debate is generally between at least two people, one person arguing one side and then the same person arguing the other side.
No - the link YOU chose did that, - did you even read it????
Your responses in this thread are so garbled and meandering that I literally have no idea what you are even talking about any more.
I also see that
Re: (Score:2)
GCC is on the way out. Everyone sees the writing on the wall - except you, I guess.
Also, don't blame me for your choice of articles to rebut. If you like the STL, then use it. I don't. I won't. Problem solved.
Honestly, I'd rather go back to writing in assembler than be stuck with the STL.
Re: (Score:2)
GCC is on the way out. Everyone sees the writing on the wall - except you, I guess.
Uh, well I don't know what the future of GCC has to do with what it's like now. You claimed that the commercial compilers are better: a fact which is objectively untrue by many measures. But yet again you twist and squirm and try to avoid having to support the point you made.
Honestly, I'd rather go back to writing in assembler than be stuck with the STL.
And you you haven't even given a single reason beyond "I don't like it" w
Re: (Score:2)
As I said before, I don't like it. It's fugly. If you like it, that's your business. I don't have to subscribe to your world view.Templates are ugly as well, but that's another issue. Template meta-programming was an accident. That it's been leveraged to what it is today, well, that's not my problem.
Re: (Score:2)
Search for c++ barf bag.
I did, nothing obvious came up.
However, it's obvious you've been trolling all this time if you finally admit the stl is flawed.
Only in your weird little world. It's not perfect but it's not fatally flawed in any way. IOW good, but not perfect.
As I said before, I don't like it.
Yes and that's all you've said.
It's fugly.
Well, that's a rational, well thought out argument.
Re: (Score:2)
Re: (Score:2)
Code can be beautiful. It contributes to its maintainability. You will never hear that accusation made against the STL.
The STL is well designed: code using the STL is much more maintainable tha nthe alternatives. There you go, I made precisely that accusation.
Now put up or shut up. What *precisely* is bad about it.
Re: (Score:2)
Re: (Score:2)
OK, fine.
Let's reverse the question - what is so good about it that it should qualify as a part of the language standard?
The entire concept based design is extremely elegant. The idea of separating data and algorithms based purely on small sets of semantics of the data and datastructures is an extremely elegant idea and pretty revoloutionary when it was introduced.
The result it a standard library which is elegant to use partly because you can extend it with your own containers and yet it still interacts wit
Re: (Score:2)
In the end, it's your opinion. If you think that someone who can't write their own resizable vector, map, or set should be allowed in the playpen, you're entitled to it. However, I agree with Linus on this one. C provides a barrier to entry, as does C++ without templates or the stl. I've seen programmers who can't write a simple string or bchunk class, or a linked list on their own. They're just one step above "google cut-n-paste" coders.
That's just my opinion, but let's face it, if you can't write them y
Re: (Score:2)
In the end, it's your opinion.
It is, but you've yet to provide a reason for your own. The reasons you provide below are essentially against any lanuage ever from having any kind of standard library. That applies equally well across the board.
If you think that someone who can't write their own resizable vector, map, or set should be allowed in the playpen, you're entitled to it.
Well, you can make up opinions that you believe I have if it suits you. It doesn't make you correct however. I never claimed that a
Re: (Score:2)
I have no problem with a language having a minimalist standard library. The current c++ goes well beyond that. There's no need for more - people can share their own creations that do the necessary jobs and only the necessary ones, without creating a huge tangled web of dependencies that make debugging harder.
That was the original vision. It's been perverted. We've seen this pushed to the extreme with Java. I have no problem with it being an option, chosen by the end user, same as Boost was; but to push it
Re: (Score:2)
I have no problem with a language having a minimalist standard library
Alright then, where do you draw the line?
Can you comment on my remark about the effective complexity of having eac hprogrammer with their own library?
I have no problem with it being an option, chosen by the end user,
It pretty much is in C++: it sticks to the "don't pay for what you don't use" principle. Using std::vector won't introduce iostreams. Using std::map won't bring in std::sort.
how much do you want to bet that the average STL us
Re: (Score:1)
I did form my own opinion, this rant from Linus is fairly old and I discussed it many times with colleagues and friends. When I discuss it with friends, opinions varies alot about STL, some are pro-STL and some others are anti-STL. Some mention boost and how C++11 improves or not things, ... etc.
I agree with you that the article has many valid points, I just want to see a reply to this article.
Re: (Score:2)
I did form my own opinion,
Care to share? Seriously, what is your opinion?
Re: Ahhhh, C++ (Score:1)
I just do not want to join this flamefest. If I knew you, I would not mind discussing it but just read the comments here: I do not want to be flamed.
The short version of my opinion is that C++ has a lot of libraries and I see many people who do not understand how the STL is implemented or even read any kind of documentation. Because in some places you can get by, if you are not curious by nature you might end up writing poor code. Also, in some places, for some reason people use C++ even though they should
Re: Ahhhh, C++ (Score:1)
Re: (Score:2)
I just do not want to join this flamefest. If I knew you, I would not mind discussing it but just read the comments here: I do not want to be flamed.
I do try to avoid flaming people who are reasonable but I disagree with. It's just the "lol C++ sux" people that annoy me because they post nothing but emotional fluff culled from internet rants.
For some reason, newcomers to C++ are prone to over engineering and complex classes hierarchy with multiple inheritance.
There are some languages which seem to trigger t
Re:Ahhhh, C++ (Score:5, Insightful)
Any language that allows the programmer to override the '=' operator is truly, verily, bad. That makes the language over-programmable and a write-only language when trying to maintain other developer's code. Java may have fewer features, but that doesn't stop the developers from getting stuff done.
Re: (Score:2)
Any language that allows the programmer to override the '=' operator is truly, verily, bad. That makes the language over-programmable and a write-only language when trying to maintain other developer's code. Java may have fewer features, but that doesn't stop the developers from getting stuff done.
Why is overriding '=' bad? If I've defined a class for a thing for which equality means something other than the usual, e.g. a mod 11 class where 'a = 13' should result in 'a==2', I would want to override '=' to do the right thing.
Re: (Score:2)
It's bad because someone can think of a niche case where it can be abused. In my experience, it never happens. You tend to find that those smart enough to know how to overload say the = operator are also smart enough to only do it for a good reason.
I've seen bad developers utterly abuse just about every language out there, if there's a language feature then it can be abused. C++ just happens to have a lot of features.
Re: (Score:2)
It's bad because someone can think of a niche case where it can be abused. In my experience, it never happens. You tend to find that those smart enough to know how to overload say the = operator are also smart enough to only do it for a good reason.
I've seen bad developers utterly abuse just about every language out there, if there's a language feature then it can be abused. C++ just happens to have a lot of features.
Fair enough. In return for not being able to overload '=', please can I have the ability to define infix operators? So I can have 13 is_congruent_to 2 == True.
Re: (Score:2)
Why is it so bad to just define something that describes what you are actually doing instead of hiding important details in overloaded operators?
When someone else defines a class for which equality means something other than the usual and your like ... WTF 2 == 13 ... who wins? What is the upside other than less typing for those still using vi to write code?
Because typing mod11_assign(&a,13) sucks compared to a = 13.
If you're doing finite field arithmetic, the rules are the rules and having a programming language that is too stupid to anything beyond elementary school arithmetic is counterproductive.
Re:Ahhhh, C++ (Score:4, Interesting)
Any language that allows the programmer to override the '=' operator is truly, verily, bad.
This is, to my mind, the most fundamental problem with C++: it is impossible to look at a page of code in isolation and know what it does, with confidence. Any of the operators could have been redefined to do anything. This is not a theoretical problem, I encountered a code base of horrors that a nerd who though he was God's gift to nerd-dom dreamed up, which had numerous standard operators reassigned to make the code he wrote "look elegant". It was impossible to analyze or maintain.
When the meaning of a simple programming construct is indeterminate, the language that supports it has failed disastrously.
Re: (Score:2)
The ability to overload operators makes it possible to write human-readable code. A class of matrix math, or non-standard length floats, results in code with a few operator symbols instead of a mass of function calls or macros.
There are advantages to using C++ wisely. If comments don't make it clear what's happening, it hasn't been used wisely.
Re: (Score:2)
You can abuse the C pre-processor as well. The early versions of the Bourne Shell are, essentially, written in Bourne Shell through the use of a mess of C macros. When I was working at a Unix vendor I was assigned to track down a bug in the shell and that was just...wrong. Some time around Sys V somebody un-macro'ized the code.
Re: (Score:2)
Oh what utter bullshit.
Because in any other language you magically know what the do_stuff() function that's referred to but not defined on that page is.
In C++ = means operator=(). + means operator+(). etc etc.
If you don't understand that then you simply don't understand C++.
Re: (Score:2)
On the other hand in a language like C or java any code that needs to work with a custom numeric type (complex numbers, integers modulo something other than a power of 2, integers larger than the compiler supports, matricies etc) becomes a horrible mess of function calls (or macros in the case of C) that obscure the maths you are trying to write/read.
Re: (Score:2)
Given a page of C code that calls functions not on the page, the meaning is indeterminate.
Stroustrup explicitly decided not to leave stuff out just because it was abusable. If there was a good reason for a feature to be in (and he was pretty strict on that), he wouldn't reject it because somebody would do something stupid and confusing with it. You may disagree with that, but there are advantages, in that it's possible to have non-buiilt-in arithmetic types (like matrices or vectors or complex numbers)
Re: (Score:2)
Big, big difference between explicit function references (known to have definitions elsewhere) and redefining the meaning of arithmetic primitives.
Stroustrup explicitly decided not to leave stuff out just because it was abusable. If there was a good reason for a feature to be in (and he was pretty strict on that), he wouldn't reject it because somebody would do something stupid and confusing with it.
And C++ stands as a monument to what you get when you follow that philosophy.
Notice that other languages since have tended to focus on a tighter coherent set of core features.
Re: (Score:1)
Worse, to understand any of a C++ program, you need to understand all of it, due to the tentacles of inheritance ...
Re: (Score:2)
Operator overloading is just a special case of polymorphism. By your reasoning, it is impossible to look at a page of code written in any OO language in isolation and know what it does, with confidence.
Re: (Score:3)
Java may have fewer features, but that doesn't stop the developers from getting stuff done.
This is a stupid argument. You could just as easily say, "Assembly language may have fewer features, but that doesn't stop the developers from getting stuff done."
Re: (Score:2)
In C++ (and C), '=' is the assignment operator. Is it your opinion that assignment from one class instance to another should be specified by the language? What do you do when an object has a pointer to allocated memory? Copy the memory? Only copy the ponter? What should the language define? Or should it be impossible to use '=' to assign a value to a user-defined type, so you can use an ugly and unintuitive function instead?
Re: (Score:2)
Java solved it correctly -- just copy the pointer, instead of overloading the '=' operator. When you you see a simple statement like shown below in C++,
a = b;
you may be unaware that an assignment operator overloaded function may be lurking in there and the side effects that are caused by it. It would be worse if b were part of a function/method's arguments. It's just poor design -- add hacks to solve a problem and end up creating more problems.
Re: (Score:2)
Java solved it for some cases, and if you're dealing with pointers in C++ you can do the same copy.
I am very aware that an assignment may be an overloaded assignment operator, since I write those things frequently. What I don't see is what the problem is, provided the program is written reasonably well. The assignment operator will do the right thing (whatever that might be), as efficiently as you'd expect, with no surprising side effects.
In order to keep this going effectively, you do need a culture
Re: (Score:2)
QT is awful. Any helper library that also needs its own preprocessor has definately lost the plot somewhere.
QT also enocurages bad programmers to use endless amounts of signals and slots that break encapsluation and obscure program flow, where a normal function or method call would have been used before. Good luck trying to figure out program flow with heavy use of those abominations.
Re: (Score:2)
You're completely off base. Code generation is a vital productivity tool. Properly applied, it lets you produce code quicker and with less defects. If you're developing a large scale project and are not using various code generators to ease your job in repetitive tasks, you're doing it wrong. Qt's use of moc is exactly what code generators are supposed to be used for. I lament that they haven't taken it far enough, in fact.
Re: (Score:2)
>> You're completely off base.
No you are. neenner.
>> Code generation is a vital productivity tool.
except maybe for generating event handler stubs for GUI code, or throwaway protoype apps, I strongly disagree.
Auto-generated code is often unmaintainable and supporting it long term is way more of a time-consuming pain in the ass than it saves. Generally, if you need a program to write code for you, chances are you have other problems.
Re: (Score:2)
I'm sorry, you're really doing it wrong, and I'm not trying to pull a "no true scotsman" on you. moc output code doesn't have to be readable, even though it's not an outright mess. For other code that you'd be writing generators for, it's on you to make it readable, and with the right approach it can work wonderfully. The 0mq folks use their own tool, gsl, and even though their own use of code generation inside of gsl is an abominable mess, you can actually use gsl to generate some very nice, readable code.
Re: (Score:2)
Yeah I take it you're a web developer or something similar where most code is considered throwaway or "here today gone tomorrow".
Auto code generation of any kind just doesn't fly (literally) in my field (embedded, avionics).
Re: (Score:2)
Out of interest, what do you use? Something stricter like Ada?
Don't get me wrong, I like C++ a lot, especially for scientific computation. It allows me to tackle much larger projects single handed than any other language would. But I can see why avionics people might want to steer clear.
Re: (Score:2)
We use C or C++ with provisos depending on what Design Assurance Level (A-E) the product is, (See FAA standard DO178B that covers software development for avionics). We have to comply with our processes based on DO178B so depending on the DAL of the project we may or may not be able to use mechanisms that lead to unpredictable code paths such as exceptions, recursion, inheritance etc. IMHO the actual effect of that is to make the risk of potential problems worse.
Re: (Score:2)
About 80% of my work is embedded. You still writing out those state machines by hand? Tsk tsk tsk. I can't even begin to imagine being productive in embedded work without lots of code-generating tools. With a proper high-level language used to define communications protocols, for example, I can do in a day what would probably take me two weeks after all bugs are out. I have many such examples. I only use code generation because it works. And the code it produces can be as pretty, readable and comprehensible
Re: (Score:2)
yay, the "i haven't yet worked out how to use it effectively in my job, so it must be useless for everyone" fallacy.
thanks for helping me with my flame-war fallacy bingo card.
Re: (Score:2)
> Generally, if you need a program to write code for you, chances are you have other problems
My compiler writes assembly code for me. Is that a problem?
Re: (Score:2)
No it doesn't write code. It compiles the code you wrote. Thats why its called a compiler.
Re: (Score:2)
i'm sorry, but most compilers use another language as an intermediate representation. gcc uses several of these, including a couple of abstract trees and platform-specific assembly. c-front used C, as did ghc. moc uses code as an intermediate representation. it's common practice in the industry.
get. over. it.
Re: (Score:2)
No you get. over. it, Your statement is clueless.
The compiler is not doing anything creative or original at all so it is definately not WRITING code. It is simply compiling it which most usually includes intermidiate steps such as conversion to lexemes, then to trigraphs, then to assembly, then optimized assembly, then target-specific binary.
Each step is simply converting the output of the previuos step to another logically equivalent form. There is no create input so It is not writing (i.e. creating) anyt
Re: (Score:2)
> Each step is simply converting the output of the previuos step to another logically equivalent form.
and moc is doing what different, exactly?
Re: (Score:2)
Generating source code.
Re: (Score:2)
dude, you're a fucking moron.
moc generates C++ code. gcc generates .as code. they both generate code, and they both use that code as an intermediate form.
mov "converts the output output of the previous step to another logically equivalent form". as does gcc.
with moc, you use a tool (gcc) to include the intermediate form in your final output. with gcc, you use a tool (as/ld) to include the intermediate form in your final output.
Re: (Score:2)
>> dude, you're a fucking moron.
"Dude" go fuck yourself.
Re: (Score:2)
Nice argument, troll.
Re: (Score:2)
Re: (Score:2)
I don't know why you want to modify strings in-place. Seems like you are complaining that it is not C-like. It would be much better if values were returned, for instance your "mystring.replace("from","to")" would not change mystring, but instead return a new string with the replacement done.
One of the biggest mistakes in std::string is that operator[] returns a non-const reference. This is so all those people raised on Visual Basic could capitalize by doing a[0]=toupper(a[0]). It also means that efficient c
Re: (Score:2)
Re: (Score:2)
auto copy = string{mystring}.replace("from", "to"); and move semantics avoids the extra copy.
The string constructor does an unnecessary copy. You are correct that move semantics avoids yet another copy from the result to "copy". I have not found any way to do this except by having two different functions, one which does an in-place modification and another that returns a newly constructed string. This produces questions about how to name them, as only one of them gets the "good" name.
I have seen attempts to
Re: (Score:2)
Thanks for your comments about UTF-16 and Windows. You are correct that wrapper functions are about the only solution on Windows. Microsoft refuses to make the multibyte api accept UTF-8.