Borland support about to be removed and C++0x plans
Neil Hodgson
Borland C++ compiler from my working tree. This will be committed
tomorrow. This is the last opportunity for anyone that wants to
continue using Borland C++ to speak up. The free Borland command line
compiler was last updated around 10 years ago and has required some
awkward work-arounds.
The win32 make files were simplified by this removal and were
changed to use batch rules (for a 25% speed up) and build a library of
lexers, Lexers.lib, when using MSVC which simplifies building Sc1.exe.
g++ 4.5 and Microsoft Visual C++ 2010 both support a reasonable
amount of the coming C++0x standard and I intend to start using C++0x
features relatively soon, probably after releasing Scintilla 2.23. On
the Macintosh, the version of g++ appears to be quite old so no C++0x
features will be used in Macintosh-specific code or in cross-platform
Scintilla code. Since long term support platforms like Red Hat
Enterprise Linux will still be using older versions of g++, users on
these platforms will have to either stick with older versions of
Scintilla/SciTE or install newer compilers.
Compiler support for C++0x:
http://wiki.apache.org/stdcxx/C++0xCompilerSupport
Neil
Nick Treleaven
Neil Hodgson <nyama...@gmail.com> wrote:
> g++ 4.5 and Microsoft Visual C++ 2010 both support a reasonable
> amount of the coming C++0x standard and I intend to start using C++0x
> features relatively soon, probably after releasing Scintilla 2.23. On
> the Macintosh, the version of g++ appears to be quite old so no C++0x
> features will be used in Macintosh-specific code or in cross-platform
> Scintilla code. Since long term support platforms like Red Hat
> Enterprise Linux will still be using older versions of g++, users on
> these platforms will have to either stick with older versions of
> Scintilla/SciTE or install newer compilers.
Obviously it's your decision, but I would strongly prefer you didn't do
that. Wouldn't this mean that users that don't want the hassle of
upgrading their systems regularly don't get Scintilla bug fixes?
If C++0x is going to help Scintilla development significantly, perhaps
you might consider maintaining a bugfix branch of Scintilla that
doesn't require it? That would be much appreciated.
Just as a note, I'm one of the maintainers of Geany, which still builds
with GTK 2.8. It wouldn't be good to impose the requirement of any C++0x
support.
Finally, I hope this doesn't sound like moaning. I and Geany users are
very grateful for the Scintilla project.
Thanks,
Nick
Philippe Lhoste
>> the coming C++0x standard and I intend to start using C++0x
>> features relatively soon
I haven't followed this C++0x, is there a clear, official reference on it?
BTW, C++ name was funny, but non practical for search purposes (although
I suppose Google and others improved on it).
But I find the C++0x name positively ugly... Why not @#!%$ it would make
a better approximation of comic's swearing... ;-)
--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --
Lex Trotman
> On 11/11/2010 16:06, Nick Treleaven wrote:
>>>
>>> the coming C++0x standard and I intend to start using C++0x
>>> features relatively soon
>
> I haven't followed this C++0x, is there a clear, official reference on it?
@Philippe
By Stroustrup
http://www2.research.att.com/~bs/C++0xFAQ.html
>
> BTW, C++ name was funny, but non practical for search purposes (although I
> suppose Google and others improved on it).
> But I find the C++0x name positively ugly... Why not @#!%$ it would make a
> better approximation of comic's swearing... ;-)
>
Funny, I thought that was Perl code :-)
@Neil,
Can I suggest that you do what I do, use the C++0x features via Boost
which provides them on many older compilers and uses the Gcc and ms
builtins where available. After all c++0x isn't a standard yet,
although Stroustrup, the eternal optimist thinks c++11. When support
is widespread you can easily change from boost:: to std::.
Cheers
Lex
> --
> Philippe Lhoste
> -- (near) Paris -- France
> -- http://Phi.Lho.free.fr
> -- -- -- -- -- -- -- -- -- -- -- -- -- --
>
> --
> You received this message because you are subscribed to the Google Groups
> "scintilla-interest" group.
> To post to this group, send email to scintilla...@googlegroups.com.
> To unsubscribe from this group, send email to
> scintilla-inter...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/scintilla-interest?hl=en.
>
>
Neil Hodgson
> Obviously it's your decision, but I would strongly prefer you didn't do
> that. Wouldn't this mean that users that don't want the hassle of
> upgrading their systems regularly don't get Scintilla bug fixes?
Only people that build Scintilla need to have a current C++
compiler installed. Pre-built binaries which I expect to be the normal
mode for Geany will be fine.
> If C++0x is going to help Scintilla development significantly, perhaps
> you might consider maintaining a bugfix branch of Scintilla that
> doesn't require it? That would be much appreciated.
If someone wants to continue a maintenance branch of Scintilla at
any point then that would be cool. I have found with SciTE on Windows
dropping support for old versions however, that there are few people
interested in running a maintenance branch.
> Just as a note, I'm one of the maintainers of Geany, which still builds
> with GTK 2.8. It wouldn't be good to impose the requirement of any C++0x
> support.
GTK+ is a C API and the version of GTK+ supported is not dependent
on the C++ compiler.
Neil
Neil Hodgson
> Can I suggest that you do what I do, use the C++0x features via Boost
> which provides them on many older compilers and uses the Gcc and ms
> builtins where available.
Boost is an enormous dependency and required much installation
effort when I used to use it for SinkWorld.
> After all c++0x isn't a standard yet,
> although Stroustrup, the eternal optimist thinks c++11. When support
> is widespread you can easily change from boost:: to std::.
The C++0x language is already quite well defined so compilers have
implemented much of it but the standard needs to go through a bit more
process before being published. g++ 4.5 is now the version included in
current Linux distributions and with Mingw for Windows which appears
widely available enough for me.
Neil
Lex Trotman
> Lex Trotman:
>
>> Can I suggest that you do what I do, use the C++0x features via Boost
>> which provides them on many older compilers and uses the Gcc and ms
>> builtins where available.
>
> Boost is an enormous dependency and required much installation
> effort when I used to use it for SinkWorld.
Yes, its a pity its so monolithic
.
Well, either there is a package for the platform or it isn't any worse
than having to upgrade a C++ compiler without package support :-)
Last time I tried to update GCC without a package I gave up and ended
up upgrading the whole OS because it was so hard, there are so many
flow on effects :-(
>
>> After all c++0x isn't a standard yet,
>> although Stroustrup, the eternal optimist thinks c++11. When support
>> is widespread you can easily change from boost:: to std::.
>
> The C++0x language is already quite well defined so compilers have
> implemented much of it but the standard needs to go through a bit more
> process before being published. g++ 4.5 is now the version included in
> current Linux distributions and with Mingw for Windows which appears
> widely available enough for me.
I think Nicks problem is with the need to upgrade older oses (eg old
RHEL systems, many of which are still in use) with current compilers,
its not easy.
Then you don't know what other compiles will break due to the new compiler.
Cheers
Lex
>
> Neil
Neil Hodgson
> I think Nicks problem is with the need to upgrade older oses (eg old
> RHEL systems, many of which are still in use) with current compilers,
> its not easy.
The last RHEL release cycle took 3 years and 8 months (RHEL 5 was
March 2007) and the new RHEL 6 includes g++ 4.4 which is 1 year 7
months old. AFAICT reading release notes all RHEL 5.x releases used
gcc 4.1. If this continues (and RHEL is slowing down, not speeding up)
then there could be a wait of over 5 years between new features
becoming available in g++ and being available in RHEL. This is *far*
too long.
Neil
Jason Haslam
>> The C++0x language is already quite well defined so compilers have
>> implemented much of it but the standard needs to go through a bit more
>> process before being published. g++ 4.5 is now the version included in
>> current Linux distributions and with Mingw for Windows which appears
>> widely available enough for me.
>
> I think Nicks problem is with the need to upgrade older oses (eg old
> RHEL systems, many of which are still in use) with current compilers,
> its not easy.
>
> Then you don't know what other compiles will break due to the new compiler.
Just to throw in my 2 cents, this is the situation we're in. We're forced to deploy on Solaris 8. If Scintilla begins to use constructs that aren't supported by the current compiler (gcc 3.4.6) then we'd be more likely to stop updating Scintilla than to try to install a modern compiler.
I'm not saying that this is good reason to not move forward with C++0x, it's not, but it's definitely going to prevent us from upgrading in the near term.
Jason
Lex Trotman
Depends on your point of view. If you don't have the resources to
upgrade then its too short.
I can see both points of view, I'm trying to see how they can be
reconciled, even if only for a while.
Neil wants to use new features to make his job easier/possible
providing great new Scintilla features that we all want. Users want
to keep their existing systems because it makes their job
easier/possible.
Whilst I understand Neils desire not to have a dependency on boost,
I've never actually found it to be a limitation, and I only use binary
packages.
Otherwise, since the existing software is working without c++ox can
its use be initially confined to new features that can be #ifdefed out
if c++ox isn't available? Probably easiest if the C++0x is in
separate files and they only get used if its available.
Old users may not get new features, but they get bugfixes in existing
functionality for a while.
Nick Treleaven
Neil Hodgson <nyama...@gmail.com> wrote:
> Nick Treleaven:
>
> > Obviously it's your decision, but I would strongly prefer you didn't do
> > that. Wouldn't this mean that users that don't want the hassle of
> > upgrading their systems regularly don't get Scintilla bug fixes?
>
> Only people that build Scintilla need to have a current C++
> compiler installed. Pre-built binaries which I expect to be the normal
> mode for Geany will be fine.
The problem is that many distros only provide new packages for Geany
for the latest release (which is understandable). Many users often stay
on older distros, and some of them build the latest Geany from source
because its requirements still allow this.
I realise that if users don't upgrade their systems they can't expect
to be able to get the latest features of apps, but this is now
something Scintilla would be imposing, rather than the apps
imposing stricter requirements. (Assuming no bugfix branch of
Scintilla and the apps upgrade their Scintilla).
I don't know, but perhaps there is a static binary of g++ 4.5 that will
work on older systems, and perhaps it's not hard to install in parallel
with the system g++. But it would still be an extra hurdle people who
build apps that use the latest Scintilla would have to jump through,
which may be off-putting.
> > If C++0x is going to help Scintilla development significantly, perhaps
> > you might consider maintaining a bugfix branch of Scintilla that
> > doesn't require it? That would be much appreciated.
>
> If someone wants to continue a maintenance branch of Scintilla at
> any point then that would be cool. I have found with SciTE on Windows
> dropping support for old versions however, that there are few people
> interested in running a maintenance branch.
Ok.
> > Just as a note, I'm one of the maintainers of Geany, which still builds
> > with GTK 2.8. It wouldn't be good to impose the requirement of any C++0x
> > support.
>
> GTK+ is a C API and the version of GTK+ supported is not dependent
> on the C++ compiler.
I know, my point was just that Geany's requirements have been kept low
to allow users to continue building on older systems.
Nick
Neil Hodgson
> Otherwise, since the existing software is working without c++ox can
> its use be initially confined to new features that can be #ifdefed out
> if c++ox isn't available? Probably easiest if the C++0x is in
> separate files and they only get used if its available.
I see the C++0x features as ways to simplify existing and new code
so would be pervasive and not easily isolated. The biggest feature to
me is lambdas which can't really be added by a library although some
ugly attempts have been published like
http://cpp-next.com/archive/2010/10/expressive-c-expression-extension-part-two/
In current C++, library algorithms like find_if and for_each are
clumsy to use as you need to define a functor for any complex
expression. Because of this, there is only one use of find_if in
Scintilla/SciTE and really, it would be clearer as an explicit loop.
Another place where I'd like to use lambdas is for GTK+ event handling
where there were originally often two functions defined to handle an
event: a static method that looks like C to have the correct signature
which thunks to an instance method which does the work. This has been
simplified a little by some thunk templates but I'd much prefer to
define the behaviour inline for simple cases.
For example some old code was (simplifying):
// in SciTEGTK:
void FindInFilesDotDot() {
FilePath findInDir(gtk_entry_get_text(GTK_ENTRY(GTK_COMBO(comboDir)->entry)));
gtk_entry_set_text(GTK_ENTRY(GTK_COMBO(comboDir)->entry),
findInDir.Directory().AsInternal());
}
static void DotDotSignal(GtkWidget */*w*/, SciTEGTK *scitew) {
scitew->FindInFilesDotDot();
}
...
gtk_signal_connect(GTK_OBJECT(btnDotDot), "clicked",
GtkSignalFunc(DotDotSignal), this);
With the Signal thunk this is now:
void SciTEGTK::FindInFilesDotDot() {
FilePath findInDir(gtk_entry_get_text(GTK_ENTRY(GTK_COMBO(comboDir)->entry)));
gtk_entry_set_text(GTK_ENTRY(GTK_COMBO(comboDir)->entry),
findInDir.Directory().AsInternal());
}
Signal<&SciTEGTK::FindInFilesDotDot> sigDotDot;
dlgFindInFiles.btnDotDot.Create(localiser.Text("_.."),
G_CALLBACK(sigDotDot.Function), this);
With lambdas it may be possible to reduce this to:
btnDotDot.Create(localiser.Text("_.."), [&]() {
FilePath findInDir(gtk_entry_get_text(GTK_ENTRY(GTK_COMBO(comboDir)->entry)));
gtk_entry_set_text(GTK_ENTRY(GTK_COMBO(comboDir)->entry),
findInDir.Directory().AsInternal());
});
Neil
Neil Hodgson
> I realise that if users don't upgrade their systems they can't expect
> to be able to get the latest features of apps, but this is now
> something Scintilla would be imposing, rather than the apps
> imposing stricter requirements. (Assuming no bugfix branch of
> Scintilla and the apps upgrade their Scintilla).
If there is sufficient benefit in a maintenance branch then the
people that experience this benefit should be prepared to pay for it
either in effort or money. For me, running a maintenance branch would
be a chore so I would only do this if I could make money on it at
commercial rates.
> I don't know, but perhaps there is a static binary of g++ 4.5 that will
> work on older systems, and perhaps it's not hard to install in parallel
> with the system g++.
There's also clang which doesn't yet have much C++0x support but is
moving quite rapidly.
Neil
Lex Trotman
> Lex Trotman:
>
>> Otherwise, since the existing software is working without c++ox can
>> its use be initially confined to new features that can be #ifdefed out
>> if c++ox isn't available? Probably easiest if the C++0x is in
>> separate files and they only get used if its available.
>
> I see the C++0x features as ways to simplify existing and new code
> so would be pervasive and not easily isolated.
Oh well, it was only a suggestion, if you are going to be rewriting
existing code then it doesn't work.
The biggest feature to
> me is lambdas
Yeah neat.
which can't really be added by a library although some
> ugly attempts have been published like
> http://cpp-next.com/archive/2010/10/expressive-c-expression-extension-part-two/
>
> In current C++, library algorithms like find_if and for_each are
> clumsy to use as you need to define a functor for any complex
> expression. Because of this, there is only one use of find_if in
> Scintilla/SciTE and really, it would be clearer as an explicit loop.
> Another place where I'd like to use lambdas is for GTK+ event handling
> where there were originally often two functions defined to handle an
> event: a static method that looks like C to have the correct signature
> which thunks to an instance method which does the work. This has been
> simplified a little by some thunk templates but I'd much prefer to
> define the behaviour inline for simple cases.
Yep.
BTW is there a reason why you don't use gtkmm for the GTK backend, it
(or at least libsigc++) can call static, virtual and ordinary member
functions? And makes widget subclassing a breeze.
But lambdas is nicer.
Thanks for the explanation Neil, see where you are coming from.
Neil Hodgson
> BTW is there a reason why you don't use gtkmm for the GTK backend, it
> (or at least libsigc++) can call static, virtual and ordinary member
> functions? And makes widget subclassing a breeze.
Initially, I was concerned about whether gtk-- would last. There
was some hostility to C++ in the GTK+ world back then. Language
binding projects are often straight-forward and boring as it can be
just a matter of applying simple rules to many cases. Another issue
was whether it would stay updated to match GTK+ or would lag but it
appears to have a good record there.
Later, it became difficult to make major changes to the code and I
don't know if gtkmm can be easily introduced incrementally. I've
looked into libsigc++ a couple of times and walked away although its a
bit fuzzy. It may have been that gtkmm implemented the easy mappings
of GTK+ signals and it does so within its own way of working whereas
libsigc++ was only providing the basic functionality. So there'd have
to be a glue layer, perhaps copied from gtkmm. Its just not easy to
see how much work there would be.
Neil
Lex Trotman
> Lex Trotman:
>
>> BTW is there a reason why you don't use gtkmm for the GTK backend, it
>> (or at least libsigc++) can call static, virtual and ordinary member
>> functions? And makes widget subclassing a breeze.
>
> Initially, I was concerned about whether gtk-- would last. There
> was some hostility to C++ in the GTK+ world back then. Language
> binding projects are often straight-forward and boring as it can be
> just a matter of applying simple rules to many cases. Another issue
> was whether it would stay updated to match GTK+ or would lag but it
> appears to have a good record there.
Understand
>
> Later, it became difficult to make major changes to the code and I
> don't know if gtkmm can be easily introduced incrementally.
I think you are right, it would be quite difficult to mix.
I've
> looked into libsigc++ a couple of times and walked away although its a
> bit fuzzy. It may have been that gtkmm implemented the easy mappings
> of GTK+ signals and it does so within its own way of working whereas
> libsigc++ was only providing the basic functionality. So there'd have
> to be a glue layer, perhaps copied from gtkmm. Its just not easy to
> see how much work there would be.
Ok, I've never used it separately from gtkmm so I can't comment.