Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Migration? I thought WG21 fought hard to preserve all the compatibility. Unless you used export you do not need migration, existing code is fine. </p> <p>I guess you really meant the question for refactoring the existing code to pick up C++11 features. Here I'd apply the general wisdom about refactoring -- never do it without a proper goal and value-based motivation. </p> <p>Just that new shiny features got introduced does not impose technological debt on your code. </p> <p>I suggest you start using new features in new code, and apply more liberal changes it where you refactor for different reasons anyway. And start thinking in general reshape only when having multiple styles is considered a real pain. (The multi-paradigm nature of C++ normally should allow quite much freedom, and force uniform approach only occasionally.)</p> <p>From the new features what I'd focus on:</p> <ul> <li>auto. All my new code is full of <code>auto const</code> and <code>auto const&amp;</code> locals omitting the types. Ok, one suggested globalreplace contradicting what I said previously: replace ::iterator usage by auto if you have for loops using them.</li> <li>lambdas, if you use algos with one-shot functions</li> <li>the new threading stuff, especially <code>std::future</code> if applies to the project</li> </ul> <p>If you happen to use 'std::auto_ptr' probably a good candidate for globalreplace too.</p> <p>I left out move semantics because I'm yet to jump on them, not sure of the impact, so I leave it for others to suggest or not.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    1. CO"*I thought WG21 fought hard to preserve all the compatibility*" -- sure, but some compilers are slowly enforcing conformance -- and this is a good time for them to improve their conformance and force us to update our programs. also, there are some breaking changes where conforming programs will produce errors when compiled using std.C++11 (narrowing conversions are one example).
      singulars
    2. CO@justin: I just re-read that C.2 section and concluded again, that if any of the changes manifest on my codebase it already has an latent bug at the spot. (IUC the narrowing conversion change applies only to brace-init, where I expect matching types.) My extrapolation from that is the migration should not be an effort worth mentioning compared to usual problems real life throws at us. But I won't debate anyone's different experience or opinion. It would be interesting to collect real-life stories.
      singulars
    3. COsee Ali's link for a more complete list of breaking changes. i just didn't agree that the obscure `export` was the only real concern. over here, i estimate it took about one hour per 50,000 physical lines of code to add support for c++11 on one compiler and a c++11 compatible std library to the point where it builds and links OK. following libs/compilers go faster. poorly maintained codebases and projects slower. testing omitted. that adoption phase would probably cost most teams a few dedicated days -- weeks at most, and hours on the low end. (cont)
      singulars
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload