Re: [osg-users] Change to Optimizer OptimizationOptions
Peter Hrenka wrote: Has anybody had a look at Qt's QFlags? http://doc.trolltech.com/4.5/qflags.html They provide a type-safe way of dealing with bit-mask-style enums. The implementation is mostly a template class with overloaded operators. Once you have the idea, it should be rather trivial to reimplement this from scratch and tailor it OSG's requirements. Wow, that's really interesting. I never imagined there were so many bitflag/mask patterns available. But I imagine you guys already know how I feel about this. :-) Personally, I already feel that using an enum to store bitflags is overkill. Defining an entire class to implement the bitflag/mask pattern along with set/get methods strikes me as the epitome of C++ abuse. I don't think I can back this, not even if measurements indicate no memory or performance bloat. It's an unnecessary layer of obfuscation. Using bitwise logic ops and unsigned bits/masks makes it perfectly clear what is happening, even at the assembly level. It reduces the potential for error and makes the code more readable. It works great in this simple form. It's not broke, and does not need to be fixed with a new C++ class. But I'm content to let Robert make the final call on this one. Clearly, we can't agree on a path forward ourselves. Further discussion is pointless; we should wait until he wraps up GL ES 2 and has time to respond to this issue. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Change to Optimizer OptimizationOptions
Paul Martz wrote: Personally, I already feel that using an enum to store bitflags is overkill. Defining an entire class to implement the bitflag/mask pattern along with set/get methods strikes me as the epitome of C++ abuse. I don't think I can back this, not even if measurements indicate no memory or performance bloat. It's an unnecessary layer of obfuscation. Using bitwise logic ops and unsigned bits/masks makes it perfectly clear what is happening, even at the assembly level. It reduces the potential for error and makes the code more readable. Oh, I love getting to wrangle theory with friends. ;) Wouldn't you think, though, that some code isn't actually concerned with thinking about bits, all it really cares about is state? Many times the bits in a bitmask are unrelated, and they're just grouped because you have several non-exclusive states you want to combine into a single member for storage efficiency. (I suspect the OptimizerOptions usage that originally spawned this discussion IS probably mostly-related state bits, so this may not apply). In the situation where they are unrelated state bits, being able to say stateBits.test(MY_STATE) it actually is perhaps more obvious and clear what's going on than doing it by hand with a bitwise operator. (I just can't resist stirring the pot... ;) -Paul -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Change to Optimizer OptimizationOptions
Chris 'Xenon' Hanson wrote: Oh, I love getting to wrangle theory with friends. ;) You can call me an idiot if you want, and I'll still buy you coffee. :-) In the situation where they are unrelated state bits, being able to say stateBits.test(MY_STATE) it actually is perhaps more obvious and clear what's going on than doing it by hand with a bitwise operator. I stand by my previous statement that it makes things less clear. Suppose you're debugging and you encounter that in the code as you step through the debugger. You now need to step in and make sure it's doing the right thing, whereas (stateBits MY_STATE) requires no debugging at all. This new class becomes just one more chunk of code to debug and vet. And if performance is an issue, I now have to wonder what the StateBits class compiled to, whereas I know that (stateBits MY_STATE) compiles to exactly one instruction. Sorry to disagree on this, but I would no sooner write my own class to hide the bitwise AND operator than I would write my own class to hide the 32-bit integer addition operator. Like I said, it's Robert's call, and we'll all go with what he says. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Change to Optimizer OptimizationOptions
On Wed, Nov 4, 2009 at 4:51 PM, Paul Martz pma...@skew-matrix.com wrote: Like I said, it's Robert's call, and we'll all go with what he says. From this day forth everyone should wear kilts and toss the caber, and work towards world peace and harmony ;-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Change to Optimizer OptimizationOptions
From this day forth everyone should wear kilts and toss the caber, and work towards world peace and harmony ;-) Absolutely! I agree with you on all points! Robert has spoken! ... but don't hate me if I had to Google to find out what toss the caber meant ... :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Change to Optimizer OptimizationOptions
Robert Osfield wrote: From this day forth everyone should wear kilts and toss the caber, and work towards world peace and harmony ;-) As long as I don't have to shave my legs. Robert. -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Change to Optimizer OptimizationOptions
Hi, Paul Martz schrieb: Hi Robert -- The code submission by Wojciech and I for MSFBO has opened a small can of worms on declaring bits and bitmasks. I hope you can weigh in and put an end to the debate. Has anybody had a look at Qt's QFlags? http://doc.trolltech.com/4.5/qflags.html They provide a type-safe way of dealing with bit-mask-style enums. The implementation is mostly a template class with overloaded operators. Once you have the idea, it should be rather trivial to reimplement this from scratch and tailor it OSG's requirements. Cheers, Peter Originally, my submission followed the Optimizer's OptimizationOptions pattern of declaring bit values in an enum, but declaring the bitmask variable as an unsigned int. In Wojciech's modified submission, he changed the bitmask variable to a signed int, with the reasoning that enum values are also signed ints, and this eliminates the need for a typecast to get rid of compiler warnings. This caused me to weigh in with the workaround of declaring the bit values as static const unsigned int, and keeping the bitmask unsigned. But this goes against the OSG precedent set with the Optimizer. The ensuing discussion has covered the merits, or lack thereof (depending on the poster) of declaring bitmasks as signed or unsigned. What this really boils down to is: If we decide that the MSFBO bit/bitmask declarations should be different from the Optimizer pattern for bits and bitmasks, then we should change the Optimizer to follow the new standard, and also do the same for any other classes that followed the Optimizer's current pattern. If you could post with do it this way or do it that way, I (for one) could get back to work and stop prodding everyone with my code style opinions. :-) Thanks, -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Change to Optimizer OptimizationOptions
Peter Hrenka wrote: Has anybody had a look at Qt's QFlags? http://doc.trolltech.com/4.5/qflags.html They provide a type-safe way of dealing with bit-mask-style enums. The implementation is mostly a template class with overloaded operators. Once you have the idea, it should be rather trivial to reimplement this from scratch and tailor it OSG's requirements. I'm not familiar with it, but I agree that perhaps a flags class/template would be a smart way to clean up the situation. If it would solve the issues. I know I'm always happier using a provided set/test API than manually masking stuff. As long as it doesn't bloat the data size beyond the simple storage of the flag word. as long as we don't make any of it virtual, I think it would be ok. Though I don't know how RTTI adds to the class per-instance weight of a real class (as opposed to a built-in type like unsigned long int). Any C++ guru care to comment on that? -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Change to Optimizer OptimizationOptions
Hi Chris, Chris 'Xenon' Hanson schrieb: Peter Hrenka wrote: Has anybody had a look at Qt's QFlags? http://doc.trolltech.com/4.5/qflags.html They provide a type-safe way of dealing with bit-mask-style enums. The implementation is mostly a template class with overloaded operators. Once you have the idea, it should be rather trivial to reimplement this from scratch and tailor it OSG's requirements. I'm not familiar with it, but I agree that perhaps a flags class/template would be a smart way to clean up the situation. If it would solve the issues. I know I'm always happier using a provided set/test API than manually masking stuff. As long as it doesn't bloat the data size beyond the simple storage of the flag word. as long as we don't make any of it virtual, I think it would be ok. Though I don't know how RTTI adds to the class per-instance weight of a real class (as opposed to a built-in type like unsigned long int). Any C++ guru care to comment on that? Nothing needs to be virtual here. It's just a template class with overloaded operators which means everything is effectively inlined. We could also use an unsigned int as internal storage type (Qt seems to use a signed int). Cheers, Peter -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Change to Optimizer OptimizationOptions
Peter Hrenka wrote: Nothing needs to be virtual here. It's just a template class with overloaded operators which means everything is effectively inlined. We could also use an unsigned int as internal storage type (Qt seems to use a signed int). But doesn't RTTI embed a hidden pointer (similr to the vftbl) into every class as well, that points to the common per-class ID/metadata? I guess quibbling about an extra pointer is very old-skool 80s coder of me. You can have my VIC-20 when I'm done porting OpenGL ES 1.0 to it! ;) -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Change to Optimizer OptimizationOptions
IMHO This is the best option so far ;-). I like it. Wojtek - Original Message - From: Peter Hrenka p.hre...@science-computing.de To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Tuesday, November 03, 2009 6:31 PM Subject: Re: [osg-users] Change to Optimizer OptimizationOptions Hi Chris, Chris 'Xenon' Hanson schrieb: Peter Hrenka wrote: Has anybody had a look at Qt's QFlags? http://doc.trolltech.com/4.5/qflags.html They provide a type-safe way of dealing with bit-mask-style enums. The implementation is mostly a template class with overloaded operators. Once you have the idea, it should be rather trivial to reimplement this from scratch and tailor it OSG's requirements. I'm not familiar with it, but I agree that perhaps a flags class/template would be a smart way to clean up the situation. If it would solve the issues. I know I'm always happier using a provided set/test API than manually masking stuff. As long as it doesn't bloat the data size beyond the simple storage of the flag word. as long as we don't make any of it virtual, I think it would be ok. Though I don't know how RTTI adds to the class per-instance weight of a real class (as opposed to a built-in type like unsigned long int). Any C++ guru care to comment on that? Nothing needs to be virtual here. It's just a template class with overloaded operators which means everything is effectively inlined. We could also use an unsigned int as internal storage type (Qt seems to use a signed int). Cheers, Peter -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Change to Optimizer OptimizationOptions
Hi Chris,
Chris 'Xenon' Hanson schrieb:
Peter Hrenka wrote:
Nothing needs to be virtual here. It's just a template class
with overloaded operators which means everything is effectively
inlined. We could also use an unsigned int as internal storage type
(Qt seems to use a signed int).
But doesn't RTTI embed a hidden pointer (similr to the vftbl) into every
class as well,
that points to the common per-class ID/metadata?
Boy, you're paranoid. Well, sometimes that's a good thing ;-)
My understanding is that as long as you do not have virtual
methods or derive (directly or indirectly) from a class that
has virtual methods, there is no overhead in the memory layout
of the class instances.
But of course, I cannot guess what stange compilers will do...
The example programm gives me the following output on
64-bit gcc on Linux:
EnumSize: 4
EnumFlagsSize: 4
EnumFlagsArraySize: 40
PlainClass: 4
VirtualClass: 16
So the template class does not use more memory than the plain enum
(on this platform).
I guess quibbling about an extra pointer is very old-skool 80s coder of me.
You can have
my VIC-20 when I'm done porting OpenGL ES 1.0 to it! ;)
No, your concerns are valid. As you can see the virtual method adds a
factor of 4 in memory usage to the VirtualClass as compared
to the PlainClass in the example.
Cheers,
Peter
--
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Roland Niemeier,
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Michel Lepert
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196
#include iostream
enum MyFlags {
ONE = (10),
TWO = (11),
TREE = (12)
};
templateclass enumType
class EnumFlags {
private:
unsigned int _flags;
};
class PlainClass {
void foo() {}
int _data;
};
class VirtualClass {
virtual void foo() {}
int _data;
};
int main(int argc, char* argv[]) {
std::cout EnumSize: sizeof(MyFlags) std::endl;
std::cout EnumFlagsSize: sizeof(EnumFlagsMyFlags) std::endl;
EnumFlagsMyFlags enumArray[10];
std::cout EnumFlagsArraySize: sizeof(enumArray) std::endl;
PlainClass p;
VirtualClass v;
std::cout PlainClass: sizeof(p) std::endl;
std::cout VirtualClass: sizeof(v) std::endl;
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Change to Optimizer OptimizationOptions
Paul Martz wrote: In Wojciech's modified submission, he changed the bitmask variable to a signed int, with the reasoning that enum values are also signed ints, and this eliminates the need for a typecast to get rid of compiler warnings. This caused me to weigh in with the workaround of declaring the bit values as static const unsigned int, and keeping the bitmask unsigned. But this goes against the OSG precedent set with the Optimizer. I see both sides here. My only input would be that some IDEs (VC++ among them, I believe) have better facilities for understanding and displaying constants defined as enums than as const variables. For example if I have an enum of FOO defined as 4, and I have a variable of the enumerated type containing 4, the debugger will display it to me as FOO (4) which is more meaningful than just (4). However, with bitmasks, you'll hardly ever have just a single bit set, so the IDE's enum interpretation ability kind of goes out the window. So, I'd lean towards whatever makes the cleanest reading and compiling code. It seems to me like this would be the static const unsigned int. No ugly casts when used, no ugly warnings when compiled. But if the same thing can already be achieved with the enum+signed technique, then I'm ok to leave well enough alone. If you could post with do it this way or do it that way, I (for one) could get back to work and stop prodding everyone with my code style opinions. :-) Ooh, we could start a whole new OSG list just for code style fights and then unearth the old extensionless headers arguments on the first day of each month just for fun! In this corner, the defending champion, Decorator Pattern and on the opposite side of the ring, the visiting challenger, VISITOR! Thanks, -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Change to Optimizer OptimizationOptions
Hi, If you could post with do it this way or do it that way, I (for one) could get back to work and stop prodding everyone with my code style opinions. :-) Ooh, we could start a whole new OSG list just for code style fights and then unearth the old extensionless headers arguments on the first day of each month just for fun! In this corner, the defending champion, Decorator Pattern and on the opposite side of the ring, the visiting challenger, VISITOR! :-) We could also have a bi-monthly singleton free-for-all... jp -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Change to Optimizer OptimizationOptions
On 29/10/09 10:55 PM, Paul Martz wrote:
Hi Robert -- The code submission by Wojciech and I for MSFBO has opened
a small can of worms on declaring bits and bitmasks. I hope you can
weigh in and put an end to the debate.
Originally, my submission followed the Optimizer's OptimizationOptions
pattern of declaring bit values in an enum, but declaring the bitmask
variable as an unsigned int.
In Wojciech's modified submission, he changed the bitmask variable to a
signed int, with the reasoning that enum values are also signed ints,
and this eliminates the need for a typecast to get rid of compiler
warnings.
This caused me to weigh in with the workaround of declaring the bit
values as static const unsigned int, and keeping the bitmask unsigned.
But this goes against the OSG precedent set with the Optimizer.
Just to add more confusion (and yet-another-solution):
StateAttribute defines 'enum Values { OFF, ON, PROTECT, OVERRIDE }' but also defines
'typedef unsigned int GLModeValues'.
StateSet::setAttributeAndModes accepts an argument of GLModeValues which is supposed to
contain bitwise-ored StateAttribute::Values.
As I remember there was never any controversy about doing it this way, although this isn't
necessarily what you would like it to be (but C++ enums are broken in that respect).
Cheers,
/ulrich
PS: AFAIK StateSet/StateAttribute predate Optimizer ;-)
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Change to Optimizer OptimizationOptions
Hi Robert -- The code submission by Wojciech and I for MSFBO has opened a small can of worms on declaring bits and bitmasks. I hope you can weigh in and put an end to the debate. Originally, my submission followed the Optimizer's OptimizationOptions pattern of declaring bit values in an enum, but declaring the bitmask variable as an unsigned int. In Wojciech's modified submission, he changed the bitmask variable to a signed int, with the reasoning that enum values are also signed ints, and this eliminates the need for a typecast to get rid of compiler warnings. This caused me to weigh in with the workaround of declaring the bit values as static const unsigned int, and keeping the bitmask unsigned. But this goes against the OSG precedent set with the Optimizer. The ensuing discussion has covered the merits, or lack thereof (depending on the poster) of declaring bitmasks as signed or unsigned. What this really boils down to is: If we decide that the MSFBO bit/bitmask declarations should be different from the Optimizer pattern for bits and bitmasks, then we should change the Optimizer to follow the new standard, and also do the same for any other classes that followed the Optimizer's current pattern. If you could post with do it this way or do it that way, I (for one) could get back to work and stop prodding everyone with my code style opinions. :-) Thanks, -- Paul Martz Skew Matrix Software LLC _http://www.skew-matrix.com_ http://www.skew-matrix.com/ +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
