Am 14.07.2015 um 03:02 schrieb Jeffrey Walton: > Hi Everyone, > > I've avoided or side stepped this issue, but Jonathan Wakely brought > it to light recently after looking at algparam and observing: > > > AssignFromHelperClass binds a > > reference to NULL just to default-construct a temporary of some > type, then > > binds a const-reference to that temporary, then casts away const to > modify > > the value of that temporary. What seems to be a "VC60 workaround" > introduces > > undefined behaviour by trying to be far too clever. > > Jonathan's observations highlight some of the issues with supporting > older platforms and gear. The older gear includes compilers like > Microsoft's embedded eVC 4.0 compiler, and older IDEs like a 1990's > era Code Warrior. I think the support was cutting edge back then, but > its a hindrance or a detriment today. > > My QUESTIONS are: > > (1) Where can we reasonably draw a line? I think we may want to handle this as Microsoft used to do: 10 years support. We publish a final version which still supports the compiler (-> next one should still support at least VS 2005), tell people we'll remove that support with next patch and that's it. > (2) How should we proceed moving forward? 10 years support. If we have a workaround for anything 10 years or more older we'll deprecate it and drop it with next release (f.ex. keep everything for 5.7.0 and drop with 5.8.0 / 5.7.1 so everyone has a few months / years to prepare) > (3) And how can we test that we are proceeding as agreed? Maybe look for the relevant macros? (GNUC_MAJOR, GNUC_MINOR, MSC_VER, ...) > > My personal feelings lie somewhere around: > > * Circa 2000's compilers and IDEs <2005, drop it. > * C++03 support 2005 and newer compiler still rely on this -> can't drop > * GCC 4.2.1 due to OpenBSD July 2007, still within 10 years time-frame > > Note that the above does not say "No, we don't support C++11". We just > have to maintain sources that are compatible with the project's goals > and objectives. I've already started exploring this issue at "How to > guard move constructors for C++03 and C++11?", > http://stackoverflow.com/q/30797388. > > Once we classify an item (like, say GCC 2.9 or 3.x; or Visual Studio > 5.0 project files), what do we do with them. So my QUESTION here is: > > (4) What do we do with obsolete gear once we agree something is > obsolete? deprecate it once it hits our EOL (10 years) -> compiler warning? After this either
1. Remove it 2. #if 0 it I'd prefer (1) as it's more like OpenBSD did with LibreSSL and we don't actually need this code if we don't advertise the support but there may be good reasons for (2). I hope I understood everything correctly :) BR JPM > > Jeff > -- > -- > You received this message because you are subscribed to the "Crypto++ > Users" Google Group. > To unsubscribe, send an email to > [email protected]. > More information about Crypto++ and this group is available at > http://www.cryptopp.com. > --- > You received this message because you are subscribed to the Google > Groups "Crypto++ Users" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout. -- -- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com. --- You received this message because you are subscribed to the Google Groups "Crypto++ Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
