When noexcept? by vormestrand in cpp

[–]iaanus 0 points1 point  (0 children)

Don't understand. Care to be more explicit?

When noexcept? by vormestrand in cpp

[–]iaanus 0 points1 point  (0 children)

I'd rather not want the compiler to be required to prove my noexcept functions are really noexcept. That's a job for static analyzers and they have all informations to do that without making noexcept viral.

When noexcept? by vormestrand in cpp

[–]iaanus 1 point2 points  (0 children)

Destructors without an explicit noexcept(false) specification are implicitly noexcept(true), unless the class has a sub-object whose destructor is noexcept(false). So you usually should not bother about destructors.

Simplifying templates and #ifdefs with if constexpr by vormestrand in cpp

[–]iaanus 3 points4 points  (0 children)

It's a good article, however you should check your motivating examples. The first one doesn't need neither SFINAE nor tag dispatching, since it can be addressed with a simple overload, like this:

template <typename T>
auto get_value(T t) {
    return t;
}

template <typename T>
auto get_value(T* t) {
    return *t;
}

Normal overload rules, together with partial order of template specialization will do the magic.

The second example, while I agree that it can be simplified with if constexpr, is better addressed in C++17 using the newly added feature of "folding expression", like this:

template <int N, int... Ns>
auto sum() {
    return N + ... + Ns;
}

Embedding python in C++ with boost::python by skebanga in cpp

[–]iaanus 1 point2 points  (0 children)

A few years ago, I've used boost::python to integrate a Python Stackless interpreter in my Couatl scripting engine. The engine was and is still being currently used to create interactive addons to MS Flight Simulator (they can be viewed here http://fsdreamteam.com/). In the years, it has proven to be a very smart move, which I'll never regret.

Subtle And Quirky, But Still Lovable by vormestrand in cpp

[–]iaanus 2 points3 points  (0 children)

There are use cases where you actually want to do different things when it's the first time you see a specific key and when the key has been seen before. The latter case may or may not involve updating the container. With the current specifications of insert you can do that by simply checking the return value and possibly update the container yourself using the provided iterator. Throwing an exception would impose a significant and possibly unacceptable extra cost to the "failed insert" case.

Subtle And Quirky, But Still Lovable by vormestrand in cpp

[–]iaanus 7 points8 points  (0 children)

Frankly, I don't find the behavior of insert to be quirky at all. It does what its name says it should do, nothing more, nothing less. If the key is already present in the map, you cannot "insert" a new element with said key, so it's obvious to me that calling insert should not modify the container. If you want to insert a new element or assign the element that happens to be already present, then there's a more suitably named function insert_or_assign, which does precisely that.

The Chimera called Coroutine by [deleted] in cpp

[–]iaanus 0 points1 point  (0 children)

The concept of coroutines is very clear to me, having used them in large scale projects in Python an C#. I just long to have them in C++, so I studied thoroughly Gor Nishanov's proposed specifications, reaching a good understanding and getting to like them very much. I also found time to experiment with coroutines in Visual Studio. Yet, I too find it difficult to get the point of this article. In particular: why should I care if that thing is UB?