I've done a rough conversion and committed it on the branch
https://svn.resiprocate.org/rep/resiprocate/branches/b-pocock-stdint
The test cases run successfully (I only did one test so far,
recompiling everything, I'll get on to some more testing as you
suggest before any merge)
Most of it was done with sed (look at my script in the scripts
directory), but there are three things that need manual attention
- Data has some constructors where I feel we could use the new types
exclusively, I've tweaked it and removed one constructor. I had to
do this anyway as it was giving errors due to the fact that some of
the types were too similar
- rutil/resipfaststreams.hxx needed some tweaking of the snprintf
code. I couldn't get PRIu64 to work universally, so I've just left
it as "%lu" which is not ideal for all platforms.
- we should probably do a hunt through the code for other things
like the unsigned long usage that I recently rectified. This is not
an essential step before the merge but maybe we can improve some
other things.
Any other testing or feedback is welcome of course
On 25/07/13 17:08, Byron Campen wrote:
To maintain source compat, we shouldn't undef the stuff we
have. First, we should ensure that the c++-11 types are defined
one way or another, and then typedef the old resip int types
based on the standard types. Then, begin converting the resip
codebase over to the standard ones entirely (easily scriptable,
and not likely to result in funny stuff like "this std::vector
of conditions" in a license block).
Best regards,
Byron Campen
On Jul 25, 2013 4:21 AM, "Daniel Pocock"
< daniel@xxxxxxxxxxxxx>
wrote:
On 19/07/13 17:14, Byron Campen wrote:
>
> Generally, we use the resip-defined UInt32, but something
that we may
> want to start thinking about is to move over to using the
now standard
> integer types defined in c++-11. Not sure how far back
support for
> these goes; we may need to supply typedefs for them in
some cases, but
> we should start building the good habit now.
>
Using the new types will make it more natural for people new
to the
codebase as well
I'm going to start doing this in trunk today and we simply
need to have
a plan for compatibility before taking it into the release
branch
I would propose that:
- with a C++11 build, we use <cstdint> (#if
__cplusplus >= 201103L)
and define stuff like:
using std::uint8_t;
using std::uint32_t;
because we are not "using namespace std;" in every source
file.
- we fall back to <stdint.h> if possible (#ifdef
HAVE_STDINT_H from
autotools / config.h)
- if that fails, we define the C++11 types ourselves in
rutil/compat.hxx (#ifndef uint32_t) using typedef
Does this seem reasonable and likely to work widely? Have you
seen
alternative approaches or extra things I should add?
|