Hi All, Just wanted to let everyone know that we’ve been talking about requiring C++11 going forward and to open it up to discussion. New and old, feel free to chime in.
In general, C++11 has very compelling features (e.g., threading, auto) that cannot be toggled on/off in code or otherwise handled conditionally. As far as I know and have tested, every platform we actively support also supports C++11. We’ve actually been optionally using it in BRL-CAD’s code ever since the fast heap allocator was implemented as that utilizes thread_local for keeping track of IDs. Requiring it doesn’t necessarily mean we’re going to suddenly convert all of our code and APIs to C++ as that would make for crappy C and crappy C++ in the long interim... What it could mean, though, is that using C++11 is fine 1) in any front-end application code, 2) in any new library designed as a C++ library, or 3) in library code as hidden implementation detail (e.g., pimpl pattern) without preprocessor accommodations. That approach will support incremental usage and adoption without egregiously breaking things in the meantime and keeping our C APIs simple. With ray tracing performance a priority, one of the places where C++11 may get put to immediate use is in libbu’s backend implementation, containers like ptbl in particular as it profiles hot. Another is bu_lists as they block automatic vectorization. Figuring out what to do there is a little bit a challenge, so thoughts appreciated. Cheers! Sean ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
