Hacker Newsnew | past | comments | ask | show | jobs | submit | jamesaguilar's commentslogin

There are a lot of objections to C++, but I've never seen any of the five he mentions. They sound more like strawmen to knock down than real objections by actual users or commentators critical of the language.


Objections from the article.

1. “To understand C++, you must first learn C”

2. “C++ is an Object-Oriented Language”

3. “For reliable software, you need Garbage Collection”

4. “For efficiency, you must write low-level code”

5. “C++ is for large, complicated, programs only”

1. Not a myth. To write your own C++ code, no. To do anything with C++ other people wrote... Yes, you must first learn C.

2. Weird one, I don't remember hearing this one ever. But it'd be a myth on many levels. C++ has some object-oriented features, but it's indeed not an object-oriented language in the original sense of the concept from Smalltalk. But if you see the effort, it can be used as one. It can also be used as a procedural language. Or even as a functional one to some extent.

3. Real myth detected! GC doesn't affect reliability. Manual memory management reduces reliability. In C++, you can do manual or RIAA-type memory management.

4. This one is not a myth. To get best possible efficiency, you do need to use assembler or compiler intrinsics. The difference you can gain is up to 40x (in my personal experience, this case was about vectorization and branch elimination), typically 2-3x, so it's not insignificant either.

5. Myth. You can use C++ for any size complicated program. You can write simple C++ programs, but the language tries very hard to make sure you can't understand a piece of code out of context. You can't even know what your arithmetic operators do without knowing the includes and other context.


> the language tries very hard to make sure you can't understand a piece of code out of context

The language goes out of its way to make it possible to write code that is understandable with as little context as possible; type deduction, lambdas, range-based for loops— all of these are tools for reducing the amount of context or number of contexts necessary to understand a portion of code.

The language also allows you to write code that requires an inordinate amount of context to understand, yes. So does C. Hell, so does every other programming language worth using. It's practically impossible to prevent such code from being written without totally crippling the language.

> You can't even know what your arithmetic operators do without knowing the includes and other context.

If you can see that the arguments to your arithmetic operators are numeric (and you should be able to tell without looking outside of function scope), you need no more context. If the arguments are of user-defined types, you need no more context than if a function named "plus" had been used instead of the function named "operator+." If that is not enough context to understand the code, you have a problem with someone choosing poor names for functions, which goes far beyond operator overloading. For example, sure, operator overloading allows for code like

    auto operator+ (string_t a, string_t b) {
        return a.length () - b.length ();
    }
but so what? User-defined functions allow for code like

    void uppercaseify (char* str) {
        unlink (str);
    }
but it would be patently absurd to blame the language for code like that.


I guess you don't maintain [legacy] C++ code. Occasionally I have to.


I have maintained C++ code that was poorly written, if that's what you're getting at, but I have yet to find myself maintaining C++ code that has been poorly written as a result of the design of the language.


That's unfortunately something you can say about any language.


I've encountered each of these myths "in the wild," and I dare say you'll see them thrown up repeatedly here on HN in various contexts.

The third item on that list especially is something you can almost certainly see every day in a random HN thread about programming languages (along with counterpoints).

In fact, 'safety', of which GC is a subset, is a huge objection, and one of the first, most frequently raised in my experience. People are afraid of pointers, some rightly (e.g. because they've personally experienced bad memory management code, or they've never worked outside of a dynamic language, etc.), but most not.


Note that one can be against a programming language feature without being afraid of them. I think pointers are a bad feature in a programming language because they're not necessary. It's rather unfortunate that Go, for example, supports pointers (which is of course not surprising when you consider who designed it).


It's hard to deal with low-level code without resorting to pointers in some ways, though. I can't think of a low-level language that doens't use them, actually.


That's true, although you can always use pointers without pointers being a language-level feature. That said, if the programming language is designed for low-level code then pointers are beneifical in my opinion. But is Go really designed to be a low-level language? I don't think so, and if it is, I will stay away from it if I can..


Go is middle-level, lower than scripting languages, higher than C++. You have control over memory layout, which lets you use less memory than a language that boxes everything (like Java or Python). You can use linear structs, or references to data, whatever fits your problem best. But, to do that, you need pointers.

However, Go pointers can't be casted to another type and you can't do pointer arithmetic. In this way, they are very close to Java or Python references, except they're made explicit. How can these kinds of pointers be any worse than references ?


>How can these kinds of pointers be any worse than references ?

Because references are easier to use.


I get your point, although I think references are not that easier ; if one doesn't think what's happening underneath when using refernces, nasty bugs can occur.


You're correct, of course, and I should probably have not used that loaded term.


The article does not claim to be refuting objections, but debunking myths.


Congratulations! Your accusation of Stroustrup's strawman is strawman itself.


> ever again

I don't understand this claim. They are still calling hot devices laptops today. Do you mean that at some point in the future they will stop, and then they will never again call these devices laptops?


I don't think Apple ever calls any of their machines 'laptops' – that's the point.


That's true, but I have a hard time believing it has anything to do with the fact that their laptops can get really hot. It's clearly marketing to differentiate themselves from their competitors.


Apple stopped using the word 'laptop' when they were still struggling with trying to put a G5 in a portable computer that didn't require jet engine fans.


Right. And the reason why it keeps breaking? Well, the solder on the board might not have any flux left, so it might have trouble flowing properly. There could be a cold joint, etc.

If it fails again, one possible next step would be to grab a multimeter and test the resistance across each component on the board. If the resistance is infinite, that might be your problem component.


There's more than resistors on logic board. Also, by even touching component leads with multimeter probes is sometimes enough to connect the joint back thus fooling you to think connection was ok.

Also, the problem might as well be one of the numerous chips in BGA packages whose connection points you can't even see, let alone- probe.


Don't you have to isolate components from the circuit to check resistance? Otherwise, you're looking also the other components look like the other arm(s) of a parallel circuit.


You know what, you're right. I saw a video of someone testing that a chip had been soldered on correctly with a multimeter, but he was testing for the lack of a connection. Testing for a connection would not be done this way.My bad.



Presumably the police would maintain a minimal, unobtrusive monitoring presence and only gear up/deploy if violence began. This might delay response during a violent protest, but, in theory, would make a peaceful protest safer and might prevent it from turning violent. I don't know what to think about the proposal but it's not completely ridiculous.


> There are no boundaries to our "rights".

I propose you test this claim by one of the methods the grandparent suggested. The protest-by-occupying-a-random-person's-house idea seems like a good one to pick.


I wonder. Do you sign any agreement that prohibits hidden city routing when you buy the ticket? If so, on an ethical level, it's not the same as the sandwich buying scenario, where you are not signing any additional agreement.

I wonder what I would do if I were the airline. Obviously the simplest thing would be to suspend the return ticket, but I suppose that the return ticket would typically be booked on a different airline. Another option would be to collaborate with other airlines to suspend return tickets, but I suppose that would be collusion and wouldn't fly with regulators. You could also try a prisoner's dilemma-y thing where future sales to a customer that has hidden city-routed in the past are marked up to fix the difference. If all airlines did this then only infrequent flyers would be able to hidden-city route. But if any airline refuses to participate, it might be tough for the business of the airlines that engaged in this practice.

Tough situation for the airlines. Not that I have too much sympathy, but I do take it into perspective that travelling is historically extremely cheap. It's a great time to be a flyer.


Do you sign any agreement that prohibits only eating one half of a sandwich? Would any such agreement be reasonable if buried in a dense online ordering click-wrap?


Reasonable . . . hrm. Hard to say. The surface area of duties and rights associated with an airline ticket in particular and airline travel in general are so vast that some level of clickwrap is unavoidable, not to mention the various laws that cover the industry.

Comparatively, the duties and rights regarding a physical good like a sandwich are fairly simple -- it behaves like most simple physical goods. You buy it, then you can do what you want with it. Airline tickets are unlike this in a variety of ways. Hidden city routing being prohibited would not, I feel, be qualitatively different than many of these other restrictions.


I buy a sandwich; I can eat all of it or some of it.

I buy airplane seats; I can sit in both seats or just one. If they don't like which seats I chose to sit in or not, they shouldn't have sold the ticket to me in the first place.


They're not really "selling you tickets" on specific flights. They're selling you the service of hauling you from from your starting point to your destination - possibly on the route planned, or possibly on other routes. This includes such things as sending you on another airline, or on a train, or putting you up in a hotel room.

I think the airlines would be willing to ignore a handful of people skipping out on a leg here or there. Pricing is obviously a major issue, but I think even moreso than that, if this were to become a common/well accepted way of buying tickets, there are serious issues in case of cancellations/delays/missed connections that, while fine in the hands of those who know they're subjecting themselves to the risk of being stranded, would lead to a bunch of "I bought a ticket to Chicago and United is going to leave me in Nantucket unless I buy a second ticket" news stories in case of a snowstorm.


> They're not really "selling you tickets" on specific flights.

They really are.

Coca-cola are marketing a refreshing tasty sparkling beverage, but what they're actually selling is carbonated water with sugar and acid. If I use it to clean my driveway, that's my prerogative, and Coca-cola don't get to retroactively charge me more because driveway cleaning chemicals are a more profitable market.


Funny that you bring that up, because that's actually happened! (Almost.) It's why alcohol-for-drinking is more expensive than alcohol-for-cleaning.

The government wanted to tax people it they drink it but not if they just clean with it. But then people (well, alcoholics mainly) realized they could buy the untaxed one "for cleaning" but then turn around and drink it. Can't have that!

End result: denatured alcohol, which (given taxes) is cheaper than the drinking kind because they "yuck it up" to the point that you can't drink it.

I just hope they don't do the analogous thing here, which would be like "poison you and hold the antidote at the ticket's final location" :-O


The problem with analogies is that just because you can make two things sound similar does not mean they are.

The statement you made about airline tickets is normative, not descriptive. I'm curious about how things actually are, not how people on HN want them to be.


Yes, you agree for both the fare rules of the specific ticket you bought and the airline's contract of carriage, both of which are approved by the Department of Transportation. And (at least) the CoC prohibits hidden-city ticketing.


Thanks! I could not find the contract on JetBlue's site when I went looking last night. But here is the contract for American Airlines.

http://www.aa.com/i18n/customerService/customerCommitment/co...

As you can see, hidden city routing is prohibited, and they retain the right to assess the difference between the ticket you actually used and what you paid if you engage in the practice.


I'm afraid that "the police were about to find out about me through this guy" does not count as a reasonable excuse for murdering someone.


It doesn't, but it's also not a non-violent threat. The police were out to lock him in a cage for decades.


No enforcement of any law is completely non-violent. That doesn't in any way excuse or justify killing or trying to kill to avoid enforcement.


I think you rephrased what I just said.


It appeared that you were trying to minimize taking out a hit on someone because, to paraphrase, "the police started it." If that isn't what you were doing, my bad, but if it was, then my comment was as designed.


But the police can take out a hit on me if I start a commotion and flee. Then they will pursue me with the intent (or legal right) to kill me and I will be blamed for it.

So it makes sense to blame the police for starting a commotion that set in motion a situation that would not have arisen otherwise.

Just playing devil's advocate, but the only difference I see here is that the government has a monopoly on law and they hire the police, and the killer that person allegedly hired is not working for the law the government made, but for the law that person made.

So there's no need to pontificate here. This is just the difference between an organization having a monopoly on violence and then acting surprised when others want to make contracts with rules based on violence as well.

Not to mention our current president has ordered the murder of US citizens before but no one is arresting him.


The court has to pretend that. We in the public can follow any decision rule we please, including maximum likelihood.


In reality, when this happens, the companies in question call each other up and fix it, generally speaking.


Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: