Its going to be quite a while before 0x is adopted into all the tools we
all care about. Even so, it offers some pretty attractive features. I'll be
sand boxing a lot of code to play with it.
On Mar 30, 2010 12:36pm, michi7x7 <[email protected]> wrote:
Probably because gcc hasn't already included the full standard? Because
of this, programs which used it would not work properly.
GCC will include it, when the Standard is (nearly) completely supported.
I guess what I'm asking is how big a deal is it if gtkmm dropped c++98
support when c++0x comes out? Could we do it at gtkmm 3.0? Do the times
line fit?
The issue is gtkmm 3.0 will probably be released in the same time as
gtk 3.0 (in almost 6 months). But if we break the ABI/API we have to
wait than all officially supported compilers implement fully c++0x.
But this won't happen in the next 6 months, so we can't use c++0x in
gtkmm 3.0.
I think my solution is good because we can use the standard we want.
And when the time will be right (gtkmm 4 ?), we will be able to remove
the old c++98 code easily.
For the work to keep two code, i don't think it will increase a lot
the maintenance.
There is a standard way to do that once the standard is out, which is to
check the numeric value of the __cplusplus macro.
In fact, gcc doesn't define the value of the macro, so it get the
default value of 1.
If gcc was following the standard it would be possible to write this:
#if __cplusplus> 199711L
// c++0x
#else
// c++98
#endif
But it's not. I hope others compilers follow the standard more closer.
------------
Fabien Parent
On Tue, Mar 30, 2010 at 19:50, Jim [email protected]> wrote:
Not that my opinion matters very much because I haven't contributed any
code to the core of gtkmm, but I agree with Chris on his point here. I
think that gtkmm should move to c++0x fully when it comes out and should
drop the c++98 support. It will get very confusing to have things start
to mix otherwise.
Jim
On Mar 30, 2010, at 1:36 PM, Christopher Harvey wrote:
The way I understand it, when c++0x comes application developers will
want to use it. If gtkmm doesn't support the new standard then there will
be an odd mix of shared_ptrs and auto's for example. Is c++0x even
backward compatible with 98? I'm not a gtkmm developer but it sounds like
Fabien's idea below would mean writing and maintaining 2 version of gtkmm
in the same file. I guess what I'm asking is how big a deal is it if
gtkmm dropped c++98 support when c++0x comes out? Could we do it at gtkmm
3.0? Do the times line fit?
Fabien Parent wrote:
Hi,
It would be great to see gtkmm start using some c++0x features. I
think the best would be to keep compatibility with c++ 98 like boost
did.
We can find if the user is using c++98 or c++0x by looking if the
macro __GXX_EXPERIMENTAL_CXX0X__ has been defined by the gcc's
preprocessor.
For example:
#if defined(__GXX_EXPERIMENTAL_CXX0X__)
// c++0x
#else
// c++98
#endif
Fabien Parent
On Tue, Mar 30, 2010 at 16:58, Murray [email protected]> wrote:
On Tue, 2010-03-30 at 16:48 +0200, Daniel Elstner wrote:
Hi,
Am Dienstag, den 30.03.2010, 16:19 +0200 schrieb Murray Cumming:
It would be nice if someone played with using these new features in
gtkmm. For intsance, create a git branch and try to replace use of
Glib::RefPtr with auto wherever possible.
Well, that would mainly be relevant for code using the gtkmm API. Ie
our examples and stuff.
Yes, we have lots of code in gtkmm-documentation/examples (make check,
to build it) that should be branched to try stuff.
For the time being I see no compelling reason to break compatibility
with C++ 98 in the library code itself. However, I'm going to adopt
C++0x in my application code as soon as it can reasonably be done.
--
[email protected]
www.murrayc.com
www.openismus.com
_______________________________________________
gtkmm-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gtkmm-list
_______________________________________________
gtkmm-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gtkmm-list
_______________________________________________
gtkmm-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gtkmm-list
_______________________________________________
gtkmm-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gtkmm-list
_______________________________________________
gtkmm-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gtkmm-list
_______________________________________________
gtkmm-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gtkmm-list
_______________________________________________
gtkmm-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gtkmm-list
