7

I want to implement my own std::make_unique function with the function being part of std namespace. I know this helper function is added to C++14 but I do not have it in C++11. So, I want to check it with some C++11 template magic (couldn't find any options with macros) to check if a function exists inside the std namespace and if it doesn't define it on my own. Is that possible? I don't even know where to start.

Gasim
  • 7,615
  • 14
  • 64
  • 131
  • 2
    It's not possible from inside the program itself. You can however use tools like [autoconf](http://www.gnu.org/software/autoconf/) or [cmake](http://www.cmake.org/) to check for functions *before* the build, and define preprocessor macros depending on the results of the checks. – Some programmer dude Jan 27 '14 at 13:56
  • Why do you think it should be in `std` ? – MSalters Jan 27 '14 at 13:58
  • 2
    You might want to consider to always call your own function, and have that function dispatch to make_uniq or your own, depending on of std::make_uniq exists (detected via sfinae) – PlasmaHH Jan 27 '14 at 14:06
  • @MSalters because I wanted to be able to use `std::make_unique`, not something of my own that wraps around it. @PlasmaHH's after you comment, I am thinking of changing my "beliefs" on this particular code design. – Gasim Jan 27 '14 at 15:56

5 Answers5

6

You cannot add a new function to the ::std namespace. You are only allowed to add specializations of existing templates, and even then only for your own types.

David Rodríguez - dribeas
  • 204,818
  • 23
  • 294
  • 489
  • What prevents me from doing `namespace std { foo(); }`? – Sebastian Hoffmann Jan 27 '14 at 13:58
  • Just because you are not *allowed* to do it doesn't mean you *can't*. – Daniel Frey Jan 27 '14 at 14:10
  • 2
    @Paranaix: That your program becomes non-conforming, that a compiler detecting that might reject it, or it might do *anything* at all... @ Daniel: Yes, the *cannot* is in italics for a reason. – David Rodríguez - dribeas Jan 27 '14 at 14:14
  • @DanielFrey see http://stackoverflow.com/q/8513417/819272 Of course, you are likely to get away with it unless a compiler checks against the entire list of allowed names in `std` – TemplateRex Jan 27 '14 at 14:42
  • I doubt compiler would check for any additional library dependency. I have stumbled upon a post here regarding making a `std::bind` to bind placeholders automatically. Ill find it in a second – Gasim Jan 27 '14 at 16:05
  • found it: http://stackoverflow.com/questions/21192659/variadic-templates-and-stdbind. I am actually using something similar to it in my post and I haven't gotten any problems on LLVM and GCC. Lets hope MSVC doesn't cry about it. I like obeying c++ rules but in some specific situations (not my original post though. breaking a rule for that isn't worth it IMO - I didn't know if there was a rule about it earlier) breaking those rules might solve a specific problem, like the link above. – Gasim Jan 27 '14 at 16:08
  • @Gasim: I don't quite understand the point of the comments. We do agree that it is against what the standard guarantees, right? – David Rodríguez - dribeas Jan 27 '14 at 16:17
  • @DavidRodríguez-dribeas yes. sorry couldn't explain my thoughts cleaner. – Gasim Jan 27 '14 at 16:22
  • @Gasim you can introduce *specializations* into `std` for types dependent on your own types. You cannot introduce anything else into `std` without invoking undefined behavior. – Yakk - Adam Nevraumont Jan 27 '14 at 19:44
  • @Yakk the compiler still has to actively check against this for anything bad to happen. In practice copying, say, C++14 features from working papers into `namespace std` is unlikely to crash your program until your Standard Library itself defines the features. Although the proper way is to make your own `namespace cpp14` and work from there, and upgrade when your system has. – TemplateRex Jan 27 '14 at 19:52
  • 2
    @TemplateRex I can think of many ways this could cause bad things to happen without active checks. The feature is added without the version being updated, possibly with some differences. The compiler implements `std` "headers" as non-plain C++ code for optimization purposes, so your are interacting with something that only *looks* like a C++ namespace when you `std::`. People reading your code see `std::make_unique` in 4 years time and think it is C++1y's `make_unique`, but the standard shifted over that time, and now your code is unmaintainable. – Yakk - Adam Nevraumont Jan 27 '14 at 19:57
6

Your best bet is to use the standard __cplusplus macro which, for C++11, is 201103L. For C++14 onwards it will be a different value to this.

Bathsheba
  • 231,907
  • 34
  • 361
  • 483
1

This is not really an anwser but I want to point out that the committee is considering (see n3694) the generic question: How a programmer could determine whether an implementation has a particular feature (e.g. std::make_unique) or not?

Currently, the best we have is the macro __cplusplus (as per Bathsheba's post) but as explained in n3694 this doesn't give the fine grain that programmers might need. (The OP's question is an example of this need.)

Community
  • 1
  • 1
Cassio Neri
  • 19,583
  • 7
  • 46
  • 68
1

Introducing std::make_unique yourself is undefined behavior, period. There is no safe way to do it. On top of that, it is also inadvisable -- the advantage you gain is small, and the maintenance and code understandability costs are high.

What more, the odds are your make_unique will not match whatever gets published exactly, so your code will have a strange version dependency.

A better plan is to define your own make_unique somewhere else in your own utility namespace. If C++1y is active, you could using std::make_unique import it instead of your own make_unique.

This keeps your code standards compliant. It should also be clear to users of utility::make_unique that it isn't guaranteed to be identical to C++1y's make_unique.

This also lets you punt the problem of detecting std::make_unique until after it is standardized, and then deciding if it matches the interface you ended up implementing.

Yakk - Adam Nevraumont
  • 262,606
  • 27
  • 330
  • 524
0
#include <memory> // std::shared_ptr, std::unique_ptr

// C++11 check doesn't work in Visual Studio 2013/2015 properly because they are not fully C++11 compliant.
// https://connect.microsoft.com/VisualStudio/feedback/details/763051/a-value-of-predefined-macro-cplusplus-is-still-199711l
#ifndef WIN32
// C++11 Check
#if __cplusplus < 201103L
#error This library needs at least a C++11 compliant compiler.
#endif // >= C++11
#endif // WIN32


namespace std {

  // Note: despite not being even C++11 compliant, Visual Studio 2013 has their own implementation of std::make_unique.
#ifndef WIN32
#if (__cplusplus >= 201103L && __cplusplus < 201402L)
  // Define std::make_unique for pre-C++14
  template<typename T, typename... Args> inline unique_ptr<T> make_unique(Args&&... args) {
    return unique_ptr<T>(new T(forward<Args>(args)...));
  }
#endif // C++11 <= version < C++14
#endif // WIN32

} // namespace std
Grayson Lang
  • 156
  • 1
  • 5