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

C++11 and Boost - Succinct like Python

fendrich.se

Post reply on HN
Print view View original

121–130 of 172 posts

Re: C++11 and Boost - Succinct like Python

#121

Post by Locke1689 »

fusiongyro wrote: post #115
Locke1689 wrote: post #104

Earlier quoted context omitted.

Just to elaborate on what danking00 is saying, the extra syntax in this case is not adding any extra information (to the compiler). The left hand type of the expression can be completely inferred at compile time, in this case. What that required syntax is adding is pain, but no gain (except for imperceptibly faster compile time). In Haskell this would look like: TagDataMap = [ ("title", ((3, 30, stripnulls)), ("artis…

"the extra syntax in this case is not adding any extra information (to the compiler)." This actually isn't true in C++, because there could be many classes in scope that could take a list initializer like this. In Haskell, no literal with [] can "turn into" something besides a list, but that can happen in C++: vector items = {1,2,3,4}; int[] items = {1,2,3,4}; These have different types, so how would C++ know which o…

This is definitely true and demonstrates how competing design decisions can add huge complexity to a language. C++ made earlier design goals to allow heavily context-dependent overriding, which has side effects on what features it can add later.

Re: C++11 and Boost - Succinct like Python

#122

Post by mquander »

blub wrote: post #100
jerf wrote: post #63

Earlier quoted context omitted.

How many other languages do you know? You sound like you know C++ really well and sort of know Python, and aren't clearly distinguishing between abstract readability (as ill-defined as that is) vs. how well you personally know the code you are reading. What's probably wrong with your Python reading is that you have to look up what the third parameter in the slice more than the slice parameter actually being confusing…

In most programming languages the [] operator allows one to access elements in a container. In this case, we are accessing the position "two colons minus one". I refuse to believe this makes any sort of sense for someone that has no deep knowledge of Python.

Lots of languages use [] with colon separators for array slicing, e.g. F#, Perl, Ruby. The idea that this syntax involves "deep knowledge" is laughable.

Your criticism is analogous to me looking at "int* foo = bar()" and saying, hey, we're multiplying a type by a name! How ridiculous!

Re: C++11 and Boost - Succinct like Python

#123

Post by simmons »

zvrba wrote: post #116
simmons wrote: post #97

I've been using both C++11 and Python lately. While the new C++11 features add a lot of value, I still find it frustratingly verbose for some things. For example, finding an element in a collection: std::string type = "foo"; auto it = std::find_if( channel_widgets.begin(), channel_widgets.end(), [type](const std::shared_ptr &w){ return (w->getType() == type); } ); if (it == channel_widgets.end()) { std::cerr target_w…

Um... maybe it's verbose because you're trying to be too clever? :-P How about auto it = channel_widgets.begin(); while (it != channel_widgets.end()) if (it->getType() == type) goto found; // error found: // whatever I kinda hate myself every time I write such for-loop, but it's still more succint than any variant of find_if. Generally, I use "trivial" STL algorithms (find, find_if, for_each, ...) only if I can reuse…

A similar approach occurred to me as I was writing that example. (Using a range-based for loop, break on found.) I guess I'm mostly scratching my head trying to figure out find_if's place in the universe.

Re: C++11 and Boost - Succinct like Python

#124

Post by bcoates »

fusiongyro wrote: post #112
Myrmornis wrote: post #98

Earlier quoted context omitted.

This is what caught my eye too as being really ugly and hard to read. const map > TagDataMap { {"title" , make_tuple( 3, 30, stripnulls)}, Why can't the compiler figure out the types involved in this map structure itself? The user-defined functions are declared above, make_tuple will be declared in some library, and the others are string/int literals.

One thing you cannot do is infer `const`ness. This isn't a problem in Hindley-Milner systems because variables are not assignable--they're all `const`, all the time. Literals are inherently immutable but when you assign a C++ variable a literal value, sometimes you want a const variable and sometimes you don't. I don't think C++ can figure out the map part simply because lots of things could have list initializers th…

You can't do it with that syntax. 'auto' never infers constructor calls, just takes the static type of an LHS to capture a temporary into. You'd have to use a non-constructor template function that inspects the type of its argument to guess what kind of map you want.

  const auto TagDataMap = map_initializer( { "foo", { 1, 20, func }, ... } );
where map_initializer would be a template function that inspects the typedefs of its std::initializer_list argument and generates an appropriate map.

In real C++ code, this would almost never be what you actually want, though, as the types in an initializer list in C++ do not imply the types being initialized, they are parameters to a constructor to be determined elsewhere.

Re: C++11 and Boost - Succinct like Python

#125

Post by fusiongyro »

bcoates wrote: post #124
fusiongyro wrote: post #112

Earlier quoted context omitted.

One thing you cannot do is infer `const`ness. This isn't a problem in Hindley-Milner systems because variables are not assignable--they're all `const`, all the time. Literals are inherently immutable but when you assign a C++ variable a literal value, sometimes you want a const variable and sometimes you don't. I don't think C++ can figure out the map part simply because lots of things could have list initializers th…

You can't do it with that syntax. 'auto' never infers constructor calls, just takes the static type of an LHS to capture a temporary into. You'd have to use a non-constructor template function that inspects the type of its argument to guess what kind of map you want. const auto TagDataMap = map_initializer( { "foo", { 1, 20, func }, ... } ); where map_initializer would be a template function that inspects the typedef…

Thanks for clearing that up. I'm just starting to play with C++11 and have some trouble getting to a supporting compiler from work.

Re: C++11 and Boost - Succinct like Python

#126

Post by mikeash »

daivd wrote: post #53
fafner wrote: post #48

Earlier quoted context omitted.

For ord he could use std::to_string string ord(string const &s) { return to_string(unsigned(s[0])); } He skips all the const-refs...

Yes, to_string would have been better The C-style cast is shorter, but less safe, so you should not use it: http://stackoverflow.com/questions/1609163/what-is-the-diffe... Yeah, I couldn't quite decide if I should include const refs. On the one hand, it is idiomatic, but on the other hand I didn't want to clutter the code with something that is just an optimization on paper.

How can a C-style cast from char to unsigned possibly be "less safe", and how could a different style of cast be more safe?

Re: C++11 and Boost - Succinct like Python

#128

Post by eru »

derleth wrote: post #94
alpatters wrote: post #74

Earlier quoted context omitted.

The extra syntax is not there for nothing. It's adding type information. Thus allowing error checking or dispatching by type or optimisations at compile time. It is a cost in terms of syntax and readability but it's not for nothing. So for correct programs the end result might be the same in terms of values. For buggy code and runtime speed that's not necessarily the case.

> The extra syntax is not there for nothing. You could say the same thing about everything old C++ compelled you to type. Or old COBOL, for that matter. I'm more interested in what the C++ memory allocation style does to verbosity. Memory-handling styles are often more important than the traditional paradigms (functional, OO, etc.) in determining what's reasonable/pleasant to do in a given language. https://sites.goo…

But aren't all allocation styles basically the same once you get GC? (I guess unless you broaden the scope of the word, and let it describe the lengths you go in Haskell to avoid allocation at all, aka triggering stream fusion and automatic deforrestation in general.)

Re: C++11 and Boost - Succinct like Python

#129

Post by Peaker »

fusiongyro wrote: post #115
Locke1689 wrote: post #104

Earlier quoted context omitted.

Just to elaborate on what danking00 is saying, the extra syntax in this case is not adding any extra information (to the compiler). The left hand type of the expression can be completely inferred at compile time, in this case. What that required syntax is adding is pain, but no gain (except for imperceptibly faster compile time). In Haskell this would look like: TagDataMap = [ ("title", ((3, 30, stripnulls)), ("artis…

"the extra syntax in this case is not adding any extra information (to the compiler)." This actually isn't true in C++, because there could be many classes in scope that could take a list initializer like this. In Haskell, no literal with [] can "turn into" something besides a list, but that can happen in C++: vector items = {1,2,3,4}; int[] items = {1,2,3,4}; These have different types, so how would C++ know which o…

Integers and Strings aren't edge cases. Their literals are polymorphic and typed.

C++ could also type its list initializers with some polymorphic type (similar to Haskell's Num) but didn't do so.

This is not inherent.

Re: C++11 and Boost - Succinct like Python

#130

Post by jerf »

blub wrote: post #100
jerf wrote: post #63

Earlier quoted context omitted.

How many other languages do you know? You sound like you know C++ really well and sort of know Python, and aren't clearly distinguishing between abstract readability (as ill-defined as that is) vs. how well you personally know the code you are reading. What's probably wrong with your Python reading is that you have to look up what the third parameter in the slice more than the slice parameter actually being confusing…

In most programming languages the [] operator allows one to access elements in a container. In this case, we are accessing the position "two colons minus one". I refuse to believe this makes any sort of sense for someone that has no deep knowledge of Python.

Your username is a little too on the nose here. Plus you seem to have somehow entirely missed my point, to a degree I wonder if it is deliberate. Is this some sort of troll?
Post reply on HN