(1) your indents are not completely according to the coding standard:
usually the doxygen comments are also indented, and the new
Oh - OK, I didn't know that.
fl_gc code
looks as if it has indents of 4.
Ah, sorry, that'll be wrong tab settings on my editor I suspect...
(2) When we
MacArthur, Ian (SELEX GALILEO, UK) wrote:
Also - would it be worthwhile pointing to the similar-but-different
fl_measure (and perhaps fl_width, fl_height) too?
I think so, especially if you write something in the text about the
differences. However, mentioning it in the text would (IMHO)
Well - I've tried to add the comments as outlined... Here's hoping.
Comments, advice, feedback welcome...
--
Ian
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
On 10 Feb 2009, at 20:07, Albrecht Schlosser wrote:
In this special case however I'm not sure _where_ to put the docs:
They
should be there, where the implementation is: inline methods in the
header file, other methods in the .cxx file. But here we have three
different implementations in
Indeed - I can write the words, and generate a screenshot,
but have no
idea how to get them into the docs...
Writing the doxygen docs is not that difficult. There are enough
examples, and there are some hints in the developer section
of the docs.
In this special case however I'm
MacArthur, Ian (SELEX GALILEO, UK) wrote:
Indeed - I can write the words, and generate a screenshot, but have no
idea how to get them into the docs...
Writing the doxygen docs is not that difficult. There are enough
examples, and there are some hints in the developer section of the docs.
In
Interesting.. if I gather the gist of the patch correctly,
it looks like the change is to avoid having the void function
return() a function that returns a void.
Which seems to compile OK with 'g++ -Wall' on my linux
systems, eg. no compile errors for this:
Interesting.. if I gather the gist of the patch correctly,
it looks like the change is to avoid having the void function
return() a function that returns a void.
=20
Which seems to compile OK with 'g++ -Wall' on my linux
systems, eg. no compile errors for this:
=20
I'm sort of wondering which compiler variants do/don't=20
allow that style
of usage...
=20
Me too. Which compiler did _not_ like it?
This one complained:
$ gcc -v
Reading specs from d:/MinGW/bin/../lib/gcc/mingw32/3.4.2/specs
VC6 is not happy too, and has another problem compiling
Fabien Costantini wrote:
Yes I'm afraid I do,
look at the diff file below needed for fixing current svn ...
- if (c) return fl_text_extents(c, strlen(c), dx, dy, w, h);
[..]
+ if (c) fl_text_extents(c, strlen(c), dx, dy, w, h);
Interesting.. if I gather the gist of the patch
I'll apply the following patch shortly (compiled okay on my
cygwin box with gcc
3.4.4).
Index: src/fl_font_win32.cxx
===
--- src/fl_font_win32.cxx (revision 6534)
+++ src/fl_font_win32.cxx (working copy)
@@
FWIW, I had a quick look and it compiled ok on vc2005, too.
Fabien
Thanks Fabien,
I do think it is odd though - it seems that some iterations of gcc/mingw
permit this style, others do not, and now you report that vc2005 is OK
with it...
Still, I guess we need to code safely though!
Cheers,
I'm sort of wondering which compiler variants do/don't
allow that style
of usage...
Me too. Which compiler did _not_ like it?
This one complained:
$ gcc -v
Reading specs from d:/MinGW/bin/../lib/gcc/mingw32/3.4.2/specs
SELEX Sensors and Airborne Systems Limited
Registered Office:
FWIW, I had a quick look and it compiled ok on vc2005, too.
Fabien
One question; did the previous version compile OK for you?
I'm sort of wondering which compiler variants do/don't allow that style
of usage...
Cheers,
--=20
Ian
___
fltk-dev
14 matches
Mail list logo
