On 09/01/2012 00:13, Rui Maciel wrote: > On 01/08/2012 03:30 PM, Murray Cumming wrote: >> And I guess that it's onsidered acceptable to use -std=c++0x with a >> library that was not compiled with that option? Then, yes, that does >> mean that a configure check won't be enough. >> >> Maybe we can just put this in a separate header that people must >> explicitly include if they need it? >> >> However, it would still need a configure check, just so we can have a >> test for it when appropriate. > > Here is a mad idea: what about creating a v3.0 branch, with the purpose of > providing a libsigc++ version which extensively relied on C++11 features? > > Among the advantages, this would prevent any software package which currently > relies on the v2 branch from breaking. > > It would also be simpler to add support for C++11 in libsigc++, both in terms of > backward compatibility and convoluted configure/compiler checks. After all, a > programmer would only use the v3.0 branch if he intentionally required C++11 > features, which he would be forced to check prior to using libsigc++. > > Then, if a particular compiler failed to support libsigc++ v3 then either the > onus to fix any problem would be on the compiler developer or the developer > would be compelled to upgrade/switch to a compiler which actually supported C++11. Given the lack of guaranteed ABI compatibility between C++98 and C++11, I think this would be a great idea, actually. And it would reduce the code base and perhaps compilation time significantly, considering that most (if not all) of the type_trait stuff is now implemented in libstdc++. It would be good to do something like that for gtkmm as well. -- Kind regards, Loong Jin
Attachment:
signature.asc
Description: OpenPGP digital signature