Build report - 20050713-0000
= Analysis Report for inkscape =
Platform Unpack Config Build Install WRNS ERRS ------------------------------------------------------------------------ debian x86 0 0 0 0 5 0
Test Status Score Info ------------------------------------------------------------------------ sut-1 ??
== Errors ==
none
== Warnings ==
display/canvas-arena.cpp:91: warning: invalid access to non-static data member display/canvas-arena.cpp:91: warning: (perhaps the `offsetof' macro was used display/sp-canvas.cpp:112: warning: invalid access to non-static data member ` display/sp-canvas.cpp:112: warning: (perhaps the `offsetof' macro was used libnrtype/Layout-TNG-Output.cpp:226: warning: enumeration value `
== Environment Summary ==
On 7/13/05, Bryce Harrington <bryce@...260...> wrote:
display/canvas-arena.cpp:91: warning: invalid access to non-static data member display/canvas-arena.cpp:91: warning: (perhaps the `offsetof' macro was used display/sp-canvas.cpp:112: warning: invalid access to non-static data member ` display/sp-canvas.cpp:112: warning: (perhaps the `offsetof' macro was used
I'm quite tired of seeing these warnings and complaints about them. They are there for ages. Can some C/C++ guru finally fix them please? We even have a bug opened for them.
On Wed, Jul 13, 2005 at 05:10:03PM -0300, bulia byak wrote:
On 7/13/05, Bryce Harrington <bryce@...260...> wrote:
display/canvas-arena.cpp:91: warning: invalid access to non-static data member display/canvas-arena.cpp:91: warning: (perhaps the `offsetof' macro was used display/sp-canvas.cpp:112: warning: invalid access to non-static data member ` display/sp-canvas.cpp:112: warning: (perhaps the `offsetof' macro was used
I'm quite tired of seeing these warnings and complaints about them. They are there for ages. Can some C/C++ guru finally fix them please? We even have a bug opened for them.
The most obvious fix would be to change to sigc++ signals. This involves quite a bit of code change, so would be a post-0.42 change.
There may be a more local fix available (e.g. similar code elsewhere in Inkscape doesn't generate a warning), but it isn't obvious to me.
pjrm.
You wrote
display/sp-canvas.cpp:112: warning: (perhaps the `offsetof' macro was used
There may be a more local fix available (e.g. similar code elsewhere in Inkscape doesn't generate a warning), but it isn't obvious to me.
I thought I read a list message pointing to a thread on the GCC list (as it was pointed out to be a GCC problem) but can't find that anymore.
ralf
On 7/14/05, Ralf Stephan <ralf@...748...> wrote:
You wrote
display/sp-canvas.cpp:112: warning: (perhaps the `offsetof' ...
There may be a more local fix available (e.g. similar code elsewhere in Inkscape doesn't generate a warning), but it isn't obvious to me.
I thought I read a list message pointing to a thread on the GCC list (as it was pointed out to be a GCC problem) but can't find that anymore.
There is some truth in that: Older versions of GCC did not report the error properly. According to the C++ standard, we cannot use 0 as the address of a non-POD object. This causes (amongst other things) the offsetof macro to fail on objects with constructors.
Whilst most, if not all, compilers generate correct code - that is, treat this as a warning rather than an error - really we should not use C macros in C++ code.
Probably the best solution is the first one suggested: Move to gtkmm (use C++ techniques throughout). Another possibility would be to move all code requiring the offsetof macro to .c files. Certainly if you can identify what makes the offending cases non-POD and remove it, then that would work as well.
I would suggest that until the best solution is in place, we just live with the warnings.
On Sat, Jul 16, 2005 at 11:59:40AM +0100, Ben Fowler wrote:
Probably the best solution is the first one suggested: Move to gtkmm (use C++ techniques throughout). Another possibility would be to move all code requiring the offsetof macro to .c files. Certainly if you can identify what makes the offending cases non-POD and remove it, then that would work as well.
I would suggest that until the best solution is in place, we just live with the warnings.
Sounds like a decent strategy.
Currently, the only major hard part about converting the remaining dialogs to gtkmm is for someone to develop a good solution for handling tree-based dialogs. I.e., a dialog that allows browsing an SPRepr class, as the XML dialog currently does. This looks like a pretty challenging thing to do, but once someone's invented a feasable structure for handling these kinds of dialogs, then people will be able to copy that approach for doing other tree-oriented dialogs, like Preferences, Layer manager, and so forth. There are also some dialogs like the Extensions manager, that would be better implemented as tree views. So there's a good bit hinging on this one problem.
Beyond the dialogs, there's a good bit of work to get the core classes converted over, however much of the work looks pretty straightforward, just time consuming.
Bryce
On Sat, 2005-07-16 at 14:53 -0700, Bryce Harrington wrote:
Sounds like a decent strategy.
Currently, the only major hard part about converting the remaining dialogs to gtkmm is for someone to develop a good solution for handling tree-based dialogs. I.e., a dialog that allows browsing an SPRepr class, as the XML dialog currently does. This looks like a pretty challenging thing to do, but once someone's invented a feasable structure for handling these kinds of dialogs, then people will be able to copy that approach for doing other tree-oriented dialogs, like Preferences, Layer manager, and so forth.
Well, for simple stuff like Preferences or Extensions, the GTK+ tree API is pretty straightforward. Someone just needs to read the documentation and tutorials.
The XML/SPObject/Layer dialogs are a little more complicated only because I intend to wrap the XML/Object tree directly rather than using an intermediate model (which would potentially double or triple the memory burden for a large document).
-mental
participants (6)
-
Ben Fowler -
Bryce Harrington -
bulia byak -
MenTaLguY -
Peter Moulder -
Ralf Stephan