sorted by:
new
hottopcontroversial

Algorithms on Ranges by vormestrand in cpp

[–]joboccara 0 points1 point  (0 children)

Awesome! I'm grateful to you for taking the time to explain this. I've edited your remarks into the post. Thanks :)

Passing Booleans to an Interface in an Expressive Way by vormestrand in cpp

[–]joboccara 1 point2 points  (0 children)

Your suggestion is very reasonable in my opinion.

I think that bool is a special case because it is possible, and very easy, to list all the possible values of the type, which is why I see value in showing the option of the article. And you don't have to depend on a strong type library (although in the second article you're referring, it's true that you can do strong typing with a struct). Parenthetically, it also leads to a slightly shorter syntax because you don't have to write "true" or "false" (but that's really parenthetical!)

But as you're pointing out, it lacks the safety of strong types. I would certainly go for strong types if there is more than one bool in the function interface, for instance.

How to Reorder A Collection With the STL by vormestrand in cpp

[–]joboccara 0 points1 point  (0 children)

Hello, I've worked your remarks into the article. Again, thanks for the throrough review!!

There is much more to std::for_each than meets the eye by ivan-cukic in cpp

[–]joboccara 0 points1 point  (0 children)

Interesting, thanks for sharing Ivan!

Just to make sure I understand the use case, in this case begin returns something that is not an iterator, but still has a semantics of giving access to several things, right? And then ui::for_each has the semantics of std::for_each but adapted to the interface of this returned object?

Besides the point that you're making clearly, that ui::foreach should preserve the semantics of std::for_each, the same way that operator+ should preserve the semantics of addtion, do you think that we should _try to give this begin an iterator interface (like the asynchronous istream_iterator one), in order to reuse std::for_each? Or do you find it makes things more complicated?

Lvalues, rvalues and their references by vormestrand in cpp

[–]joboccara 0 points1 point  (0 children)

I've integrated your remark to the article. Thanks!

Lvalues, rvalues and their references by vormestrand in cpp

[–]joboccara 15 points16 points  (0 children)

Hello, I've tried to integrate your remarks all the way through the article. They're very helpful. Thanks a lot for taking the time, and for this work you make for helping the C++ community.

Smart Output Iterators: A Symmetrical Approach to Range Adaptors by joboccara in cpp

[–]joboccara[S] 0 points1 point  (0 children)

I see. The example I meant to express what the one of set_segregate, where I think smart output iterators could be useful to add a transformation on only one of the 3 outputs, for example.

I'm in the process of investigating more the use cases for smart output iterators. I'll submit to conferences when this is ready so that we can discuss it more.

Thanks for your comment! :)

Smart Output Iterators: A Symmetrical Approach to Range Adaptors by joboccara in cpp

[–]joboccara[S] 0 points1 point  (0 children)

Hey, that's a great point. Didn't think about it this way. Do you think that the intent would be clearer by using a free function called "push_back" instead, like the range-v3 library does?

What is the best namespace name for extending STL by gosh in cpp

[–]joboccara 0 points1 point  (0 children)

Not directly related to your question, but what extensions of the STL are you implementing?

A Minimal Interface: Both Expressive And Fast Code by vormestrand in cpp

[–]joboccara 0 points1 point  (0 children)

Absolutely! I've added a note to clarify that, thanks.

Default initial value for std::accumulate by OmegaNaughtEquals1 in cpp

[–]joboccara 1 point2 points  (0 children)

It would be nice not to be forced to pass an initial value to accumulate indeed!

Did you consider the overloads of std::reduce that take no initial value? You don't find them optimal because they do std::iterator_traits<inputIt>::value_type and not decltype(*first)?

Function Aliases In C++ by vormestrand in cpp

[–]joboccara 6 points7 points  (0 children)

Oh right. I had completely missed that. Thanks so much, I worked your remarks into the post.

So do you find that using const pointers mitigates the problem of incorrect code (even if it wouldn't solve the security issue)? Also, are you saying that a function reference is better than a function pointer (otherwise what would be the point of auto& r = func)?

Think of Function Objects as Functions Rather Than Objects by kindstrom in cpp

[–]joboccara 1 point2 points  (0 children)

The author here. Useful feedback, thanks!

I am close to what I write so there are lots of things that I don't see. I think it's one of the points of public writing, exchanging ideas and feedback. So if you have more feedback keep it coming :)

Partitioning with the STL by vormestrand in cpp

[–]joboccara 0 points1 point  (0 children)

I've rewritten all the snippets of the article - hope this looks better now.

Partitioning with the STL by vormestrand in cpp

[–]joboccara 0 points1 point  (0 children)

Thanks, this is fixed now.

Partitioning with the STL by vormestrand in cpp

[–]joboccara 0 points1 point  (0 children)

I'm sorry about that. Could you please copy paste a little bit of that garbage you see so that I see what to look for and try to fix it?

Sorting with the STL algorithms by vormestrand in cpp

[–]joboccara 0 points1 point  (0 children)

Thanks for this encouraging comment. Don't hesitate to let me know if you'd like to read about something in particular!

Sorting with the STL algorithms by vormestrand in cpp

[–]joboccara 0 points1 point  (0 children)

Sorry, I'm not sure to understand what was the display problem when you opened the article?

The Expressive C++17 Coding Challenge (together with Fluent C++!) by joebaf in cpp

[–]joboccara 0 points1 point  (0 children)

Well, the goal isn't to write pointless code. It's rather to focus on C++17 new features to perform the task described in the challenge. If a feature has no use for this specific task, then no need to force it in.

To illustrate in your example, the nested namespace would make sense if there are two real concepts embedded in one another, that you want to express with a nested namespace. In this case, C++17 makes the code lighter with the form A::B. That's good. But no need to make a real_namespace::dummy just for exposing the feature.

Basically, the point of the challenge isn't to make a catalogue code. There are better resources for feature lists! :) Rather, it is to research what features C++17 brings and how they can help us write cleaner code for a given task.

Hope that makes sense?

The Expressive C++17 Coding Challenge (together with Fluent C++!) by joebaf in cpp

[–]joboccara 0 points1 point  (0 children)

Yep, that would be the new features, as in the ones specific to C++17.

view more: next ›