Re: [osg-users] memory leak false positives on Windows
Tanguy, Robert, et al: Some good points have been raised by both sides. Singletons should be used carefully, but are still useful in certain circumstances. For the most part, it is a design decision - that is, it must be determined at the highest design level whether it makes sense to allow multiple instances of something to exist within a single process. Yes, only having one of some object may limit certain features, but the point is what the original design calls for - programs and libraries are not uber-omni-functional; they are designed for a specific purpose. It is best to maintain genericism, but only within the original purpose. Let's look at any registry-type object. Does it make sense within a design to have multiple registries? Well, this depends on the design. Is this registry intended to be a sort of index for objects or functions loaded at runtime? If this is the case, a singleton registry makes the most sense. It exists as a single object for any process, indexing all functions/object types/whatever with only the appropriate register and accessor functionality built-in. Certain forms of factory design may make good use of such a structure. But what if you want multiple index-type factories? Consider what little there is to be gained from having more than one of these objects - the ability to reference different objects/functions/etc by using the exact same identifier (key/index/whatever). But is it a good thing to even allow such ambiguity? That would mean that there were two items that registered using the same exact identifier, and both were accessible from the same calling application. Unless you have a very specific requirement to allow for non-unique identifiers, it would generally be seen as bad to have several distinct items referred to with the exact same identifier, only separated by the specific instance of an accessor/registry object. Sort of like having a global and a local variable with the exact same name, even though they denote entirely different things. Yes, you can do it, but why would you choose to it? Now, on the other hand, some type of global state-manager class may seem like a good candidate for singleton usage as well. However, this would only be true in the rare case where there absolutely cannot be more than one handled state. For example, a OGL context manager could seem to operate in a singleton capacity if you think in terms of a single window with a single context per application - and such thinking could be reasonable some years ago. But nowadays, we routinely open multiple windows with multiple contexts. Thus, a singleton is a poor choice here. Basically, IMO, singletons are suited to objects used only as interfaces to some other set of objects or functionality. For example, an API class for a DLL, as the only exposed interface containing accessor functions. Of course, if it only contains functions, then they could just be placed into a namespace without a class (and hence no singleton), but if resource reference counting or something similar was desired to track usage of the DLL API, then a singleton would make sense. Simiarlly, an auto-register factory class which loads some sort of plugin objects at runtime would make a lot of sense as a singleton. These are classes which contain minimal internal functionality, serving primarily to interface some indexed data. Oh, and to the question of how to reset the library; if you are using OSG in a runtime-loaded DLL, you could force a reload by freeing and loading the library fresh. (I don't have experience with dynamic linking in non-Windows environments, but there may be analogous procedures available in other systems.) Really, when you think about it, truly returning to the same clean slate you started when a library was first loaded is generally a complicated matter; if you really do need the original state, the best way to guarantee it is to completely reload the library itself. Yes, OSG could be equipped with the capability to fully clean up and reset itself, but that's a rather extreme task for a seldom-used case - if you absolutely have to have the library back in its original state (I'm not even sure the exact reason why you need everything fully reset), you should reload it. Matthew W Fuesz Software Engineer Asc Lockheed Martin STS -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=6719#6719 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Skylark wrote: Where: HeaderStart: #if defined(_MSC_VER) %% defined(OSG_DISABLE_MSVC_WARNINGS) #pragma warning(push) #pragma warning(disable: a b c d e f g) #endif HeaderEnd: #if defined(_MSC_VER) %% defined(OSG_DISABLE_MSVC_WARNINGS) #pragma warning(pop) #endif You can actually roll the pragamas all up into two macros - one to begin (push+disable) and one to end. e.g., in a common header, (osg/Export or whatever), include the following block: #ifdef _MSC_VER #define SUPPRESS_WARNINGS __pragma (warning(push)) __pragma (warning(disable : a b c d)) #define POP_WARNINGS __pragma (warning(pop)) #else #define SUPPRESS_WARNINGS #define POP_WARNINGS #endif Now, obviously, you could also define these macros to selectively suppress warnings in other compilers by including proper conditional switches for each in the above block. I myself do this often, and have a common macros header, which gets included pretty much everywhere, for this purpose (it also defines macros for declaration specifiers and other compiler- or OS-specific code features). Matthew W Fuesz Software Engineer Asc Lockheed Martin STS -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=6004#6004 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Eliminating VS warnings in external projects
Since I want to run at /W4 without warnings, I just push all OSG include directives back to /W2. That is, when including any OSG headers, I surround the #include calls with #pragma warning ( push, 2 ) and #pragma warning ( pop ) I have to do similar things with other third-party libraries I must leverage in some of my projects. Matthew W Fuesz Software Engineer Asc Lockheed Martin STS -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=5525#5525 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg/Export disabling MSVC deprecated warning
J-S Robert - with regard to C4251: As J-S has noted, C4251 is often generated for STL usage; in particular, C4251 is often errorneously generated for STL usage in *private* members or functions. STL usage in *public* members or functions in a DLL-exported class is problematic (as would be protected usage if the class is derived from outside of the DLL), but internal private usage of non-exportable elements such as STL is a non-issue. This production of DLL export warnings for inacessible/private members is a known VS quirk. The best approach to working with C4251 is to selectively disable it around class declarations which produce such false warnings. In some cases, C4251 may expose an actual problem in a DLL interface, and thus it should not be globally supressed, in general. Matthew W Fuesz Software Engineer Asc Lockheed Martin STS -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=5146#5146 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Warning level
Robert Osfield wrote:
Hi Sukender,
Code readability is key to spotting algorithm
errors, so any slip in readability is something to take very seriously
which is why the !=0 is not what I would deem a good programming
practice.
But I find that the '!= 0' produces far more readable code, when the convention
is consistently adhered to.
It is completely unambigous what is meant by a if ( (a=b) != 0 ) statement;
the intention was obviously to conditionally check the results of an
assignment. Without the explicit conditional, it may become ambiguous as to
whether the intention was to check on the assignment, or if it was a typo and
supposed to be just a conditional.
And if you would find a statement if ( (a==b) != 0 ), then you could catch
the comparison instead of assignment; likewise, if ( a=b ) was found, it would
indicate assignment instead of comparison. This holds, of course, only if
consistency is mainted and the standard of using != after the assignment is
adhered to.
As I said earlier, I prefer this way (explicit comparison) anyway - the fact
that it saves me the warning is an added benefit beyond the readability issue.
Of course, what is - IMO - the _absolutely_ most readable is to split the
statement in two - i.e., a = b; if ( a ) {}
Matthew W Fuesz
Software Engineer Asc
Lockheed Martin STS
--
Read this topic online here:
http://osgforum.tevs.eu/viewtopic.php?p=4303#4303
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Warning level
Robert Osfield wrote:
Following your logic we should also do:
if (bool_variable==true)
{
}
Rather than:
if (bool_variable)
{
}
Actually, no. No ambiguity of intent is present. Only when there arises a case
where both assignment or comparison operators are logical possibilities can
there be ambiguity as to the original intent of the statement.
As to the more general discussion, it is very apparent that we will never agree
on anything in this matter, as we have *drastically* different views of what
constitutes the most readable code.
Matthew W Fuesz
Software Engineer Asc
Lockheed Martin STS
--
Read this topic online here:
http://osgforum.tevs.eu/viewtopic.php?p=4325#4325
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Warning level
Skylark (J-S) wrote: I'm fine with suppressing C4706 as it's true that it's a warning that only tells you that you *might* be doing something unsafe... Whether it's actually safe or not is totally context-dependent. Blanket-supression of C4706 isn't really a good thing, since as you pointed out, it can actually point out an error (usually a typo by the developer). C4706 will not be generated if it is made explicitly clear what the intent of the conditional is. i.e., instead of checking if ( a = fxn() ), check if ( (a = fxn()) != 0 ). This is covered in the MSDN page on C4706. I actually prefer the latter syntax (which doesn't generate C4706) anyway, since it eliminates any possible confusion as to the intended operations. Matthew W Fuesz Software Engineer Asc Lockheed Martin STS -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=4253#4253 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Warning level
J-S, /W4 is generally sufficient. I run all of my projects at warning level 4, and effectively treat warnings as errors for my purposes. I don't enable /WX on the off chance that I get some crazy warning that I can't suppress and isn't meaningful in my application. I know of several such warnings for the linker (which are VERY annoying, and generally only deal with debug info), though I haven't actually come across any in the compiler. I suppose some of the warnings that are suppressed by default could be individually turned on if they were deemed beneficial, but this would require sorting through the list of default-off warnings and deciding whether we want each one on or off. My standard Win32 compile options, as relating to warnings, are the following: /D _CRT_SECURE_NO_DEPRECATE /D _CRT_SECURE_NO_WARNINGS /D _CRT_NONSTDC_NO_DEPRECATE /W4 So, set at warning level 4 with all of the crazy warnings about MS replacement of standard-C/C++ functions supressed. Matthew W Fuesz Software Engineer Asc Lockheed Martin STS -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=4138#4138 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Warning level
/Wall combined with any other /Wn option is redundant. /Wall enables *ALL* warnings, including those automatically supressed by VS under any other circumstances. /W1 through /W4 set the warning level; /Wall goes far beyond /W4 by enabling normally disabled warnings. I'm not sure if /Wall ignores #pragma warning supression as well, as I have never used it in any real situation. If it does ignore the #pragmas, then you would be getting even *more* warnings, on top of all of those that would otherwise be supressed by VS internally. Matthew W Fuesz Software Engineer Asc Lockheed Martin STS -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=4130#4130 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Warning level
/W4 on windows is far from useless, and can often point out some pretty big mistakes that the VS compiler just happens to find a way to take care of for you (outside of the C/C++ standard). I haven't built a newer version of OSG - my projects here are still relegated to running 2.6.0 for the time being - so I don't know what kinds of warnings are being generated currently. What are some of the dominant warning numbers that are appearing? I know C4251 can pop up a lot with DLL-based projects using STL, and is one of the most annoying warnings, generally best attacked with a limited-scope (and here, VS-conditional) pragma. Matthew W Fuesz Software Engineer Asc Lockheed Martin STS -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=3897#3897 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Warning level
Just did some checking on OSG VS settings, and there are some differences in the primary warning-supressing preprocessor options - once again, I'm not running the current version or latest dev build, so this may have changed. In OSG 2.6.0, the following are defined: _SCL_SECURE_NO_WARNINGS _CRT_SECURE_NO_DEPRECATE Whereas all of my VS Win32 projects are built with the following: _CRT_SECURE_NO_DEPRECATE _CRT_SECURE_NO_WARNINGS _CRT_NONSTDC_NO_DEPRECATE The SCL version (instead of the CRT version) has been known to not supress warnings for all C-standard functions, so this could be a contributing factor if the preprocessor defintions have not been changed since 2.6.0. BTW, all of my work is done in VS2005 (VC8). Matthew W Fuesz Software Engineer Asc Lockheed Martin STS -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=3898#3898 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Forum with Mailing list connection (Christmas Gift ; ) )
With regard to categorization (subforums): It could be possible to automatically manage this from the forum side. That is, any threads created in the forum could be tagged with an appropriate flag designating the originating categorical subforum when they are transcribed into mailing list messages. (This could just be in the subject line, or maybe elsewhere in the header.) Anything started in the forum could then be kept within categorical divisions, while everything originating from the mailing list would just wind up in General (unless the users were so inclined as to add the appropriate tag(s) to their mails). Just a thought. Matthew W Fuesz Software Engineer Asc Lockheed Martin STS -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=3821#3821 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3D Animation questions
osgATK (now osgAnimation, I believe) provides an animation-based nodekit. It should be a good starting point for looking into animation in OSG. Your first question seems somewhat contradictory. Vertex animation has traditionally referred to an older, obsolete style of animation based on saving the positions of all vertices, and manually manipulating each vertex to create the animation. Skinned animation, on the other hand, refers to a more modern animation method, based on weighted vertex maps (skins) tied to a set of skeletal animation bones. Only the bones are manipulated (and their data saved) in order to create (and describe) the animation. Are you currently looking for a method of skinned animation in OSG? Once again, I believe that osgAnimation provides the necessary tools to accomplish this. It may also provide the ability to determine the current frame or other animation state. I have no need for animation in my current use of OSG, so I can't offer any further help. Hopefully one of the osgATK/osgAnimation users (or developers) will be along shortly to provide more complete information on this subject. Matthew W Fuesz Software Engineer Asc Lockheed Martin STS -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=3826#3826 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
