(WIP) Small fixes and improvements - #108

g++ supports nullptr before change __cplusplus to 201103 in 4.6, will fix it

EDIT: We have other feature-testing macros using __cplusplus

# define FMT_USE_VARIADIC_TEMPLATES \
   (FMT_HAS_FEATURE(cxx_variadic_templates) || \
       (FMT_GCC_VERSION >= 404 && __cplusplus >= 201103L) || _MSC_VER >= 1800)

Which won't work for g++4.6 and below

Thanks for your interest in C++ Format and a huge contribution.

A few comments:

1. New BufferedFile methods overall look good, but

   • I'd rename write_raw to write. The idea is to mostly follow the naming of the underlying methods, fwrite in this cases.

   • The following checks shouldn't be there, because calling a method on a closed file should fail in one way or another, not silently do nothing:

     if (!file_)
       return;

2. FMT_NOEXCEPT without an argument: great idea, can merge it any time (if you submit it in a separate PR).
3. nullptr: I'm afraid this change can't go in, because the library shouldn't define any unprefixed macro to avoid potential conflicts and warnings in the client code (however unlikely they are). It is possible to use FMT_NULLPTR instead, but it's probably make the code to ugly and not worth it. So I suggest keeping 0 for now. I have plans to write a small program that will do automatic translation of some C++11 constructs into C++98 that will address this issue.

In general, it would be nice to split it in several PRs if it is not too difficult. As I said the FMT_NOEXCEPT can go in right now and BufferedFile methods with only minor modifications.

Cheers!

Thanks for your reply.

1. I'd rename write_raw to write. The idea is to mostly follow the naming of the underlying methods, fwrite in this cases.
   • Have thought before. Concern: we already have fmt::MemoryWriter::write, which looks like fmt::BufferedFile::write. But they have different behavior: It's ok to say somefile.write("{}{}{}"), but you will get a fmt::FormatError exception when you run the same code for MemoryWriter
2. The following checks shouldn't be there, because calling a method on a closed file should fail in one way or another, not silently do nothing
   • I agree. Will throw an exception.
3. nullptr: I'm afraid this change can't go in
   • Well, nullptr is one of the cleanest feature in C++11 in my opinion. Too bad we can't use it for supporting ancient compilers. Ok I'll revert the change by some simple %s/nullptr/0/g

As there are some FIXMEs left, I don't expect a quick merge. Other comments are welcomed.

Will split this into several smaller PRs, closing