| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
Should add, before doing this, do the whole build with dyn linking, back every executable up, make the changes and make sure the backed up executables still work on the new libs. Might also make sense to convert everything but the tests and make sure that you still have source compat, and if everything checks out, finish the conversion.
Best
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 CampenOn 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?