In <list-933508@2rosenthals.com>, on 07/27/20
at 11:08 PM, "Dave Yeo" <cwmm-dev@2rosenthals.com> said:
Hi Dave,
>The som.hh included with VACPP3.08 has,
>// som.hh for DTS C++
>// SHD: May 27/94
If you review the VAC docs, you will find that DTS bindings are intended
for Visual Builder components. To me this means that the results of using
DTS for WPS applications will be indeterminate.
As you note the last time IBM generated this .hh was in 1994. I am 100%
certain there are residual defects in this code, just as there are in
other parts of VAC. The only question for these are what workarounds
might be available.
>Well, Chris uses .hh files and I did have that crash when trying an xh
>version, possibly due to not having enough string space, the .hh files
>use -S128000.
IIRC, the trap is in the compiler, not sc.exe. I cannot see how the
sc.exe -S value would have any effect on the compiler. More likely the
generated .hh is exposing a defect in the icc pre-processor. If you want
to track this down, you need to do the same thing we did for your mozilla
build issues. Start with a testcase that fails and start trimming code
until the issue goes away.
>Looking, I see intree, _wpobject.h, __wpobject.h which is about 8k
>smaller as well as wpobject.hh, need to investigate why one isn't
>getting included and still left wondering.
Maybe I am missing something, but the .h and .hh files are unrelated other
than that they may have generated from the same .idl. Also given that the
compiler has a number of DTS specific switches, it would not surprise me
if switch between .hh and .xih may require changes to the .cpp code that
implements your class. The user's of your class would not be affected by
this because a class user only references the .h file.
>There's other system files
>that Chris included and added a leading _ They're all pretty old.
Is this done by the makefiles? If so, this is probably so he could tell
one from the other.
>Those are only accessed by classes, need to access from mediafolder. I'm
>reluctant to mix them.
This is up to you. It's just another directory in the INCLUDE path.
>Some don't have corresponding idl files, and no code to build the ones
>using system idl files.
This may be an indicator of missing code. Too bad some folks diss-ed
Chris to the point where he is no longer available to even answer
questions.
>I'll assume using the toolkit versions is preferred.
Until proven otherwise, this would be my way to go.
back to list