Live data from Hacker News

You can't make C++ not ugly, but you can't not try (2010)

apenwarr.ca

181–187 of 187 posts

Re: You can't make C++ not ugly, but you can't not try (2010)

#181
post #102

Earlier quoted context omitted.

> Because that way you don't need to haul in dependencies unless you have a real reason. These are all largely header libraries. You're already hauling in a dependency, and in every c++ file that uses it at that. > std::function is fine for prototyping std::function isn't part of the containers library of the STL (containers being all the stuff here: https://en.cppreference.com/w/cpp/container ). I agree std::functio…

> These are all largely header libraries. That's not even true for boost, no matter if they always advertise that. The lib is also notorious for bad decomposability (using only a subset without installing the whole monster). Not to speak about idiosyncratic naming and build system, making it sometimes hard to include it in meta builds of other libraries and frameworks. In sum: Anyone sensible, regarding different kin…

boost does not advertise being an header only library. Some boost libraries are header only, some offer hybrid modes, some require a library to be linked in. Each case is documented individually.

Boost is better thought as a loose collection of libraries that try to follow some common design principles instead of a single monolithic library.

I can't defend the build system though.

Re: You can't make C++ not ugly, but you can't not try (2010)

#182
post #166

Earlier quoted context omitted.

> OK but if you're a competent, adult software engineer "No true Scotsman" and all, please refrain from posting messages that add nothing of value besides petty insults thrown in broad brush strokes.

Much as I didn't mean to insult anyone with my post, I'm sure you meant to add value by calling it petty and fallacious. Picking up features in a language you already use is easier than learning the language to begin with which itself is easier than learning to program at all. If you were able to read the documentation to get to 50%, you have all the skills needed to pick up the rest and get to the difficult part of…

> Much as I didn't mean to insult anyone

You accused anyone who did not agreed with you of being incompetent and immature. In the very least own your own claims.

Re: You can't make C++ not ugly, but you can't not try (2010)

#184
post #18

Earlier quoted context omitted.

To the contrary, modern C++ has solved very few, if any, of the problems described in the article. Being generous: * There's now `std::string_view` to address some of the problems with `std::string`, but the rest are still there. There are some attempts to specify the encoding now, at least. * Lambdas and `std::function` pretty much solve the function pointer complaints, with some added complexity. * Containers still…

> To the contrary, modern C++ has solved very few, if any, of the problems described in the article. The author, after a long and dubious appeal to authority, claims that: * C++ exceptions are outright evil and should be avoided * C++ string class "is so utterly godawfully stupid" because it has no garbage collection or refcounting, and in short doesn't precisely match Python's implementation. He also felt personally…

Your version:

> The author [...] claims that C++ exceptions are outright evil and should be avoided

What the article actually says:

> This includes the RTTI and exceptions stuff; C++'s versions of those were enough to convince a whole generation of programmers that introspection and exceptions were outright evil and should be avoided

Your reading comprehension is lacking. You didn't understand what he is talking about. Why is Google not using exceptions?

Re: You can't make C++ not ugly, but you can't not try (2010)

#185

Earlier quoted context omitted.

Market share, maybe. Mindshare - Lisp has its zealots. C++ is tolerated rather than adored, because it's more of a Katamari Damacy of stray CS than a language with a coherent focus. How many other languages have a Turing complete sublanguage built into them just to handle templating?

> How many other languages have a Turing complete sublanguage built into them just to handle templating? On the bright side, C++ doesn't have obscure keywords like "cdr" and "car" that refer to specific hardware elements of an obsolete computer built in 1954.

No, C++ has obscure keywords like << which mean vastly different things, and can change, based on some invisible context.

Re: You can't make C++ not ugly, but you can't not try (2010)

#186

Earlier quoted context omitted.

Uh, what? Here's a simple example, clang supports windows. Clang's "bundled" standard library, libc++, doesn't support windows. Clang also not only allows but is commonly used with libstd++ instead. Mixing and matching compilers and standard libraries is not only possible it's common. Especially when cross-compiling enters the picture. There is no bundling of any kind in any concept of that word, practically or techn…

> Clang's "bundled" standard library, libc++, doesn't support windows. You're an awful troll. Clang on Windows is distributed to use the system installation of libstdc++, not clang's experimental libc++. https://clang.llvm.org/get_started.html > Clang also not only allows but is commonly used with libstd++ instead. That's because libc++ is clang's experimental implementation of the C++ standard library, developed to…

> You're an awful troll.

Chill on the name calling.

> Clang on Windows is distributed to use the system installation of libstdc++

Windows doesn't have a default system installation of C++ at all nor is it libstdc++. You can use clang on windows with libstdc++, but that's a MingW port and not at all "native" to the platform.

Windows' standard C++ runtime is the Visual C++ Redistributable and there are many versions of it that all coexist simultaneously. Which one is used depends on what the application was compiled against, there is no "system version" of it. Runtimes that Clang can also use.

> That's because libc++ is clang's experimental implementation of the C++ standard library

There is nothing experimental about libc++ at all. It is the standard for some platforms, like Android and MacOS/iOS. In fact Apple removed support for using libstdc++ entirely with Xcode 10. And before Xcode 10 you got a choice between libstdc++ & libc++, because again the C++ standard library is not bundled. Similarly on Android there used to be a choice between not just libstdc++ and libc++ but also stlport was an option. Now only libc++ is supported, and it's not provided by the system at all.

Re: You can't make C++ not ugly, but you can't not try (2010)

#187
post #166

Earlier quoted context omitted.

Much as I didn't mean to insult anyone with my post, I'm sure you meant to add value by calling it petty and fallacious. Picking up features in a language you already use is easier than learning the language to begin with which itself is easier than learning to program at all. If you were able to read the documentation to get to 50%, you have all the skills needed to pick up the rest and get to the difficult part of…

> Much as I didn't mean to insult anyone You accused anyone who did not agreed with you of being incompetent and immature. In the very least own your own claims.

Would you please stop posting in the flamewar style to HN? You've been doing it a lot lately, and it's really not what this site is for. What we want here is curious conversation, which generally requires stepping away from the keyboard when feeling provoked, even if other people are doing or saying bad things.

https://news.ycombinator.com/newsguidelines.html

Post reply on HN