and greater with the -std=gnu++0x flag
for the compiler. (Note I said should - I haven't tried it.)
I tried it, and it works. I even mentioned it before on this list.
As for C++0x improvements in gtkmm, the following purely practical
things would be nice:
1. Better bindings for GOption, using
, 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
On Wed, 2010-03-31 at 00:02 +0100, Chris Vine wrote:
What could be changed, as Murray already said, are the examples in
the gtkmm-documentation module. It could be worthwhile to see if
the examples could be modified to use these upcoming C++ features.
Provided it does not make the
On Tue, 30 Mar 2010 22:54:26 +0200
Fabien Parent paren...@gmail.com wrote:
__cplusplus is not something new from c++0x, it is already there in c++98.
Here come a quote from the c++ 98 standard paper:
_ _cplusplus The name _ _cplusplus is defined to the value 199711L
when compiling a C++
Hello,
On Wed, 31 Mar 2010 08:27:07 +0200
Murray Cumming murr...@openismus.com wrote:
As soon as g++ supports a finally-standardized C++0x, I would be happy
to use it in examples.
Please keep in mind that explicit mentioning of the actual variable types
in documentation / examples actually
On Wed, 2010-03-31 at 12:59 +0400, Alexander Shaduri wrote:
As soon as g++ supports a finally-standardized C++0x, I would be
happy
to use it in examples.
Please keep in mind that explicit mentioning of the actual variable
types
in documentation / examples actually helped me with my
On Wed, 31 Mar 2010 11:02:42 +0200
Murray Cumming murr...@openismus.com wrote:
I appreciate that, as I once strongly believed in hungarian notation. I
don't any more, though I can't explain why.
I really don't like the hungarian notation. Thinking about this further,
using auto may make people
I appreciate that, as I once strongly believed in hungarian notation. I
don't any more, though I can't explain why.
I really don't like the hungarian notation. Thinking about this further,
using auto may make people use hungarian notation again, because
the type is not so visible
On Wed, Mar 31, 2010 at 11:31 AM, michi7x7 mailing-li...@michi7x7.de wrote:
I really don't like auto. C++ is a type-oriented language, auto will just
cause problems with highlighters and will most of the time just be used to
skip the real type.
Me neither. It seems to me that auto is the sort
Please keep in mind that explicit mentioning of the actual variable types
in documentation / examples actually helped me with my learning process.
Substituting the types with auto may diminish the educational value of
the documentation.
Agreed.
For example,
Gtk::Widget* w = somefunc();
is
Hi,
Am Mittwoch, den 31.03.2010, 12:02 +0200 schrieb Oscar Lazzarino:
On Wed, Mar 31, 2010 at 11:31 AM, michi7x7 mailing-li...@michi7x7.de wrote:
I really don't like auto. C++ is a type-oriented language, auto will just
cause problems with highlighters and will most of the time just be
I had a discussion about this with Daniel once. One of the good uses
of auto would be avoid redundancy.
eg., Glib::RefPtrGtk::IconTheme icon_theme = Gk::IconTheme::get_default();
Here the return type is quite obvious and using auto makes sense to
make the code more readable by avoiding really
Hi,
Am Mittwoch, den 31.03.2010, 12:51 +0200 schrieb michi7x7:
I had a discussion about this with Daniel once. One of the good uses
of auto would be avoid redundancy.
eg., Glib::RefPtrGtk::IconTheme icon_theme =
Gk::IconTheme::get_default();
Here the return type is quite obvious and
Le mer. 31 mars 2010 à 11:31:47 (+0200), michi7x7 a écrit:
I really don't like auto. C++ is a type-oriented language, auto
will just cause problems with highlighters and will most of the time
just be used to skip the real type.
If IDEs cannot handle auto, it would be because they lack the
Le mer. 31 mars 2010 à 12:02:50 (+0200), Oscar Lazzarino a écrit:
It seems to me that auto is the sort of feature that
should be implemented in an IDE, just to make you type faster.
I think it's not only that. It can be useful to declare objects
for which it's hard to know the type without
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::RefPtrThing with auto wherever possible.
Well, that would mainly be relevant for
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::RefPtrThing with
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
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
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
On Tue, 30 Mar 2010 16:19:44 +0200
Murray Cumming murr...@openismus.com wrote:
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::RefPtrThing with auto wherever possible.
You shouldn't need to change
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
Dear all,
I am usually a year behind other people with my software updates. I
suspect there are more people like me, who prefer a working, tried
and tested system over an up-to-date one.
I wouldn't want gtkmm to drop compatibilty with my old gcc just because
there is a newer gcc available
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
for people to
a) Check that gtkmm builds with C++0x.
b) Check that example code works when it uses C++0x features, and check
if that suggests any need for improvements in the gtkmm API.
c) Explore what C++0x features, if any, we might want to use in the API,
which might require dropping support.
--
murr
El Mar 30, 2010, a las 2:37 PM, Chris Vine
ch...@cvine.freeserve.co.uk escribió:
On Tue, 30 Mar 2010 16:19:44 +0200
Murray Cumming murr...@openismus.com wrote:
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
that we would need to drop support.
I'm mostly just asking for people to
a) Check that gtkmm builds with C++0x.
C++0x should be backward compatible with C++98/03.
b) Check that example code works when it uses C++0x features, and check
if that suggests any need for improvements in the gtkmm API
I'm not going to install.
We don't know of any reason that we would need to drop support.
I'm mostly just asking for people to
a) Check that gtkmm builds with C++0x.
C++0x should be backward compatible with C++98/03.
b) Check that example code works when it uses C++0x features
Hi,
Am Dienstag, den 30.03.2010, 20:37 +0200 schrieb Fabien Parent:
For the work to keep two code, i don't think it will increase a lot
the maintenance.
OK, I will repeat myself: I don't see any glaring need to modify our API
to use C++0x features. Most of the C++0x features will work just
On Tue, Mar 30, 2010 at 22:35, Daniel Elstner
daniel.ki...@googlemail.com wrote:
Hi,
Am Dienstag, den 30.03.2010, 20:37 +0200 schrieb Fabien Parent:
For the work to keep two code, i don't think it will increase a lot
the maintenance.
OK, I will repeat myself: I don't see any glaring need
Am Dienstag, den 30.03.2010, 22:54 +0200 schrieb Fabien Parent:
What I said is still true: gcc doesn't follow the c++98 standard
closely. At least in gcc 4.4 shipped in debian sid.
*shrug*
You can bet they will assign some proper value as soon as the need to
differentiate between C++ 98 and
On Tue, 30 Mar 2010 16:01:10 -0400
José Alburquerque jaalburquer...@cox.net wrote:
El Mar 30, 2010, a las 2:37 PM, Chris Vine
ch...@cvine.freeserve.co.uk escribió:
On Tue, 30 Mar 2010 16:19:44 +0200
Murray Cumming murr...@openismus.com wrote:
It would be nice if someone played with
On Wed, 2010-03-31 at 00:02 +0100, Chris Vine wrote:
On Tue, 30 Mar 2010 16:01:10 -0400
José Alburquerque jaalburquer...@cox.net wrote:
What could be changed, as Murray already said, are the examples in
the gtkmm-documentation module. It could be worthwhile to see if
the examples could be
33 matches
Mail list logo
