The advent of std::optional (EDIT: Delayed past C++14)

[LB]

http://en.cppreference.com/w/cpp/utility/optional

When a good deal of compilers support std::optional, do you think we will need to adjust tutorials that explain when to use pointers as function parameters? E.g. in this article:
http://www.cplusplus.com/articles/z6vU7k9E/
As well as in many others, it is suggested to use pointer parameters when the parameter may be [code]nullptr[/tt], or, in other words, when the parameter is optional.

Or do you think that the traditional pass-by-pointer technique has benefits over std::optional? Exclude speed/performance, as we will assume for the sake of this discussion that compilers can optimize both versions to equivalent code.

Note also that this is not only relevant to function parameters, as optional data is common in other places too - function parameters just seemed most iconic to me.

Personally, I will immediately start using std::optional - I dislike the ugly pointer syntax with a passion and even the workarounds like making a reference to the dereferenced pointer.

EDIT: It seems that std::optional won't be making it into C++14 after all. Oh well. I guess we can assume it will make it to C++17 (or whatever year that is expected to be released).

[Cubbi]

It's been available as boost::optional since 2003..

[helios]

Pointers are compatible with C, which is important if you need a consistent ABI.

[LB]

@Cubbi: I know, but now it's integrated in C++ and thus is much easier to suggest in answers to questions. Many people shy away from the idea of using an external library to answer a simple question and so many good practices are left untaught.

@helios: Good point, I forgot to mention that for the sake of discussion we're ignoring the fact that C exists. There are many nifty C++ things which can't be shown to C code :)

[helios]

Well, you don't need them just to interact with C. If your library can't be recompiled for every C++ compiler its users might choose, you need to export unmangled symbols.

[LB]

helios wrote:

If your library can't be recompiled for every C++ compiler its users might choose, you need to export unmangled symbols.

I'm not sure what you mean by this, could you give a common scenario for this? What does it have to do with std::optional?

[chrisname]

I think he's referring to the lack of binary compatibility between different C++ compilers due to the lack of a standardised symbol mangling scheme, hence why you would have to export unmangled symbols.

[LB]

I know, but I'm confused as to what that has to do with std::optional.

EDIT: I've been doing some research and found that it's possible std::optional won't make it to C++14!
http://libcxx.llvm.org/cxx1y_status.html
The above page mentions that 3672 is "Removed from Draft Standard". Does this really mean it might not be part of C++14?

[Cubbi]

Yep, looks like they couldn't resolve the issues around rel.ops that a couple national bodies raised.

[LB]

Aw. I'm interested though, can you link to or explain what the issues were?

[Cubbi]

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3765.pdf discusses some of the issues. It's not completely gone, it's just moved out of WP into a TS (a separate document)

[chrisname]

Can't they make it optional? (ba dum tss)

[LB]

Depending on how close the interfaces of std::optional and boost::optional are, you may be able to make a simple header that detects whether std::optional is available and if not aliases boost::optional into the std namespace. Though I don't know if there's a way to conditionally execute code at compile time based only on the existence of a class. Maybe with some template magic?

Also, I assume that std::optional is trivial to implement yourself anyway.

[chrisname]

Why would you have to do it at runtime? I think you could probably use conditional compilation with macros; something like this:

#ifdef NEED_STD_OPTIONAL
# include <boost/optional.hpp>
# undef NEED_STD_OPTIONAL
namespace std { class optional : public boost::optional {}; }
#endif // NEED_STD_OPTIONAL 

where NEED_STD_OPTIONAL is defined in your Makefile if and only if the following code can be compiled by the configure script:

#include <optional>

int main()
{
    std::optional<int> x;
    return 0;
}

[LB]

chrisname, where did I mention anything that gave you the impression I was thinking about runtime?

And I'm trying to think of a solution that can detect it automatically - no external help.

Also, I don't think simply inheriting boost::optional is enough, unless you were just doing that for demonstration - but why not use an alias?

[JLBorges]

> and if not aliases boost::optional into the std namespace.

The behavior of a C++ program is undefined if it adds declarations or definitions to namespace std or to a namespace within namespace std unless otherwise specified. A program may add a template specialization
for any standard library template to namespace std only if the declaration depends on a user-defined type and the specialization meets the standard library requirements for the original template and is not explicitly
prohibited. - IS

Use a namespace of your own in which either std::optonal<> or boost::optional<> is aliased.


> And I'm trying to think of a solution that can detect it automatically - no external help.

Use the toolchain to check for the existence of a header (for instance <optional>).
In your case autoconf http://en.wikipedia.org/wiki/Autoconf
which is available in MSYS http://www.mingw.org/category/wiki/autotools

Or use equivalent facilities in an alternate build system like CMake.

[chrisname]

LB wrote:

where did I mention anything that gave you the impression I was thinking about runtime?

Oops, I misread "compile time" in your post as "runtime".

I'm trying to think of a solution that can detect it automatically - no external help.

I suppose that would be better.

I don't think simply inheriting boost::optional is enough

Why not? If the interface is the same for both then it should appear to be identical to any calling code.

why not use an alias?

How would you do that?

JLBorges wrote:

Use the toolchain to check for the existence of a header (for instance <optional>).
In your case autoconf http://en.wikipedia.org/wiki/Autoconf
which is available in MSYS http://www.mingw.org/category/wiki/autotools

Or use equivalent facilities in an alternate build system like CMake.

That's what I suggested but that's "external help".

[LB]

chrisname wrote:

Why not? If the interface is the same for both then it should appear to be identical to any calling code.

I don't see any indication of inheriting constructors...

chrisname wrote:

How would you do that?

template<typename T>
using optional = boost::optional<T>;

[chrisname]

LB wrote:

Why not? If the interface is the same for both then it should appear to be identical to any calling code.

I don't see any indication of inheriting constructors...

Well I wasn't going into detail.

template<typename T>
using optional = boost::optional<T>;

Huh, I didn't know you could do that.

[LB]

Yeah, template aliases are really nice. I got told off for trying to do what you did with inheritance ;)

http://ideone.com/eH9Yyf