Hello,

I was recently working on upgrading compilers from VC10 to VC12, and came across the following regression when exporting *.osgt files.

VC10:

osg::Group {
  UniqueID 1
  Children 5 {
    osg::Group {
      UniqueID 2
      Children 3 {
        osg::Switch {
          UniqueID 3
          UpdateCallback TRUE {
            osg::NodeCallback {
              UniqueID 4
            }
          }
          Children 2 {
            osg::Group {
              UniqueID 5
              UpdateCallback TRUE {
                osg::NodeCallback {
                  UniqueID 6
                }
              }
              Children 1 {
                osg::Geode {
<snip>

VC12:

#Ascii Scene
#Version 100
#Generator OpenSceneGraph 3.2.1

osg::Group {
  UniqueID 1
  Children 5 {
osg::Group {
      UniqueID 2
      Children 3 {
osg::Switch {
          UniqueID 3
          UpdateCallback TRUE {
osg::NodeCallback {
              UniqueID 4
            }
          }
Children 2 {
osg::Group {
              UniqueID 5
              UpdateCallback TRUE {
osg::NodeCallback {
                  UniqueID 6
                }
              }
Children 1 {
osg::Geode {
<snip>

Notice that the indentation has changed between VC10 and VC12 unexpectedly. I have traced the problem to OutputIterator::isEndl() in the osgDB/StreamOperator header. In VC10, the "fn" variable comes from msvcp100.dll for all calls to isEndl(). In VC12, some calls show "fn" coming from osg100-osgdb.dll, and some calls come from osgdb_serializers_osg.dll. Thus, the std::endl() address does not match (and the function returns false) if "fn" originates from osgdb_serializers_osg.dll.

Applying the __sun workaround does appear to fix the problem. I am leaning towards thinking that the address check logic is not portable due to most of the functions involved being inline. This is particularly problematic since the osgdb_serializers_osg library is explicitly linked, and therefore, the one definition rule behavior cannot be applied by the linker when linking the application or other OSG dlls.

Perhaps there is a better way to "detect" std::endl, or refrain from having to detect std::endl entirely?

Regards,

Judson
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Reply via email to