Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Nick Treleaven]

On 05/09/2013 10:48, Matthew Brush wrote:

On 13-09-05 02:26 AM, Nick Treleaven wrote:

On 01/09/2013 02:36, Matthew Brush wrote:

On 13-08-29 05:08 AM, Nick Treleaven wrote:

On 29/08/2013 02:39, Matthew Brush wrote:

[...]



If we were to use C++, I think it'd be pointless to limit it to
CFront/CwithClasses-style 1980's C++. We should use common/standard
stuff like standard library containers, inheritance (maybe not
multipl-inheritance), the class keyword, templates (where it makes
sense), exceptions, etc. The issues/limits being discussed in this
thread are issues long since considered "resolved" or "non-issues"
for a
long time for desktop software (and since a *long* time even before
Geany's first line of code was written :). The style of code I read on
the net and in talks and books and stuff is modern (ie. >= C++98)
style
C++ and I'd expect that's what the bulk of C++-using contributors
would
be used to using.


Idiomatic C++ takes a *lot* of learning and experience to get right for
someone coming from C.



Do you think there's more C-only programmers out there contributing to
desktop application projects than C++ programmers? I honestly don't know
but my instinct says there isn't.


If you mean open source projects, then yes. Somewhat difficult to
measure, but some (possibly flawed) stats:

Here C has at least twice the share of C++:
http://lang-index.sourceforge.net/

In terms of noise on the web, here C also has approaching twice that of
C++:
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html



It would be better (but even harder to measure) to compare desktop
applications, as I mentioned, like Geany since this is an area where C++
makes a lot of more sense compared to C, and there's a lot of excellent
C++ GUI toolkits like Qt, WxWidgets, FLTK, FOX, GTKmm, WTL, etc.
Compared to C, where GTK+ is about the only actually good toolkit I've
ever come across.


You don't need to be a GUI programmer to make good contributions to Geany.


Also even if there were more C++ programmers, it would still be much
easier for a C++ programmer to write C than vice versa.



Yeah maybe, although if you learned C++ first, using C is fairly foreign
and weird I'm sure. Also all of the other languages that support
modern/more programming paradigms would probably make an easier
transition to C++ than C.


The STL is almost unique. Only D has something similar. Also C++-style 
RAII is not commonly found in popular languages.

___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Matthew Brush]

On 13-09-05 02:26 AM, Nick Treleaven wrote:

On 01/09/2013 02:36, Matthew Brush wrote:

On 13-08-29 05:08 AM, Nick Treleaven wrote:

On 29/08/2013 02:39, Matthew Brush wrote:

[...]



If we were to use C++, I think it'd be pointless to limit it to
CFront/CwithClasses-style 1980's C++. We should use common/standard
stuff like standard library containers, inheritance (maybe not
multipl-inheritance), the class keyword, templates (where it makes
sense), exceptions, etc. The issues/limits being discussed in this
thread are issues long since considered "resolved" or "non-issues"
for a
long time for desktop software (and since a *long* time even before
Geany's first line of code was written :). The style of code I read on
the net and in talks and books and stuff is modern (ie. >= C++98) style
C++ and I'd expect that's what the bulk of C++-using contributors would
be used to using.


Idiomatic C++ takes a *lot* of learning and experience to get right for
someone coming from C.



Do you think there's more C-only programmers out there contributing to
desktop application projects than C++ programmers? I honestly don't know
but my instinct says there isn't.


If you mean open source projects, then yes. Somewhat difficult to
measure, but some (possibly flawed) stats:

Here C has at least twice the share of C++:
http://lang-index.sourceforge.net/

In terms of noise on the web, here C also has approaching twice that of
C++:
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html



It would be better (but even harder to measure) to compare desktop 
applications, as I mentioned, like Geany since this is an area where C++ 
makes a lot of more sense compared to C, and there's a lot of excellent 
C++ GUI toolkits like Qt, WxWidgets, FLTK, FOX, GTKmm, WTL, etc. 
Compared to C, where GTK+ is about the only actually good toolkit I've 
ever come across.



Also even if there were more C++ programmers, it would still be much
easier for a C++ programmer to write C than vice versa.



Yeah maybe, although if you learned C++ first, using C is fairly foreign 
and weird I'm sure. Also all of the other languages that support 
modern/more programming paradigms would probably make an easier 
transition to C++ than C.


Cheers,
Matthew Brush
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Nick Treleaven]

On 05/09/2013 10:26, Nick Treleaven wrote:

Also even if there were more C++ programmers, it would still be much
easier for a C++ programmer to write C than vice versa.


Here I meant *idiomatic* (STL-heavy) C++. Some features e.g. references 
are well known to programmers of other languages and IMO simple to learn 
and understand. I think using a dynamic string type is also well 
understood by modern programmers. Even if we just used those two things, 
I think it would be worth starting to use some C++.

___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Nick Treleaven]

On 01/09/2013 02:36, Matthew Brush wrote:

On 13-08-29 05:08 AM, Nick Treleaven wrote:

On 29/08/2013 02:39, Matthew Brush wrote:

[...]



If we were to use C++, I think it'd be pointless to limit it to
CFront/CwithClasses-style 1980's C++. We should use common/standard
stuff like standard library containers, inheritance (maybe not
multipl-inheritance), the class keyword, templates (where it makes
sense), exceptions, etc. The issues/limits being discussed in this
thread are issues long since considered "resolved" or "non-issues" for a
long time for desktop software (and since a *long* time even before
Geany's first line of code was written :). The style of code I read on
the net and in talks and books and stuff is modern (ie. >= C++98) style
C++ and I'd expect that's what the bulk of C++-using contributors would
be used to using.


Idiomatic C++ takes a *lot* of learning and experience to get right for
someone coming from C.



Do you think there's more C-only programmers out there contributing to
desktop application projects than C++ programmers? I honestly don't know
but my instinct says there isn't.


If you mean open source projects, then yes. Somewhat difficult to 
measure, but some (possibly flawed) stats:


Here C has at least twice the share of C++:
http://lang-index.sourceforge.net/

In terms of noise on the web, here C also has approaching twice that of C++:
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

Also even if there were more C++ programmers, it would still be much 
easier for a C++ programmer to write C than vice versa.


P.S. Sorry for the late replies, also to Lex ;-) Been AFK a lot lately.
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Nick Treleaven]

On 05/09/2013 09:41, Matthew Brush wrote:

On 13-09-04 09:20 AM, Nick Treleaven wrote:

My C89 & C++ version:

guint i;
foreach_document(i) {
 GeanyDocument *doc = documents[i];
 // do stuff with every valid doc
}



While this code is short, it's actually sort of nuts too (and also not
very C++-ish).

1. You should include the definition of the custom macro used and the
definitions of the two other non-obvious macros used inside the first
macro for a fair comparison, since none of them are standard or even
well-known like the pasted examples.


Most files already include document.h.


2. The code does not loop over the windows like the pasted code, so
you'd need another outer loop which would likely have a 2nd style of
iteration wrapped around the existing loop.


We don't support accessing multiple windows IIUC.

BTW I was just providing code for that specific case, not necessarily 
for all iteration.



3. It's somewhat unclear what type should be passed in looking at the
macro without the doc comments (I always forget and have to RTFM each
time I see it since we often use gint where we mean guint).

4. The argument is not only assigned to but also evaluated multiple
times (what if you pass `--i` or something weird as argument). I guess
assigning might be good here since the compiler would catch it rather
than flying off the end of the array when it hits `(guint)-1` (UINT_MAX)
on underflow.

5. It's fairly tricky to debug misuses of the macro (better with Clang).

6. The implicit check in the loop (failure first) indexes into a macro
wrapper around a whole other type using a hard cast from the result of
another function-like macro cast thing off in another file, and is
dereferenced without any NULL check (although probably safe in this
case, unless a plugin or something re-assigns the global variable or
redefines any macro aliases of it).

7. It forces you to define an indexing variable outside of the loop into
the wrong scope (C89-style, even if used in > C99 plugin code).

8. Even though slightly dirtier, it would be more useful to iterate over
document pointers than document indexes (what are those? tab pages?
order of opening? arbitrary array indices?), for example (untested, C99
or GNU89 probably):

 #define foreach_doc(doc) \
 for (unsigned z_=0; z_ < documents_array->len; z_++) \
if ( !((doc) = documents_array->pdata[z_]) || \
 !(doc)->is_valid ) { continue; } else
 ...
 GeanyDocument *doc;
 foreach_doc(doc) {
   // every valid doc
 }


Yes, that is much better if we have C99/C++. That also solves most of 
the points above.



9. I personally find it annoying to use API's that have all their own
versions of things that are really common and not that hard anyway; it's
difficult to learn them all, and also all the stuff mentioned above when
they are macros. Consider this slightly longer example that uses no
macro madness and common C looping idiom:

 guint i;
 for (i = 0; i < documents_array->len; i++) {
   GeanyDocument *doc = documents_array->pdata[i];
   // do stuff with every *should be* (but isn't) valid doc
 }

Assuming the API didn't have the weirdness about documents being invalid
but still sticking around for whatever reason, it's the same number of
lines as the macro version and no magic.


Yes. Although sometimes bugs do slip through, even in incrementing for 
loops. Suppose someone used <= instead of <, or forgot to initialize i.



10. The macro should be named `foreach_document_index()`.


OK.


I don't think we should rewrite Geany's API in C++, or maintain a C++
wrapper for the C one, except for any cases which are particularly
bug-prone.



An idiomatic C++ binding would be quite useful for a plugin written in
normal C++. In my current C++ plugin I'm working on, I'm actually
wrapping up a few parts of Geany's API it uses to avoid scattering the
weird C code containing lots of raw pointers, miscellaneous allocators,
different string/collection types, and so on, throughout the normal C++
code.


It would be useful, but also a distraction for the core project.
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Matthew Brush]

On 13-09-04 09:20 AM, Nick Treleaven wrote:

On 01/09/2013 02:36, Matthew Brush wrote:

I would even go so far as to say it's silly to not use C++11 since it's
[...]




Just for fun I wrote some theoretical code that could be used in a
program like Geany to compare styles between various C's and C++'s
(note: none of it tested).

http://pastebin.geany.org/gYFMO/


My C89 & C++ version:

guint i;
foreach_document(i) {
 GeanyDocument *doc = documents[i];
 // do stuff with every valid doc
}



While this code is short, it's actually sort of nuts too (and also not 
very C++-ish).


1. You should include the definition of the custom macro used and the 
definitions of the two other non-obvious macros used inside the first 
macro for a fair comparison, since none of them are standard or even 
well-known like the pasted examples.


2. The code does not loop over the windows like the pasted code, so 
you'd need another outer loop which would likely have a 2nd style of 
iteration wrapped around the existing loop.


3. It's somewhat unclear what type should be passed in looking at the 
macro without the doc comments (I always forget and have to RTFM each 
time I see it since we often use gint where we mean guint).


4. The argument is not only assigned to but also evaluated multiple 
times (what if you pass `--i` or something weird as argument). I guess 
assigning might be good here since the compiler would catch it rather 
than flying off the end of the array when it hits `(guint)-1` (UINT_MAX) 
on underflow.


5. It's fairly tricky to debug misuses of the macro (better with Clang).

6. The implicit check in the loop (failure first) indexes into a macro 
wrapper around a whole other type using a hard cast from the result of 
another function-like macro cast thing off in another file, and is 
dereferenced without any NULL check (although probably safe in this 
case, unless a plugin or something re-assigns the global variable or 
redefines any macro aliases of it).


7. It forces you to define an indexing variable outside of the loop into 
the wrong scope (C89-style, even if used in > C99 plugin code).


8. Even though slightly dirtier, it would be more useful to iterate over 
document pointers than document indexes (what are those? tab pages? 
order of opening? arbitrary array indices?), for example (untested, C99 
or GNU89 probably):


#define foreach_doc(doc) \
for (unsigned z_=0; z_ < documents_array->len; z_++) \
   if ( !((doc) = documents_array->pdata[z_]) || \
!(doc)->is_valid ) { continue; } else
...
GeanyDocument *doc;
foreach_doc(doc) {
  // every valid doc
}

9. I personally find it annoying to use API's that have all their own 
versions of things that are really common and not that hard anyway; it's 
difficult to learn them all, and also all the stuff mentioned above when 
they are macros. Consider this slightly longer example that uses no 
macro madness and common C looping idiom:


guint i;
for (i = 0; i < documents_array->len; i++) {
  GeanyDocument *doc = documents_array->pdata[i];
  // do stuff with every *should be* (but isn't) valid doc
}

Assuming the API didn't have the weirdness about documents being invalid 
but still sticking around for whatever reason, it's the same number of 
lines as the macro version and no magic.


10. The macro should be named `foreach_document_index()`.




I don't think we should rewrite Geany's API in C++, or maintain a C++
wrapper for the C one, except for any cases which are particularly
bug-prone.



An idiomatic C++ binding would be quite useful for a plugin written in 
normal C++. In my current C++ plugin I'm working on, I'm actually 
wrapping up a few parts of Geany's API it uses to avoid scattering the 
weird C code containing lots of raw pointers, miscellaneous allocators, 
different string/collection types, and so on, throughout the normal C++ 
code.


Cheers,
Matthew Brush

___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Nick Treleaven]

On 01/09/2013 01:08, Lex Trotman wrote:

I mean inheritance and virtual functions. I don't think they would pull
>their weight in src, unless we were going to use gtkmm for custom widgets.


Agree I can't immediately think of places where inheritance is likely to be
useful at high level, but thats no reason to ban it.


That's not the reason. The reason is maintainability and ease of 
contribution.

___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Nick Treleaven]

On 01/09/2013 02:36, Matthew Brush wrote:

I would even go so far as to say it's silly to not use C++11 since it's
[...]




Just for fun I wrote some theoretical code that could be used in a
program like Geany to compare styles between various C's and C++'s
(note: none of it tested).

http://pastebin.geany.org/gYFMO/


My C89 & C++ version:

guint i;
foreach_document(i) {
GeanyDocument *doc = documents[i];
// do stuff with every valid doc
}

I don't think we should rewrite Geany's API in C++, or maintain a C++ 
wrapper for the C one, except for any cases which are particularly 
bug-prone.

___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Matthew Brush]

On 13-08-31 04:37 PM, Lex Trotman wrote:

On 1 September 2013 00:05, Nick Treleaven wrote:


On 29/08/2013 06:47, Lex Trotman wrote:


[...]


  On using gtkmm, personally I think it is *way* better than the C interface

to GTK, but I don't know if it can be mixed with C GTK easily, and
changing
*everything at once* would be a big job.



I don't know either, but gtkmm is much better than GObject boilerplate.
Although I don't think we need custom objects that often.



Funnily enough, since subclassing widgets is trivial with gtkmm, they start
to be used more often in my experience :)



Yeah, there's lots of cases for Geany; geany::MainWindow, 
geany::Toolbar, geany::PrefsDialog, geany::Scintilla, geany::StatusBar, 
geany::SymbolsView, geany::EditorMenu, and even the existing GObject 
subclasses, not to mention geany::Filetype or geany::Document and friends.


Anywhere you want to extend/customize the behaviour of another class or 
widget or such.


Cheers,
Matthew Brush
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Matthew Brush]

On 13-08-31 07:05 AM, Nick Treleaven wrote:

On 29/08/2013 06:47, Lex Trotman wrote:

[...]



Nick has offered that C++ "might" attract him to contribute more, I
"might"
have time at the end of my current contract, unless I get another
quickly,
I guess Colomban is out, Matthew? anybody else?


I'm happy to manage/co-ordinate the transition to C++ (at a slowish
pace), should we decide we want that.



IMO, step #1 is to create a separate branch for this topic. I'm sure 
Colomban won't mind a separate branch if it's not affecting master and 
it would provide a hacking playground for everyone interested. If it 
proves fruitful, we could eventually look to merge/replace Geany code 
from this branch, even if we have to maintain separate branches for some 
time.


I think starting with a core plugin is a good idea. The "Class Builder" 
plugin has lots of gnarly C string copying/formatting/etc, it might be a 
good candidate for hackage, as per your suggestion.


Cheers,
Matthew Brush

___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Matthew Brush]

On 13-08-31 07:42 PM, Lex Trotman wrote:

[...]






Just for fun I wrote some theoretical code that could be used in a program
like Geany to compare styles between various C's and C++'s (note: none of
it tested).

http://pastebin.geany.org/**gYFMO/ 




As discussed on IRC here's another way of doing the C++98/03, marked with
+es. http://pastebin.geany.org/AzbMV/



Or alternatively in c++11 :)

for_each(begin(App::instance().windows()),
 end(App::instance().windows()),
 [] (Window &win) {
   for_each(begin(win.documents()),
end(win.documents(),
[] (Document &doc) {
  // do stuff with each document
}
);
 }
);

Cheers,
Matthew Brush
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Lex Trotman]

[...]

>
>>
> Just for fun I wrote some theoretical code that could be used in a program
> like Geany to compare styles between various C's and C++'s (note: none of
> it tested).
>
> http://pastebin.geany.org/**gYFMO/ 



As discussed on IRC here's another way of doing the C++98/03, marked with
+es. http://pastebin.geany.org/AzbMV/

This is the method I alluded to in my response to Nick.

For the micro-optimisers among us, its very likely to generate the same
code as the first version since the operator() call is inlined :)

Cheers
Lex


>
> Cheers,
> Matthew Brush
>
> __**_
> Devel mailing list
> Devel@lists.geany.org
> https://lists.geany.org/cgi-**bin/mailman/listinfo/devel
>
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Matthew Brush]

On 13-08-29 05:08 AM, Nick Treleaven wrote:

On 29/08/2013 02:39, Matthew Brush wrote:

[...]



If we were to use C++, I think it'd be pointless to limit it to
CFront/CwithClasses-style 1980's C++. We should use common/standard
stuff like standard library containers, inheritance (maybe not
multipl-inheritance), the class keyword, templates (where it makes
sense), exceptions, etc. The issues/limits being discussed in this
thread are issues long since considered "resolved" or "non-issues" for a
long time for desktop software (and since a *long* time even before
Geany's first line of code was written :). The style of code I read on
the net and in talks and books and stuff is modern (ie. >= C++98) style
C++ and I'd expect that's what the bulk of C++-using contributors would
be used to using.


Idiomatic C++ takes a *lot* of learning and experience to get right for
someone coming from C.



Do you think there's more C-only programmers out there contributing to 
desktop application projects than C++ programmers? I honestly don't know 
but my instinct says there isn't.



I would even go so far as to say it's silly to not use C++11 since it's
[...]




Just for fun I wrote some theoretical code that could be used in a 
program like Geany to compare styles between various C's and C++'s 
(note: none of it tested).


http://pastebin.geany.org/gYFMO/

Cheers,
Matthew Brush
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Lex Trotman]

[...]

>  Readability is definitely better in C++11 when avoiding iterators and
>>> using lambdas, but I was kind of hoping we could avoid those ugly cases.
>>> I
>>> wasn't thinking of using the STL heavily, just a few containers like
>>> string, and perhaps others for any specialized use cases.
>>>
>>>
>> Sadly, containers means iterators, inevitably, and yes C++03 syntax is
>> ugly, but you get used to it, and just type it automatically. Pity "auto"
>> and "for( a: container )" is C++11, oh well.
>>
>
> Yes. Unless we use a foreach macro ;-P
>

m-m-m-m-m-macro?

There seems to be a typo here, I assume you mean the std::for_each template
:)

And of course requiring the use of a function object declared immediately
before the for_each, not a function declared some distance away.



> I'm not sure iterators are needed often for string though, but it's been a
> while since I looked at code using it.


Ahh, I may have been misunderstanding you again.

Strictly strings are not containers, so I havn't considered them whenever
you said container, I was thinking vector, list, etc.

I find iterators are rarely used on strings because it has operator[] and
most of the operations return an index, not an iterator.


>
>
>  I proposed banning OOP, operator overloading and exceptions in src to make
>>
>>> it (much?) easier to understand & maintain the code vs idiomatic C++,
>>> with
>>> all its unintuitive bug-prone corner cases (which are still in C++11),
>>> see
>>> my reply to Lex for more info.
>>>
>>>
>>>  Looking at it again, I'm not sure we mean the same thing by OOP, its a
>> much
>> abused and overloaded term, could you perhaps explain your meaning?
>>   Depending on what you mean, banning it is either sensible, or the
>> silliest
>> idea ever :)
>>
>
> I mean inheritance and virtual functions. I don't think they would pull
> their weight in src, unless we were going to use gtkmm for custom widgets.


Agree I can't immediately think of places where inheritance is likely to be
useful at high level, but thats no reason to ban it.

Mind you, the concepts of document and filetype could be combined by
deriving a filetype specific document type from the base Document class,
allowing filetype specific overriding of functions like indenting :)

class Perl_document::Document { etc };

Which brings me to the point that some *design* and planning might be
useful before we start hacking.

 [...]

Cheers
Lex
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Lex Trotman]

On 1 September 2013 00:05, Nick Treleaven wrote:

> On 29/08/2013 06:47, Lex Trotman wrote:
>
>> On the topic of exceptions, remember many STL operations and "new" can
>> throw.  Of course only throwing on uncorrectable errors like out of memory
>> is fine, it just exits the application.  Thats what will happen to a throw
>> from Scintilla in current Geany, its not something that will be
>> introduced.
>>   But as resource management moves to RAII, exceptions can be caught and
>> produce a more user friendly exit such as dumping buffers first.
>>
>
> OK. We might not want to use -fno-exceptions then, but maybe still avoid
> throwing ourselves.


I've never used -fno-exceptions, but reading the docs it doesn't sound like
it actually stops code throwing, just it doesn't create the data tables for
stack unwinding.  I presume therefore throws go direct to terminate(), do
not pass try, do not catch $200 (apologies to Monopoly :)



>
>
>  On using gtkmm, personally I think it is *way* better than the C interface
>> to GTK, but I don't know if it can be mixed with C GTK easily, and
>> changing
>> *everything at once* would be a big job.
>>
>
> I don't know either, but gtkmm is much better than GObject boilerplate.
> Although I don't think we need custom objects that often.


Funnily enough, since subclassing widgets is trivial with gtkmm, they start
to be used more often in my experience :)


>
>
>  Not sure why the RTTI affects the ABI, things visible in the ABI must be
>> POD to maintain C compatibility, there are much stricter limitations to
>> maintaining POD, like no non-trivial constructors etc.
>>
>
> OK, so a struct declaration in extern C would be compatible with the C ABI.


Yes, a pure struct, no constructors, destructors, no virtual member
functions etc is required by the standard to be the same layout as C.  The
extern "C" just stops the names being mangled so it will link with C.


>
>
>  We need to organise the resources first, doing things "to attract more
>> contributors" have so far failed, I wouldn't bet a change like this on
>> attracting more support (at least in the time the change is happening).
>>
>
> I think moving to C99 may at least avoid /deterring/ further contributions
> because of minor issues like C++-style comments and variable declaration
> after code (or at least in a for statement). I don't know if it makes a big
> difference, but the fewer unnecessary hurdles we make them jump through the
> better.


Yes, if those things are allowed.



>
>
>  Nick has offered that C++ "might" attract him to contribute more, I
>> "might"
>> have time at the end of my current contract, unless I get another quickly,
>> I guess Colomban is out, Matthew? anybody else?
>>
>
> I'm happy to manage/co-ordinate the transition to C++ (at a slowish pace),
> should we decide we want that.



Cheers
Lex


>
> __**_
> Devel mailing list
> Devel@lists.geany.org
> https://lists.geany.org/cgi-**bin/mailman/listinfo/devel
>
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Nick Treleaven]

On 29/08/2013 13:52, Lex Trotman wrote:

  I would even go so far as to say it's silly to not use C++11 since it's

such a major improvement over previous C++ versions, in both performance



I'm curious, why does it perform better?



I'm putting words in Matthews mouth here, but things like move semantics
can reduce the need for allocations and copying, but like all such
"performance improvements" it needs to be used a zillion times before it
matters, and well, Geany does few things a zillion times (except inside
Scintilla's rendering code).


OK.


Readability is definitely better in C++11 when avoiding iterators and
using lambdas, but I was kind of hoping we could avoid those ugly cases. I
wasn't thinking of using the STL heavily, just a few containers like
string, and perhaps others for any specialized use cases.



Sadly, containers means iterators, inevitably, and yes C++03 syntax is
ugly, but you get used to it, and just type it automatically. Pity "auto"
and "for( a: container )" is C++11, oh well.


Yes. Unless we use a foreach macro ;-P
I'm not sure iterators are needed often for string though, but it's been 
a while since I looked at code using it.



I proposed banning OOP, operator overloading and exceptions in src to make

it (much?) easier to understand & maintain the code vs idiomatic C++, with
all its unintuitive bug-prone corner cases (which are still in C++11), see
my reply to Lex for more info.



Looking at it again, I'm not sure we mean the same thing by OOP, its a much
abused and overloaded term, could you perhaps explain your meaning?
  Depending on what you mean, banning it is either sensible, or the silliest
idea ever :)


I mean inheritance and virtual functions. I don't think they would pull 
their weight in src, unless we were going to use gtkmm for custom widgets.



Yes, or maybe convert a core plugin that uses strings a lot, so we get the
benefit of RAII. I might look into it unless Colomban is against that (even
for a core plugin).



Good idea, plugins can be written in C++ now, without any changes to Geany
being needed.  Just make sure you don't leak exceptions (unless you mean
to) since they currently mean terminate().


OK.

Regards,
Nick
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Nick Treleaven]

On 29/08/2013 06:47, Lex Trotman wrote:

On the topic of exceptions, remember many STL operations and "new" can
throw.  Of course only throwing on uncorrectable errors like out of memory
is fine, it just exits the application.  Thats what will happen to a throw
from Scintilla in current Geany, its not something that will be introduced.
  But as resource management moves to RAII, exceptions can be caught and
produce a more user friendly exit such as dumping buffers first.


OK. We might not want to use -fno-exceptions then, but maybe still avoid 
throwing ourselves.



On using gtkmm, personally I think it is *way* better than the C interface
to GTK, but I don't know if it can be mixed with C GTK easily, and changing
*everything at once* would be a big job.


I don't know either, but gtkmm is much better than GObject boilerplate. 
Although I don't think we need custom objects that often.



Not sure why the RTTI affects the ABI, things visible in the ABI must be
POD to maintain C compatibility, there are much stricter limitations to
maintaining POD, like no non-trivial constructors etc.


OK, so a struct declaration in extern C would be compatible with the C ABI.


We need to organise the resources first, doing things "to attract more
contributors" have so far failed, I wouldn't bet a change like this on
attracting more support (at least in the time the change is happening).


I think moving to C99 may at least avoid /deterring/ further 
contributions because of minor issues like C++-style comments and 
variable declaration after code (or at least in a for statement). I 
don't know if it makes a big difference, but the fewer unnecessary 
hurdles we make them jump through the better.



Nick has offered that C++ "might" attract him to contribute more, I "might"
have time at the end of my current contract, unless I get another quickly,
I guess Colomban is out, Matthew? anybody else?


I'm happy to manage/co-ordinate the transition to C++ (at a slowish 
pace), should we decide we want that.

___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Lex Trotman]

Hi Nick,

[...]

>
>  I would even go so far as to say it's silly to not use C++11 since it's
>> such a major improvement over previous C++ versions, in both performance
>>
>
> I'm curious, why does it perform better?


I'm putting words in Matthews mouth here, but things like move semantics
can reduce the need for allocations and copying, but like all such
"performance improvements" it needs to be used a zillion times before it
matters, and well, Geany does few things a zillion times (except inside
Scintilla's rendering code).


>
>
>  and readability/coder-friendliness and it's well supported on current
>> compilers and platforms.
>>
>
> Is it? I hadn't heard that, maybe. But I bet it will cause problems for
> some distro maintainers/builders on LTS distros.
>

Many of the simpler but useful parts of C++11 seem to have been implemented
in many compilers a while ago, and most compilers now seem to be at, or
close to, standards compliance, but as you say LTS systems are not going to
support C++11 for a while yet.  For example gcc 4.6 (the oldest supported
version) does some stuff under the banner of C++0x and I'm happily using
C++11 with gcc 4.7 without problems, a bit behind the 4.9 latest
development version.


>
> Readability is definitely better in C++11 when avoiding iterators and
> using lambdas, but I was kind of hoping we could avoid those ugly cases. I
> wasn't thinking of using the STL heavily, just a few containers like
> string, and perhaps others for any specialized use cases.
>

Sadly, containers means iterators, inevitably, and yes C++03 syntax is
ugly, but you get used to it, and just type it automatically. Pity "auto"
and "for( a: container )" is C++11, oh well.

 [...]

I proposed banning OOP, operator overloading and exceptions in src to make
> it (much?) easier to understand & maintain the code vs idiomatic C++, with
> all its unintuitive bug-prone corner cases (which are still in C++11), see
> my reply to Lex for more info.
>
>
Looking at it again, I'm not sure we mean the same thing by OOP, its a much
abused and overloaded term, could you perhaps explain your meaning?
 Depending on what you mean, banning it is either sensible, or the silliest
idea ever :)


>
>  Maybe rather than bikeshed about it too much, we can wait until someone
>> wants to add a new module, or replace an existing module (I'm looking at
>> you TM!), or some actual use case, at which point we could discuss
>> whether it makes sense to use C++ for it, and since we already use C++
>> for Scintilla, it's not a huge change to use it in another new C++
>> module with respect to the build systems and stuff.
>>
>
> Yes, or maybe convert a core plugin that uses strings a lot, so we get the
> benefit of RAII. I might look into it unless Colomban is against that (even
> for a core plugin).


Good idea, plugins can be written in C++ now, without any changes to Geany
being needed.  Just make sure you don't leak exceptions (unless you mean
to) since they currently mean terminate().

Cheers
Lex
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Nick Treleaven]

On 29/08/2013 02:39, Matthew Brush wrote:

Personally, I think it'd be great to use C++ in Geany, and it would more
than likely actually make it *easier* for people to contribute since
outside of a sampling of GTK+-using desktop/GUI software (and obviously
embedded, kernel, drivers, and similar), C is considered "dead" and the
majority uses >= C++ (more likely Java, C#, Python ... many people also
consider C++ outdated and dead for desktop GUI apps - not me BTW :). C++
allows modern programming techniques but still retains much (or more) of
the performance and "light-weightedness" that Geany strives for.


Yeah, templates make it much easier for libraries to have extra 
flexibility in performance.



If we were to use C++, I think it'd be pointless to limit it to
CFront/CwithClasses-style 1980's C++. We should use common/standard
stuff like standard library containers, inheritance (maybe not
multipl-inheritance), the class keyword, templates (where it makes
sense), exceptions, etc. The issues/limits being discussed in this
thread are issues long since considered "resolved" or "non-issues" for a
long time for desktop software (and since a *long* time even before
Geany's first line of code was written :). The style of code I read on
the net and in talks and books and stuff is modern (ie. >= C++98) style
C++ and I'd expect that's what the bulk of C++-using contributors would
be used to using.


Idiomatic C++ takes a *lot* of learning and experience to get right for 
someone coming from C.



I would even go so far as to say it's silly to not use C++11 since it's
such a major improvement over previous C++ versions, in both performance


I'm curious, why does it perform better?


and readability/coder-friendliness and it's well supported on current
compilers and platforms.


Is it? I hadn't heard that, maybe. But I bet it will cause problems for 
some distro maintainers/builders on LTS distros.


Readability is definitely better in C++11 when avoiding iterators and 
using lambdas, but I was kind of hoping we could avoid those ugly cases. 
I wasn't thinking of using the STL heavily, just a few containers like 
string, and perhaps others for any specialized use cases.


Variadic templates are very cool also. (Die, stream << operators!)


Since we're talking about better languages, there's also Vala which has
most of the benefits discussed here about C++, already uses the same
libraries and type-system as our existing G* code, is API compatible
with C (in the sense that it generates idiomatic G*-style C code,
mostly) and would be an easier transition for the vast quantity of C#
programmers out there who might want to contribute, since the languages
are so similar. Not sure it's a point since most of them use Mono and
C#-strong IDEs, but still, in general there's probably substantially
more developers out there who know C# better than C or C++.


I'm happy to consider using Vala, but I think it would probably be a lot 
less work to use C++ if we want to convert existing code.



While it's a community project, and in general I think the popular
opinion should ultimately prevail or at least that not one person
(barring maybe a BDL) solely controls the direction of the project's
momentum, it's somewhat harsh to make the current maintainer who does an
excellent job and devotes a lot of time already to working on Geany
stuff, to learn a whole different, non-trivial language, one he
dislikes, and to become "more proficient than average" in order to be
able to continue doing code reviews, merging PRs and stuff.


+1. Although I would definitely be keener to contribute using restricted 
C++, I don't want to be maintainer again. Thanks for all the great work 
Colomban (and others) ;-)



I'm all for using modern C++ in strategic (or new) places and I'm
totally against using ancient 1980/90's CFront-style C++ or that which
is restricted so much that it's basically C.


totally against :-O

RAII is a powerful feature that standard C has no hope of competing 
with. It basically allows a string type with automatic memory 
management. Ditto for templates, but I can live without defining our own 
templates if that helps contributor understanding & maintainability.


I proposed banning OOP, operator overloading and exceptions in src to 
make it (much?) easier to understand & maintain the code vs idiomatic 
C++, with all its unintuitive bug-prone corner cases (which are still in 
C++11), see my reply to Lex for more info.



Maybe rather than bikeshed about it too much, we can wait until someone
wants to add a new module, or replace an existing module (I'm looking at
you TM!), or some actual use case, at which point we could discuss
whether it makes sense to use C++ for it, and since we already use C++
for Scintilla, it's not a huge change to use it in another new C++
module with respect to the build systems and stuff.


Yes, or maybe convert a core plugin that uses strings a lot, so we get 
the benefit of RAII. I might look into

Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Lex Trotman]

Nick, Matthew, Dimitar,

To keep it short, a few comments:

@Nick,

Thinking back on previous conversions from C to C++, those that went
smoothest were the ones that first changed to compiling with the C++
compiler, with minimal changes to the C code.  This means that you are not
having to be unreasonably careful about non-C compatible features like
exceptions.   That also allows smart pointers for resource management
(where an object is needed outside its creation scope) and other useful
features.

On the topic of exceptions, remember many STL operations and "new" can
throw.  Of course only throwing on uncorrectable errors like out of memory
is fine, it just exits the application.  Thats what will happen to a throw
from Scintilla in current Geany, its not something that will be introduced.
 But as resource management moves to RAII, exceptions can be caught and
produce a more user friendly exit such as dumping buffers first.

After Geany compiles with C++, then parts that can benefit from/need more
C++ features can be changed as someone wants/needs to, its not that
everything has to go to multiple inherited virtual templates tomorrow :).

On using gtkmm, personally I think it is *way* better than the C interface
to GTK, but I don't know if it can be mixed with C GTK easily, and changing
*everything at once* would be a big job.

Not sure why the RTTI affects the ABI, things visible in the ABI must be
POD to maintain C compatibility, there are much stricter limitations to
maintaining POD, like no non-trivial constructors etc.

@Dimitar,

IIUC many C++ implementations (and even some C ones) use the same algorithm
as gslice for small objects already, and of course it can't be used for
strings since they are not fixed size.

The global/static/auto version of RAII is fine if you use smart pointers to
objects that have longer lifetimes, the local RAII ensures that the object
is deleted any time it is still owned by a smart pointer declared in the
scope being exited.  If the object is to live on, it will have been passed
to another smart pointer outside the scope.

@Matthew,

The resource engineering points are IMHO the main ones preventing this
happening.  Geany just doesn't have enough resources to do major changes.
 Subtract those who don't like C++ (its a free world, I don't like Vala :)
and the resources are slimmer still.  Irrespective of whether the changes
are made "one file at a time" or "all C to C++ with minimal changes" there
is a significant first step, coding and testing and testing and testing.
 Most of us are very time constrained, unless we find a significant pool of
available resources it is not gonna happen.

We need to organise the resources first, doing things "to attract more
contributors" have so far failed, I wouldn't bet a change like this on
attracting more support (at least in the time the change is happening).

Nick has offered that C++ "might" attract him to contribute more, I "might"
have time at the end of my current contract, unless I get another quickly,
I guess Colomban is out, Matthew? anybody else?

Cheers
Lex
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Matthew Brush]

On 13-08-26 08:07 AM, Nick Treleaven wrote:

 From the C99 discussion:

lex:
 >>> Unless we follow the example of gcc itself and upgrade to C++ :)

me:
 >> Not sure that's a good idea for Geany now, although I'm glad that gcc
 >> did it. They use a restricted subset IIRC. I miss templates and RAII in
 >> C though.

I now think gradually using a (quite heavily restricted) subset of C++98
for *some* source files might be better than moving to C99 (more on that
below). I still support C99 over just C90 though. (I don't do a lot of
Geany coding now, but I plan to do some from time to time, so obviously
this is just my opinion and less important than more active devs).

Reasons:

* No build problems for Long Term Support distros that don't support C99
(but clearly do compile scintilla's C++98).

* RAII - this is a pretty essential feature for safe resource
management. It's a stupid acronym though, it's basically automatic
scoped destruction:

http://en.wikipedia.org/wiki/Resource_Acquisition_is_Initialization

* References can be useful in making code more readable vs pointers.

* Developer enjoyment, productivity & gaining more experience with C++.
(This might be an incentive for e.g. me to spend more time working on
Geany). This has to be offset against those that might need to learn
e.g. RAII.

* Possibly we might use some STL containers internally.

* Possibly we could use a GObject wrapper for safe reference counting. I
don't want to add any dependencies on C++ libraries though.

* Possibly we could have some template function utilities instead of
unsafe macros. Although I think most header files should be kept C90
compatible.

matt:
 > +1. While I'm also not sure it's a good idea in Geany and certainly
 > won't be pressing for it anytime soon, 90% of C++'s crumminess is due to
 > backwards compatibility with C, so I think it should be (theoretically,
 > not socially) possible to gradually transition from one to the other in
 > a project like Geany without too much pain.

colomban:
 > I doubt it, C++ is sufficiently different from a C program not to be
 > compilable by a C++ compiler in many cases -- even if it is just for
 > some implicit casts C++ requires to be explicit (IIRC), and there are
 > plenty.  Or maybe it depends what "too much pain" means:)
 >
 > Also, I doubt it's any kind of sensible either, because good C++ use is
 > sufficiently different from C to require large rewrite.  In this case,
 > better rewrite everything and don't keep the clumsy code

I disagree it *requires* a large rewrite. You can make *good* use of
some C++ features without having *idiomatic* use of C++. (E.g. dmd, the
reference D compiler is not written in idiomatic C++ - it doesn't use
the STL really, but it's still good code).

I think it would be quite manageable. If we did this, I suggest just
converting one source file at a time, and only files that can benefit
from RAII and/or the more powerful type system.

We would also need to disable some C++ features. I hoped we could do
that with g++ flags, but I've only found this so far:

-fno-rtti (disable runtime info for object inheritance)

There ought to be a way to disable mixed code and declarations, but
maybe not.

I don't know if this can be enforced by g++, but I suggest we disallow
these keywords:

class
dynamic_cast
friend
mutable
operator
throw
virtual

That could be enforced with a 'make check' build target.

Thoughts?



I was waiting for Colomban to respond before piping up, but whatever. 
I'll just respond to the general topics in the thread in my typical 
TL;DR fashion (skip to Conclusion section if you like :)


Style and Ease of Contribution
--

Personally, I think it'd be great to use C++ in Geany, and it would more 
than likely actually make it *easier* for people to contribute since 
outside of a sampling of GTK+-using desktop/GUI software (and obviously 
embedded, kernel, drivers, and similar), C is considered "dead" and the 
majority uses >= C++ (more likely Java, C#, Python ... many people also 
consider C++ outdated and dead for desktop GUI apps - not me BTW :). C++ 
allows modern programming techniques but still retains much (or more) of 
the performance and "light-weightedness" that Geany strives for.


If we were to use C++, I think it'd be pointless to limit it to 
CFront/CwithClasses-style 1980's C++. We should use common/standard 
stuff like standard library containers, inheritance (maybe not 
multipl-inheritance), the class keyword, templates (where it makes 
sense), exceptions, etc. The issues/limits being discussed in this 
thread are issues long since considered "resolved" or "non-issues" for a 
long time for desktop software (and since a *long* time even before 
Geany's first line of code was written :). The style of code I read on 
the net and in talks and books and stuff is modern (ie. >= C++98) style 
C++ and I'd expect that's what the bulk of C++-using contributors would 
be used to using.


I'd say the li

Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Dimitar Zhekov]

On Wed, 28 Aug 2013 15:52:17 +0100
Nick Treleaven  wrote:

> >> * Developer enjoyment, productivity & gaining more experience with C++.
> >> (This might be an incentive for e.g. me to spend more time working on
> >> Geany). This has to be offset against those that might need to learn
> >> e.g. RAII.
> 
> > Hmmm?..
> 
> Time spent for contributors who don't know C++ to learn the parts we 
> use. What's the question?

What's the assumption - that harder contribution will actually be
beneficial? Maybe we should throw some C# then, it's modern and
somewhat supported under Linux, and there may be people who want to
learn it. :)

> Assuming we're comparing the same design in C vs templated C++ code, the 
> C++ code would normally have an advantage because more code can be 
> inlined. It might be at a disadvantage because of code bloat though, but 
> the inlining may outweigh that. Are you sure you tested the C++ code 
> with full compiler optimization?

With -O2 for gcc, and the standard "Optimize for speed" profile in the
compiler used by our company. If you mean something like -O99, no, I
haven't. The difference insignificant (<= 0.5%), only annoying.
A probable reason is that STL doesn't use realloc(), and has no slice
allocator (though I haven't tested slices explicitly).

> > Note that gcc has a non-standard extension for RAII, which works with
> > the base C types. And Geany compiles with gcc only.
> 
> Really? Have you read HACKING?

The non-existent part which lists the supported compilers? :)
(I know, I know: use standard C code only).

--

So it would be something  with pointers-and-references,
gchar-and-[S]String, STL-and-GArray/GList (sometimes required by
GLib/GTK), GObjects-and-classes (or no classes? or library classes
only?..), and some words banned... It'll indeed be challenging to
contribute.

About RAII, how can I convice you that the automatic destructors for
global/static and auto objects *only* are not that useful? Perhaps by
the fact that the later languages, Java and C#, use a different model,
more similar to GLib?

As for our own C++ reference counting for pointers - please... One
should not include new essences unless required. Sorry if my english
is unclear, I think Lex will understand and say it better.

If we are to switch, let's at least stick to what scintilla/gtk/*
does, instead of inventing our own "standards" and wheels. And by that,
I mean gradually rewriting Geany with classes. C++ with functions is
like perl with glob() expressions. It'll still be ugly though, with all
the x'-and-x"-s listed above.

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Nick Treleaven]

On 27/08/2013 02:48, Lex Trotman wrote:

Hi Nick,

Thanks for the well thought out sensible proposal.  In general I agree with
the idea of progressively moving appropriate parts of the code to using
appropriate C++ features.  Of course, as usual, I disagree on some of the
details and I'm sure we would disagree on some of the selections of files,
but thats healthy.


Thanks for considering it ;-)


I now think gradually using a (quite heavily restricted) subset of C++98
for *some* source files might be better than moving to C99 (more on that
below). I still support C99 over just C90 though. (I don't do a lot of
Geany coding now, but I plan to do some from time to time, so obviously
this is just my opinion and less important than more active devs).



I'll address the "restricted subset" idea here and refer back from relevant
places below.  My experience of a couple of projects migrating to C++ is
that applying strict "limits" on the C++ features just leads to
implementing those features poorly in the code itself.  One common one is
to not allow virtual functions, but in my experience that just leads to the
use of function pointers and the associated ugly syntax and increase in
errors.


If we want to write OOP code, allow "virtual" and "class". Personally I 
tend to think for Geany OOP is mostly useful for GTK. If we want that, 
we would need gtkmm bindings.


Another reason why I suggest we don't use OOP is that getting 
overloading right with inheritance is difficult for C++ beginners, and 
can cause bugs with experienced devs. Avoiding OOP simplifies the 
unintuitive corner cases of C++, and is easier for C programmers.



The approach that seems to have worked better is the same as that required
for C++ in general, *appropriate* use of features.  Whilst that is easier
to control in a corporate situation where programmers can be trained
properly, review by senior devs should catch the more egregious misuses
within Geany, its not like we have a huge developer base to train anyway :).


We have a fairly large potential contributor base.


Reasons:

* No build problems for Long Term Support distros that don't support C99
(but clearly do compile scintilla's C++98).



Neil is attempting to move Scintilla forward, it might soon be using C++03.5


Another project was against Neil moving to C++11, not just us. Nice 
though C++11 is. As things stand though, we know using more C++98 won't 
cause problems for users. C99 possibly might. C++11 may do.



* RAII - this is a pretty essential feature for safe resource management.
It's a stupid acronym though, it's basically automatic scoped destruction:

http://en.wikipedia.org/wiki/**Resource_Acquisition_is_**Initialization



Agree on both the usefulness and the silly name :)


:)


* References can be useful in making code more readable vs pointers.



Unfortunately, since references are immutable, you can never get rid of
pointers in imperative style programs, that leads to code with a mix,
luckily getting it wrong (using . not ->) will be picked up by the compiler.


I don't want to use references instead of pointers, only where 
references make the code easier to maintain. E.g. 'Output' arguments and 
sometimes in local scope to simplify repeated expressions.



* Developer enjoyment, productivity & gaining more experience with C++.
(This might be an incentive for e.g. me to spend more time working on
Geany). This has to be offset against those that might need to learn e.g.
RAII.



Indeed there is a learning curve, but hopefully many will find that useful
and attractive.


+1


* Possibly we could use a GObject wrapper for safe reference counting. I
don't want to add any dependencies on C++ libraries though.



Or what almost all my C++03 programs have, a template headed:  /* The
ubiquitous intrusive reference counted smart pointer */ :)

Of course use gobject, for things that are gobjects, but don't bring it
into things that are not, the idea is to move to C++, not to tie more
closely to a C library.


I don't know how well it would work in practice. But it might be better 
to stick to one type for reference counting than two.



* Possibly we could have some template function utilities instead of
unsafe macros. Although I think most header files should be kept C90
compatible.



Yes existing headers that are used by the remaining C code will have to
remain C compatible, and will probably need:

#ifdef __cplusplus
extern "C" {
#endif

around them.


There's a GLib macro for that.


But (for C++ files) that doesn't prevent having extra headers with
templates in them.


Yes.


matt:

+1. While I'm also not sure it's a good idea in Geany and certainly
won't be pressing for it anytime soon, 90% of C++'s crumminess is due to
backwards compatibility with C, so I think it should be (theoretically,
not socially) possible to gradually transition from one to the other in
a project like Geany without to

Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Nick Treleaven]

On 26/08/2013 19:54, Dimitar Zhekov wrote:

On Mon, 26 Aug 2013 16:07:13 +0100
Nick Treleaven  wrote:

* RAII - this is a pretty essential feature for safe resource
>management.

This works for global/static and auto classes. We can wrap a gchar *s
= g_strdup_printf() in a class, but I'd rather not...


We don't always need a gchar*. For string processing we could use the 
STL basic_string (or Scintilla SString).



* References can be useful in making code more readable vs pointers.


But using both heavily (as GLib/GTK+ required pointers) will make it
harder to read.


Just use them where they help ;-)


* Developer enjoyment, productivity & gaining more experience with C++.
(This might be an incentive for e.g. me to spend more time working on
Geany). This has to be offset against those that might need to learn
e.g. RAII.


Hmmm?..


Time spent for contributors who don't know C++ to learn the parts we 
use. What's the question?



* Possibly we might use some STL containers internally.


There things are heavily templated. They generate more code,
compilation is slower, and (unless improved significantly from the last
time I tried them) the code is overall slower than using GArray/GList.


Slower compilation may be an issue. The minor performance/bloat 
differences you mention would not be a problem for Geany IMO.


Assuming we're comparing the same design in C vs templated C++ code, the 
C++ code would normally have an advantage because more code can be 
inlined. It might be at a disadvantage because of code bloat though, but 
the inlining may outweigh that. Are you sure you tested the C++ code 
with full compiler optimization?



Moreover, you propose to ban "class".


struct = class but with public member visibility by default.


* Possibly we could use a GObject wrapper for safe reference counting.


Why? Where? How to do that without classes and destructors?


Obviously you need destructors for RAII. I meant ban the keyword 'class' 
in Geany code, not in STL code.



Note that gcc has a non-standard extension for RAII, which works with
the base C types. And Geany compiles with gcc only.


Really? Have you read HACKING?


* Possibly we could have some template function utilities instead of
unsafe macros.


Do we need these macros to work with different types? If not, "inline
is already declared in a portable manner in the GLib headers and can be
used normally."


See FALLBACK in tagmanager. Matt doesn't like it though. I don't expect 
we need to replace many macros, more that some template utility 
functions will be useful in C++ code. I can give an example if you like.



I don't know if this can be enforced by g++, but I suggest we disallow
these keywords:

class


There isn't, that's THE most basic feature of C++.
And you can write classes with struct and union.


exactly.


dynamic_cast


-fno-rtti


ok.


friend


No classes -> no usage for friends.

...
>> virtual
>
> No classes -> no virtual methods.

*cough* structs *cough*


throw


-fno-exceptions


nice


Thoughts?


Sorry, but IMHO, that seems even more pointless than using C99.


RAII != pointless

___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Lex Trotman]

Hi Nick,

Thanks for the well thought out sensible proposal.  In general I agree with
the idea of progressively moving appropriate parts of the code to using
appropriate C++ features.  Of course, as usual, I disagree on some of the
details and I'm sure we would disagree on some of the selections of files,
but thats healthy.

Comments below.

Cheers
Lex


On 27 August 2013 01:07, Nick Treleaven wrote:

> From the C99 discussion:
>
> lex:
> >>> Unless we follow the example of gcc itself and upgrade to C++ :)
>
> me:
> >> Not sure that's a good idea for Geany now, although I'm glad that gcc
> >> did it. They use a restricted subset IIRC. I miss templates and RAII in
> >> C though.
>
> I now think gradually using a (quite heavily restricted) subset of C++98
> for *some* source files might be better than moving to C99 (more on that
> below). I still support C99 over just C90 though. (I don't do a lot of
> Geany coding now, but I plan to do some from time to time, so obviously
> this is just my opinion and less important than more active devs).
>

I'll address the "restricted subset" idea here and refer back from relevant
places below.  My experience of a couple of projects migrating to C++ is
that applying strict "limits" on the C++ features just leads to
implementing those features poorly in the code itself.  One common one is
to not allow virtual functions, but in my experience that just leads to the
use of function pointers and the associated ugly syntax and increase in
errors.  Since the runtime costs are still there, all you have saved is the
cost of the pointer in the object (or at least reduced it to a flag
indicating the object type, but then you have to test it each use, again
error prone).

The approach that seems to have worked better is the same as that required
for C++ in general, *appropriate* use of features.  Whilst that is easier
to control in a corporate situation where programmers can be trained
properly, review by senior devs should catch the more egregious misuses
within Geany, its not like we have a huge developer base to train anyway :).


>
> Reasons:
>
> * No build problems for Long Term Support distros that don't support C99
> (but clearly do compile scintilla's C++98).
>

Neil is attempting to move Scintilla forward, it might soon be using C++03.5


>
> * RAII - this is a pretty essential feature for safe resource management.
> It's a stupid acronym though, it's basically automatic scoped destruction:
>
> http://en.wikipedia.org/wiki/**Resource_Acquisition_is_**Initialization


Agree on both the usefulness and the silly name :)


>
>
> * References can be useful in making code more readable vs pointers.
>

Unfortunately, since references are immutable, you can never get rid of
pointers in imperative style programs, that leads to code with a mix,
luckily getting it wrong (using . not ->) will be picked up by the compiler.


>
> * Developer enjoyment, productivity & gaining more experience with C++.
> (This might be an incentive for e.g. me to spend more time working on
> Geany). This has to be offset against those that might need to learn e.g.
> RAII.
>

Indeed there is a learning curve, but hopefully many will find that useful
and attractive.


>
> * Possibly we might use some STL containers internally.
>
>
Most definitely.



> * Possibly we could use a GObject wrapper for safe reference counting. I
> don't want to add any dependencies on C++ libraries though.
>

Or what almost all my C++03 programs have, a template headed:  /* The
ubiquitous intrusive reference counted smart pointer */ :)

Of course use gobject, for things that are gobjects, but don't bring it
into things that are not, the idea is to move to C++, not to tie more
closely to a C library.


>
> * Possibly we could have some template function utilities instead of
> unsafe macros. Although I think most header files should be kept C90
> compatible.
>

Yes existing headers that are used by the remaining C code will have to
remain C compatible, and will probably need:

#ifdef __cplusplus
extern "C" {
#endif

around them.

But (for C++ files) that doesn't prevent having extra headers with
templates in them.


>
> matt:
> > +1. While I'm also not sure it's a good idea in Geany and certainly
> > won't be pressing for it anytime soon, 90% of C++'s crumminess is due to
> > backwards compatibility with C, so I think it should be (theoretically,
> > not socially) possible to gradually transition from one to the other in
> > a project like Geany without too much pain.
>
> colomban:
> > I doubt it, C++ is sufficiently different from a C program not to be
> > compilable by a C++ compiler in many cases -- even if it is just for
> > some implicit casts C++ requires to be explicit (IIRC), and there are
> > plenty.  Or maybe it depends what "too much pain" means:)
>

So long as the gain is larger than the pain.


> >
> > Also, I doubt it's any kind of sensible either, b

Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Dimitar Zhekov]

On Mon, 26 Aug 2013 16:07:13 +0100
Nick Treleaven  wrote:

> I now think gradually using a (quite heavily restricted) subset of C++98 
> for *some* source files might be better than moving to C99 [...]
> 
> Reasons:
> 
> * RAII - this is a pretty essential feature for safe resource 
> management.

This works for global/static and auto classes. We can wrap a gchar *s
= g_strdup_printf() in a class, but I'd rather not... and you want to
ban "class".

> * References can be useful in making code more readable vs pointers.

But using both heavily (as GLib/GTK+ required pointers) will make it
harder to read.

> * Developer enjoyment, productivity & gaining more experience with C++. 
> (This might be an incentive for e.g. me to spend more time working on 
> Geany). This has to be offset against those that might need to learn 
> e.g. RAII.

Hmmm?..

> * Possibly we might use some STL containers internally.

There things are heavily templated. They generate more code,
compilation is slower, and (unless improved significantly from the last
time I tried them) the code is overall slower than using GArray/GList.
Moreover, you propose to ban "class".

> * Possibly we could use a GObject wrapper for safe reference counting.

Why? Where? How to do that without classes and destructors?
Note that gcc has a non-standard extension for RAII, which works with
the base C types. And Geany compiles with gcc only.

> * Possibly we could have some template function utilities instead of 
> unsafe macros.

Do we need these macros to work with different types? If not, "inline
is already declared in a portable manner in the GLib headers and can be
used normally."

> We would also need to disable some C++ features. I hoped we could do 
> that with g++ flags, but I've only found this so far:
> 
> -fno-rtti (disable runtime info for object inheritance)

+1. Earlier versions of Qt/KDE did that, don't know about current.

> There ought to be a way to disable mixed code and declarations, but 
> maybe not.

Not AFAIK.

> I don't know if this can be enforced by g++, but I suggest we disallow 
> these keywords:
> 
> class

There isn't, that's THE most basic feature of C++.
And you can write classes with struct and union.

> dynamic_cast

-fno-rtti

> friend

No classes -> no usage for friends.

> mutable
> operator

> throw

-fno-exceptions

> virtual

No classes -> no virtual methods.

> Thoughts?

Sorry, but IMHO, that seems even more pointless than using C99.

-- 
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel