Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

apenwarr.ca

Post reply on HN
Print view View original

61–70 of 187 posts

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

#61

Post by AnimalMuppet »

unlinked_dll wrote: post #9

Most of what the author complains about w.r.t callbacks is fixed with std::function and lambdas (member function pointer syntax is necessarily weird, because methods aren't just normal functions). I definitely don't miss the days of std::bind. Nowadays you just do something like using Callback = std::function ; // or whatever Callback cbk = [&](int i) { return instance.method(i); }; I've also seen some real evil hack…

What's so awful about pointer to member? I've used it a couple of times, and didn't think it was particularly weird. I mean, yes, I had to look up the syntax, but it was rather straightforward.

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

#62

Post by Espressosaurus »

kllrnohj wrote: post #57
vlovich123 wrote: post #47

Earlier quoted context omitted.

I still think the STL containers are the sane default to reach for & switch to more obscure ones when the problem domain and performance requirements say to use a different one.

You have that backwards. The STL containers are for when you have a hyper-specific niche use case. They are otherwise terrible defaults and everyone should use boost or abseil by default otherwise. std::map, for example, is only appropriate if you need a red-black tree specifically. Which almost nobody does. std::unordered_map is less awful, but abseil has a literal straight upgrade. With the same API. So... why woul…

Because that way you don't need to haul in dependencies unless you have a real reason.

std::function is fine for prototyping, but its size hit is extreme, so in embedded code we use other implementations. But where size and speed doesn't matter? Why bother?

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

#63

Post by ajna91 »

Tallasatree wrote: post #38
Rusky wrote: 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…

2 people equally confident in their own, completely opposing opinions. Every comment enabled website in a nutshell.

The real problem is everyone else who pattern-matches confidence with competence and upvotes.

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

#64

Post by AnimalMuppet »

TheOtherHobbes wrote: post #28
nineteen999 wrote: post #25

Earlier quoted context omitted.

Difference is, C++ actually has more than single digit mind/marketshare outside the safety of the HN eggcup.

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?

I don't know about templating, but... is Haskell's Hindley-Milner type identification system Turing complete? For that matter, Lisp's macros are definitely Turing complete, and they are... a templating system on steroids, maybe?

About mindshare: Lisp has zealots, but they are few, even if they are loud, and they are on HN more than many other places. C++ is perhaps not loved, but in some circles it is very well respected, the way a chef respects a very sharp knife. The value lies precisely in the sharpness.

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

#65

Post by WalterBright »

coding123 wrote: post #60
crazypython wrote: post #41

You can make C++ pretty: it's called D. https://dlang.org/comparison.html Here's the D C++ intercompatibility project: https://wiki.dlang.org/Calypso#Current_status

There's always a D guy lurking about.

We're everywhere.

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

#66

Post by WalterBright »

TheOtherHobbes wrote: post #28
nineteen999 wrote: post #25

Earlier quoted context omitted.

Difference is, C++ actually has more than single digit mind/marketshare outside the safety of the HN eggcup.

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?

D does. It's just that nobody uses it for that, because CTFE (Compile Time Function Execution) is so much better.

https://dlang.org/spec/function.html#interpretation

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

#68

Post by mrpippy »

kevin_thibedeau wrote: post #55
gumby wrote: post #2

This decade old article describes an ancient and obsolete language (C++03 probably though some of the text suggests it might be C++98). It's not worth reading in 2020. Modern C++ is a very different language though it can still almost completely interoperate with quite old code. C++11 and C++14 already addressed most of the things brought up, and contemporary C++ (obviously most code is not in it yet) even supports g…

Some of us still have to use outdated C++ compilers where the ::std namespace doesn't exist and all the modern goodies are but a dream.

Yikes, what platform is this?

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

#69

Post by WesternStar »

unlinked_dll wrote: post #9

Most of what the author complains about w.r.t callbacks is fixed with std::function and lambdas (member function pointer syntax is necessarily weird, because methods aren't just normal functions). I definitely don't miss the days of std::bind. Nowadays you just do something like using Callback = std::function ; // or whatever Callback cbk = [&](int i) { return instance.method(i); }; I've also seen some real evil hack…

It is notable that this code forces a conversion to std::function which IIRC can actually require more space than the lambda it's attempting to store. For lambdas just use auto they don't have a type don't worry about their type.

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

#70

Post by cryptonector » 

  > But in python, it works perfectly (even for
  > user-defined types). How? Simple. Python's parser
  > has a little hack in it - which I'm sure must hurt
  > the python people a lot, so much do they hate
  > hacks - that makes m[5]= parse differently than
  > just plain m[5].
  > 
  > The python parser converts o[x]=y directly into
  > o.setitem(x,y).
The name for this is "generalized variables", at least in Lisp land. The idea is to allow complex assignment left-hand side (LHS) expressions and turn assignments into calls to setter functions, including whatever complex data structure traversals might be needed.

Lisp has generalized variables via "setf macros", which turn assignments into the right set of calls to setter functions. Setf macros do this at compile time and generically for any getter/setter functions that have been registered with a bit of ceremony.

(Lisp also has destructuring-bind, which lets you write a data structure with variable symbols in it such that the corresponding variables will be bound to the data find in the corresponding places of a real data structure value. The two features, destructuring and generalized variables, are similarly magical.)

jq can do crazy generalized variable assignments like '.a[].b[0] = 1', but this is a run-time thing. (The LHS is evaluated in a context that allows only "path expressions", and in a reduction, while the RHS expression is run in the body of the reduction to update the input value at each path matched by the LHS.)

Icon implements generalized variables by letting procedures return "places" -- references to assignable locations --, so you can assign to the return value of procedures. This may seem quite surprising when you see it, but it works beautifully.

Post reply on HN