views:

399

answers:

4

Boost's C99 stdint implementation is awfully handy. One thing bugs me, though. They dump all of their typedefs into the boost namespace. This leaves me with three choices when using this facility:

  1. Use "using namespace boost"
  2. Use "using boost::[u]<type><width>_t"
  3. Explicitly refer to the target type with the boost:: prefix; e.g., boost::uint32_t foo = 0;

  • Option № 1 kind of defeats the point of namespaces. Even if used within local scope (e.g., within a function), things like function arguments still have to be prefixed like option № 3.
  • Option № 2 is better, but there are a bunch of these types, so it can get noisy.
  • Option № 3 adds an extreme level of noise; the boost:: prefix is often ≥ to the length of the type in question.

My question is: What would be the most elegant way to bring all of these types into the global namespace? Should I just write a wrapper around boost/cstdint.hpp that utilizes option № 2 and be done with it?


Also, wrapping the header like so didn't work on VC++ 10 (problems with standard library headers):

namespace Foo
{
  #include <boost/cstdint.hpp>

  namespace boost_alias = boost;
}

using namespace Foo::boost_alias;

EDIT: I guess another option is to use the preprocessor to make it work on VC 10? Taking the snippet above:

#ifndef FOO_HPP_INCLUDED
#define FOO_HPP_INCLUDED

#if _MSC_VER >= 1600 /*VC++ 10*/ || defined USE_NATIVE_STDINT_HEADER
  #include <stdint.h>
#else
  namespace cstdint_wrapper
  {
    #include <boost/cstdint.hpp>

    namespace boost_alias = boost;
  }

  using namespace cstdint_wrapper::boost_alias;
#endif

#endif

Less work, I guess?

+1  A: 

I personally always use option 3. If things are too long, then you can use typedefs to reduce the amount of code.

Billy ONeal
+2  A: 

Your idea of writing a wrapper header that implements option 2 is definitely the better of those three options.

What I'd suggest, though, is a slight variant: Put those using declarations within another namespace, such as cstdint or something; then, you have the option if putting using cstdint; in your own code or explicitly specifying cstdint:: on the particular uses.

Brooks Moses
+5  A: 

I just use C99's stdint.h (it's actually now in VS 2010). For the versions of Visual C/C++ that don't include it, I use a public domain version from MinGW that I modified to work with VC6 (from when I had to work in VC6):

There are a couple other options you might consider in this SO question: http://stackoverflow.com/questions/126279/c99-stdint-h-header-and-ms-visual-studio

If you'd like to continue using boost/cstdint.hpp, I'd say that the suggestion of implementing a wrapper header that brings the types into the global namespace would be the way to go.

Does boost/cstdint.hpp provide anything I should know about that isn't in stdint.h?

Michael Burr
Re: cstdint.hpp vs stdint.h -- I think they only difference is that cstdint.hpp may or may not include the 64-bit types and associated macros because long long is not yet standard. Other than that, I wanted to use boost's version because I already have several boost dependencies in my project. Didn't make sense to distribute an extra header in that case.
patt0h
A: 

If you included directly the file you will be forced to prefix it with std::. So the question is, which option would you take in this case. What would you do with the other types introduced by Boost? Would you prefix them with boost:: or not?

The fist one is clearly a bad option. You can implement option two using your my_cstdint.hpp file

#include <boost/cstdint.hpp>

using boost::uint32_t;
...

and include my_cstdint.hpp in your application. But in my opinion it is a bad idea to add new symbols on the root namespace, you can get more conflicts as the types can be already defined by for example the stdint.h C file.

Even if the third option use a lot of characters, namespaces are there for this purpose. boost::uint32_t will be defined to the correct type depending on your toolset, so just use it, as you would use std::uint32_t.

Vicente Botet Escriba