xml-cppdom-devel — Developer list

[xml-cppdom-devel] Splitting up cppdom.h

[Patrick H. <pa...@13...>]

I am planning to implement automatic linking for CppDOM when building wit=
h
Visual C++, but I have run into what may be a significant problem. I thin=
k
that the fact that nearly all the CppDOM declarations are in cppdom.h
results in unnecessary exposure of information to code built on top of
CppDOM. That has not necessarily been an issue before, but with automatic=

linking, any code that includes a header that includes cppdom.h ends up
being built in such a way that it gets linked against cppdom.lib (or
whichever variant is used).

Consider the case of two pieces of code, A and B, where A is a library an=
d B
is an application. If A is using CppDOM internally, it has to be linked
against cppdom.lib. B, on the other hand, is not using CppDOM at all but =
is
just using the higher level interface provided by A. From what I have see=
n
over the last 2+ years, B should not have to be linked against cppdom.lib=

explicitly, though it would of course have to be linked against A.lib.

Implementing automatic linking with CppDOM as it is currently structured
means putting the #pragma directive in cppdom.h along with everything els=
e.
Since a library using CppDOM has no convenient mechanism for forward
declarations, the library's headers that use cppdom.h expose the whole
CppDOM API along with its own API even when this is totally unnecessary.
What I want to do is break up cppdom.h into a collection of headers (Node=
=2Eh,
NodePtr.h, Document.h, DocumentPtr.h, etc.) and corresponding implementat=
ion
files. At that point, cppdom.h would be a way to get all the CppDOM
declarations just as it is now, thus allowing full backwards compatibilit=
y
for existing code. However, code using CppDOM could be updated so as not =
to
expose the whole CppDOM API through the use of conveniently and centrally=

defined forward declarations.

My question, then, is this: are there any objections to this effort?
Frankly, it has always annoyed me that cppdom.h is a catch-all for just
about the whole CppDOM API, and this new issue is the proverbial last str=
aw
for me. Nevertheless, I do not want to spend the time splitting up the
cppdom.h if other people would prefer that the code remain structured as =
it
is. I can implement the automatic linking without splitting up cppdom.h, =
but
it will mean that CppDOM will be exposed indirectly/inadvertently (in the=

form of preprocessor symbols and linker options) to code that did not
previously need to know anything about it. Not implementing automatic
linking means that Windows users would have to identify the specific vers=
ion
of CppDOM's .lib file against which they want to link.

 -Patrick


--=20
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2oum9          | http://www.infiscape.com/

Re: [xml-cppdom-devel] [xml-cppdom-checkins] cvs commit: cppdom ChangeLog SConstruct

[Allen B. <al...@vr...>]

Patrick Hartling wrote:

>When do you plan to update the SConsAddons copy that is in
>cppdom/tools/scons-addons and restore its use?
>  
>
I hope to update it by next Thursday or Friday. 

I would have updated it this time but the code is going to be changing 
so much it seemed like a waste for now.  Once things stabilize it will 
be updated.

-Allen

> -Patrick
>
>Allen Bierbaum wrote:
>  
>
>>allenb      2006/06/30 15:58:59 PDT
>>
>>  Modified files:
>>    .                    ChangeLog SConstruct 
>>  Log:
>>  - Update the build to use the alpha EnvironmentBuilder from scons-addons
>>     note: this project is being used to test and develop this part of scons-addons
>>           so things could be a little unstable for a bit.  It works now, but
>>           the code is in development.
>>  - The SCons build can now build the library on win32.
>>  
>>  Revision  Changes    Path
>>  1.46      +3 -0      cppdom/ChangeLog
>>  1.57      +50 -55    cppdom/SConstruct
>>
>>http://xml-cppdom.cvs.sourceforge.net/xml-cppdom/cppdom/ChangeLog.diff?r1=1.45&r2=1.46&diff_format=h
>>http://xml-cppdom.cvs.sourceforge.net/xml-cppdom/cppdom/SConstruct.diff?r1=1.56&r2=1.57&diff_format=h
>>
>>Using Tomcat but need to do more? Need to support web services, security?
>>Get stuff done quickly with pre-integrated technology to make your job easier
>>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>_______________________________________________
>>Xml-cppdom-checkins mailing list
>>Xml...@li...
>>https://lists.sourceforge.net/lists/listinfo/xml-cppdom-checkins
>>    
>>
>
>
>  
>

Re: [xml-cppdom-devel] [xml-cppdom-checkins] cvs commit: cppdom ChangeLog SConstruct

[Patrick H. <pa...@13...>]

When do you plan to update the SConsAddons copy that is in
cppdom/tools/scons-addons and restore its use?

 -Patrick

Allen Bierbaum wrote:
> allenb      2006/06/30 15:58:59 PDT
>=20
>   Modified files:
>     .                    ChangeLog SConstruct=20
>   Log:
>   - Update the build to use the alpha EnvironmentBuilder from scons-add=
ons
>      note: this project is being used to test and develop this part of =
scons-addons
>            so things could be a little unstable for a bit.  It works no=
w, but
>            the code is in development.
>   - The SCons build can now build the library on win32.
>  =20
>   Revision  Changes    Path
>   1.46      +3 -0      cppdom/ChangeLog
>   1.57      +50 -55    cppdom/SConstruct
>=20
> http://xml-cppdom.cvs.sourceforge.net/xml-cppdom/cppdom/ChangeLog.diff?=
r1=3D1.45&r2=3D1.46&diff_format=3Dh
> http://xml-cppdom.cvs.sourceforge.net/xml-cppdom/cppdom/SConstruct.diff=
?r1=3D1.56&r2=3D1.57&diff_format=3Dh
>=20
> Using Tomcat but need to do more? Need to support web services, securit=
y?
> Get stuff done quickly with pre-integrated technology to make your job =
easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geron=
imo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> Xml-cppdom-checkins mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xml-cppdom-checkins


--=20
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2oum9          | http://www.infiscape.com/

[xml-cppdom-devel] CppDOM 0.6.4 released

[Patrick H. <pa...@13...>]

Several builds of the CppDOM 0.6.4 release has just been posted on
SourceForge. This release has a fairly important bug fix for compile-time=

errors seen related to the declarations of cppdom::NodePtr and
cppdom::DocumentPtr. The big change in this release is the support for
universal binaries on Mac OS X, and there is a universal binary of this
release posted on SourceForge.

 -Patrick


--=20
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2oum9          | http://www.infiscape.com/

Re: [xml-cppdom-devel] Shared library naming problem

[Patrick H. <pa...@13...>]

I assume you mean the CVS HEAD version. I am referring to the 0.6 branch =
as
I have not yet tested 0.7 on Mac OS X. I have a workaround for this probl=
em
that does not require modifying AutoDist.py; I just wanted to know if the=

way that AutoDist is calling SCons' StaticLibrary() and SharedLibrary()
functions is valid.

 -Patrick

Allen Bierbaum wrote:
> The CVS version has had AutoDist removed and I do not recommend using=20
> AutoDist any more.  There are a number of dubious things that it does=20
> and IMHO it just adds more complexity to the build then is needed.=20
>=20
> Please let me know if the problem still occurs in CVS.
>=20
> -Allen
>=20
> Patrick Hartling wrote:
>=20
>> For a while now, I have seen intermittent problems with the CppDOM sha=
red
>> library on Mac OS X. Every once in a while, I get an error when runnin=
g an
>> application where the run-time loader complains that it cannot find
>> "build.../cppdom/libcppdom.dylib" when one would expect it to be looki=
ng for
>> just plain "libcppdom.dylib".
>>
>> I tried tracking this down, and I think it might have something to do =
with
>> the AutoDist stuff in SConsAddons. Specifically, where SCons is told t=
he
>> name of the shared and static libraries to create, it appears to be gi=
ven an
>> absolute path rather than just the name of the shared library to creat=
e. Not
>> being an SCons expert, I don't know if this is a valid usage of
>> StaticLibrary() and SharedLibrary(), but it doesn't seem very correct =
to me.
>> The reason given in a comment about why an absolute path is used seems=

>> rather dubious to me, too:
>>
>>   Use get_abspath() with fileNode so we get the path into the build_di=
r and
>>   not src dir
>>
>> Isn't it the job of SCons to figure out where to build things? I thoug=
ht
>> that was what BuildDir() was for. I changed line 432 of AutoDist.py fr=
om
>>
>>   lib =3D self.env.__dict__[lib_builder](lib_filepath, self.sources)
>>
>> to
>>
>>   lib =3D self.env.__dict__[lib_builder](self.fileNode.name, self.sour=
ces)
>>
>> Things appear to me to build correctly (at least with SCons 0.96.92). =
Am I
>> missing something?
>>
>> -Patrick
>>
>>
>> =20
>>
>> ----------------------------------------------------------------------=
--
>>
>> Using Tomcat but need to do more? Need to support web services, securi=
ty?
>> Get stuff done quickly with pre-integrated technology to make your job=
 easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache Gero=
nimo
>> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&da=
t=3D121642
>>
>> ----------------------------------------------------------------------=
--
>>
>> _______________________________________________
>> Xml-cppdom-devel mailing list
>> Xml...@li...
>> https://lists.sourceforge.net/lists/listinfo/xml-cppdom-devel
>> =20
>>
>=20
>=20
> Using Tomcat but need to do more? Need to support web services, securit=
y?
> Get stuff done quickly with pre-integrated technology to make your job =
easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geron=
imo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> Xml-cppdom-devel mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xml-cppdom-devel


--=20
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2oum9          | http://www.infiscape.com/

Re: [xml-cppdom-devel] Shared library naming problem

[Allen B. <al...@vr...>]

The CVS version has had AutoDist removed and I do not recommend using 
AutoDist any more.  There are a number of dubious things that it does 
and IMHO it just adds more complexity to the build then is needed. 

Please let me know if the problem still occurs in CVS.

-Allen

Patrick Hartling wrote:

>For a while now, I have seen intermittent problems with the CppDOM shared
>library on Mac OS X. Every once in a while, I get an error when running an
>application where the run-time loader complains that it cannot find
>"build.../cppdom/libcppdom.dylib" when one would expect it to be looking for
>just plain "libcppdom.dylib".
>
>I tried tracking this down, and I think it might have something to do with
>the AutoDist stuff in SConsAddons. Specifically, where SCons is told the
>name of the shared and static libraries to create, it appears to be given an
>absolute path rather than just the name of the shared library to create. Not
>being an SCons expert, I don't know if this is a valid usage of
>StaticLibrary() and SharedLibrary(), but it doesn't seem very correct to me.
>The reason given in a comment about why an absolute path is used seems
>rather dubious to me, too:
>
>   Use get_abspath() with fileNode so we get the path into the build_dir and
>   not src dir
>
>Isn't it the job of SCons to figure out where to build things? I thought
>that was what BuildDir() was for. I changed line 432 of AutoDist.py from
>
>   lib = self.env.__dict__[lib_builder](lib_filepath, self.sources)
>
>to
>
>   lib = self.env.__dict__[lib_builder](self.fileNode.name, self.sources)
>
>Things appear to me to build correctly (at least with SCons 0.96.92). Am I
>missing something?
>
> -Patrick
>
>
>  
>
>------------------------------------------------------------------------
>
>Using Tomcat but need to do more? Need to support web services, security?
>Get stuff done quickly with pre-integrated technology to make your job easier
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Xml-cppdom-devel mailing list
>Xml...@li...
>https://lists.sourceforge.net/lists/listinfo/xml-cppdom-devel
>  
>

[xml-cppdom-devel] Shared library naming problem

[Patrick H. <pa...@13...>]

For a while now, I have seen intermittent problems with the CppDOM shared=

library on Mac OS X. Every once in a while, I get an error when running a=
n
application where the run-time loader complains that it cannot find
"build.../cppdom/libcppdom.dylib" when one would expect it to be looking =
for
just plain "libcppdom.dylib".

I tried tracking this down, and I think it might have something to do wit=
h
the AutoDist stuff in SConsAddons. Specifically, where SCons is told the
name of the shared and static libraries to create, it appears to be given=
 an
absolute path rather than just the name of the shared library to create. =
Not
being an SCons expert, I don't know if this is a valid usage of
StaticLibrary() and SharedLibrary(), but it doesn't seem very correct to =
me.
The reason given in a comment about why an absolute path is used seems
rather dubious to me, too:

   Use get_abspath() with fileNode so we get the path into the build_dir =
and
   not src dir

Isn't it the job of SCons to figure out where to build things? I thought
that was what BuildDir() was for. I changed line 432 of AutoDist.py from

   lib =3D self.env.__dict__[lib_builder](lib_filepath, self.sources)

to

   lib =3D self.env.__dict__[lib_builder](self.fileNode.name, self.source=
s)

Things appear to me to build correctly (at least with SCons 0.96.92). Am =
I
missing something?

 -Patrick


--=20
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2oum9          | http://www.infiscape.com/

[xml-cppdom-devel] CppDOM 0.6.3 released

[Patrick H. <pa...@13...>]

Aron Bierbaum discovered a bug when using 'cppdom-config --basedir' from
CppDOM 0.6.2 on 64-bit architectures. We fixed it, and there is now a 0.6=
=2E3
release available for download. As before, there are several RPMs built, =
and
I will get to the Windows builds as soon as I can.

 -Patrick


--=20
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2oum9          | http://www.infiscape.com/

[xml-cppdom-devel] CppDOM 0.6.2 released

[Patrick H. <pa...@13...>]

I posted the 0.6.2 release of CppDOM a few minutes ago. The changes are a=
ll
in the build system and were made to get RPM building (and
multi-architecture RPM building) working. There are several builds of thi=
s
release posted in RPM form. The Windows builds will follow soon.

 -Patrick


--=20
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2oum9          | http://www.infiscape.com/

[xml-cppdom-devel] Architecture-specific build directories

[Patrick H. <pa...@13...>]

Would anyone object to me committing the following patch? I would like to be
able to have a single CppDOM source tree that is built on multiple
architectures. This simple change achieves that in a Python-friendly manner.

 -Patrick


-- 
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2oum9          | http://www.infiscape.com/

[xml-cppdom-devel] [ xml-cppdom-Bugs-664479 ] There is a bug when parsing comments

[SourceForge.net <no...@so...>]

Bugs item #664479, was opened at 2003-01-08 10:50
Message generated for change (Comment added) made by patrickh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=467781&aid=664479&group_id=52718

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Patrick Hartling (patrickh)
Summary: There is a bug when parsing comments

Initial Comment:
The following went through ok. 
<!-- Success comment -->

But this one failed
<!-- Failed comment-->

If there is a trailing space before closing tag everything 
works ok, if not it fails.

Serge Gut
gu...@ga...

----------------------------------------------------------------------

>Comment By: Patrick Hartling (patrickh)
Date: 2005-05-03 16:50

Message:
Logged In: YES 
user_id=49856

The patch has been committed as Revision 1.29 and Revision
1.26.2.1 of cppdom/cppdom/xmlparser.cpp.  Sorry it took so
long.  :(

----------------------------------------------------------------------

Comment By: Andy Friesen (the_speed_bump)
Date: 2003-02-20 18:38

Message:
Logged In: YES 
user_id=328934

This patch fixes it.  It also fixes <!----> comments, and
throws an exception if end-of-stream is hit before closing
the comment block.

--- copy after this ---
Index: cppdom/xmlparser.cpp
===================================================================
RCS file: /cvsroot/xml-cppdom/cppdom/cppdom/xmlparser.cpp,v
retrieving revision 1.24
diff -u -r1.24 xmlparser.cpp
--- cppdom/xmlparser.cpp	14 Jan 2003 22:29:55 -0000	1.24
+++ cppdom/xmlparser.cpp	21 Feb 2003 00:29:19 -0000
@@ -131,6 +131,9 @@
                   if (token3.getGeneric().at(0) == '-' &&
                       token3.getGeneric().at(1) == '-')
                   {
+                      // needed to correctly handle <!---->
+                     
mTokenizer.putBack(XMLToken(token3.getGeneric().substr(2)));
+
                       parseComment(context);
                   }
                   else
@@ -452,7 +455,13 @@
       while (true)
       {
          ++mTokenizer;
-         if (*mTokenizer == "--")
+
+         if (mTokenizer->isEndOfStream())
+             throw XMLError(xml_closetag_expected);
+
+         // Needed to handle -->s not preceded by whitespace
+         const std::string& s = mTokenizer->getGeneric();
+         if (s.length() >= 2 && (s.substr(s.length()-2) ==
"--"))
          {
             ++mTokenizer;
             if (*mTokenizer == '>')

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=467781&aid=664479&group_id=52718

[xml-cppdom-devel] Re: [vrjuggler-devel] cppdom SConstruct

[Patrick H. <pa...@in...>]

On Thu, 2004-09-02 at 09:39 -0700, Kejian Jin wrote:
> I modify the cppdom SConstruct so that it will work with Mac 0S X. =20
> attach the file, hope you can update in your cppdom.=20

This change breaks compilation with GCC on all platforms except Mac OS
X.  Could you re-submit a patch that is more flexible?

I should also mention two things:

     1. It is typically easier to deal with a patch to a specific
        revision than a whole file intended as a replacement.  In this
        specific case, it would be much easier to deal with a patch
        because there are two CppDOM branches in CVS that need to be
        fixed.
     2. This change should have been sent to the CppDOM list (which I
        have cc'd in this message) since it is a CppDOM issue, not a
        (direct) VR Juggler issue.

 -Patrick


--=20
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2msw3          | http://www.infiscape.com/

[xml-cppdom-devel] 0.3.1 NodeLists crash

[<ar...@ia...>]

cppdom::NodeLists seem to crash when they go out of scope. I am running Win32 Visual
Studio 7.0 with cppdom 0.3.1 built from source, and the 
following code generates a crash and stack trace that ends in std::vector::~vector : 
 
 
ContextPtr context( new Context ); 
 
Document doc( context ); 
 
doc.loadFile( "myFile" ); 
 
NodePtr tag = doc.getChild( "tag" ); 
 
{ 
	NodeList subtags = tag->getChildren( "subtag" ); 
} <-- stack trace jumps from here into STL and ends in std::vector::~vector 
 
 
myFile.xml 
---------- 
<tag> 
	<subtag/> 
	<subtag/> 
</tag> 
 
It seems like the NodeList goes out of scope and the smart pointers to the nodes it
contains get deleted prematurely. I should also note that 
calling getChildren() without any tags does not crash, probably because a new vector is
never generated. 
 
 
Any help would be appreciated, 
 
 
Andres Reinot 
ar...@vr... 

Re: [xml-cppdom-devel] SConsAddons??

[Allen B. <al...@vr...>]

Patrick Hartling wrote:
> Why does the CppDOM SCons build depend on SConsAddons?  There is no
> information in the source tree about where to get the necessary Python
> source, and I don't see what SConsAddons buys.  In particular, looking
> at the diff, I don't even see why it is needed since the AutoDist module
> is already present in the CppDOM source tree.
> 
> Related to this, a patch has been submitted to make the SConsAddons use
> optional.  The patch does far more than that, however, and I don't
> understand SCons well enough to know if it does too much.
> 
>  -Patrick
> 
> 

I just incorporated the patch.  Give it a try.

-Allen

[xml-cppdom-devel] SConsAddons??

[Patrick H. <pa...@13...>]

Why does the CppDOM SCons build depend on SConsAddons?  There is no
information in the source tree about where to get the necessary Python
source, and I don't see what SConsAddons buys.  In particular, looking
at the diff, I don't even see why it is needed since the AutoDist module
is already present in the CppDOM source tree.

Related to this, a patch has been submitted to make the SConsAddons use
optional.  The patch does far more than that, however, and I don't
understand SCons well enough to know if it does too much.

 -Patrick


--=20
Patrick L. Hartling                     | Research Assistant, VRAC
pa...@13...                         | 2274 Howe Hall Room 2624
http://www.137.org/patrick/             | http://www.vrac.iastate.edu/
PGP: http://wwwkeys.gpg.cz:11371/pks/lookup?op=3Dget&search=3D0xE02D5527

[xml-cppdom-devel] [ xml-cppdom-Patches-824083 ] Build Fix

[SourceForge.net <no...@so...>]

Patches item #824083, was opened at 2003-10-15 07:57
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=467783&aid=824083&group_id=52718

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Johnathan Gurley (daren)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build Fix

Initial Comment:
This fixes the build for those of us that do not have SConsAddons. 
 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=467783&aid=824083&group_id=52718

[xml-cppdom-devel] Re: [xml-cppdom-checkins] cvs commit: cppdom/cppdom cppdom.h

[Patrick H. <pa...@13...>]

This change is invalid and breaks the build with GCC and MIPSpro.  The 
return type for Attribute::getValue<T>() is based on the template 
parameter, and 'const std::string&' does not match 'std::string'.

  -Patrick

Kevin Meinert wrote:
> subatomic    2003/02/22 15:07:54 PST
> 
>   Modified files:
>     cppdom               cppdom.h 
>   Log:
>   use
>   
>      const std::string& getValue<std::string>() const
>   
>   instead of
>   
>      std::string getValue<std::string>() const
>   
>   since were returning mData, this would be faster (just a pointer instead
>   of a temporary.)
>   
>   slightly related, this also fixes a crash bug in one of my applications,
>   somehow it was dying in the destructor of std::string if I called
>   getValue<std::string>....  strange. :(   all good now though.
>   
>   Revision  Changes    Path
>   1.67      +4 -4      cppdom/cppdom/cppdom.h
> 
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xml-cppdom/cppdom/cppdom/cppdom.h.diff?r1=1.66&r2=1.67&diff_format=h
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> Xml-cppdom-checkins mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xml-cppdom-checkins


-- 
Patrick L. Hartling			| Research Assistant, VRAC
pa...@13...				| 2274 Howe Hall Room 2624
PGP: http://www.137.org/patrick/pgp.txt	| T: +1.515.294.4916
http://www.137.org/patrick/		| http://www.vrac.iastate.edu/

Re: [xml-cppdom-devel] Another Win32-related change

[Allen B. <al...@vr...>]

Patrick Hartling wrote:
> A problem has arisen with CppDOM on Win32, most likely because of the 
> change I made for the import/export stuff for the CppDOM DLL.  It has 
> come to my attention that cppdom::Attributes derives from std::map<>. 
> (More specifically, it derives from std::map<std::string, std::string>).
> 
> If there is code that links against CppDOM that also uses the type 
> std::map<std::string, std::string>, the VC++ 7 linker complains of 
> multiply defined symbols, all of them in the std::map<> class.  It is my 
> understanding that deriving from STL types is not recommended, and in my 
> (limited) experience, DLLs and templates as base types do not mix well.
> 
> So, my proposed change is to fix cppdom::Attributes so that it 
> aggregates std::map<std::string, std::string> instead of extending it. 
> The API for cppdom::Attributes has to be extended a little to have some 
> pass-through methods into the std::map<> interface.  I have already made 
> this change and tested it successfully, and I want to know if it is okay 
> to commit it.  I'm sure my changes aren't very elegant, but they get the 
> job done.

I like the idea.

It would also allow us to internally use a hash_map when the platform 
supports it.

-Allen

>  -Patrick
> 
> 


-- 
-- Allen Bierbaum                         al...@vr...
-- PhD Candidate             txtmsg - 515...@us...
-- VR Juggler Team                              www.vrjuggler.org
-- Virtual Reality Applications Center       www.vrac.iastate.edu

[xml-cppdom-devel] Another Win32-related change

[Patrick H. <pa...@13...>]

A problem has arisen with CppDOM on Win32, most likely because of the 
change I made for the import/export stuff for the CppDOM DLL.  It has 
come to my attention that cppdom::Attributes derives from std::map<>. 
(More specifically, it derives from std::map<std::string, std::string>).

If there is code that links against CppDOM that also uses the type 
std::map<std::string, std::string>, the VC++ 7 linker complains of 
multiply defined symbols, all of them in the std::map<> class.  It is my 
understanding that deriving from STL types is not recommended, and in my 
(limited) experience, DLLs and templates as base types do not mix well.

So, my proposed change is to fix cppdom::Attributes so that it 
aggregates std::map<std::string, std::string> instead of extending it. 
The API for cppdom::Attributes has to be extended a little to have some 
pass-through methods into the std::map<> interface.  I have already made 
this change and tested it successfully, and I want to know if it is okay 
to commit it.  I'm sure my changes aren't very elegant, but they get the 
job done.

  -Patrick


-- 
Patrick L. Hartling			| Research Assistant, VRAC
pa...@13...				| 2274 Howe Hall Room 2624
PGP: http://www.137.org/patrick/pgp.txt	| T: +1.515.294.4916
http://www.137.org/patrick/		| http://www.vrac.iastate.edu/

Re: [xml-cppdom-devel] Patch for Win32 dllexport goop

[Ben S. <bs...@ia...>]

That would be a good change. Please apply the patch.

-Ben

Patrick Hartling wrote:

> Does anyone have any objections to the attached patch?  The 
> preprocessor would be unhappy if both CPPDOM_EXPORTS and 
> CPPDOM_IMPORTS were defined, and I don't think it should be necessary 
> for user code to define CPPDOM_IMPORTS.
>
>  -Patrick
>
>
>------------------------------------------------------------------------
>
>Index: config.h
>===================================================================
>RCS file: /cvsroot/xml-cppdom/cppdom/cppdom/config.h,v
>retrieving revision 1.9
>diff -u -r1.9 config.h
>--- config.h	14 Jan 2003 22:29:55 -0000	1.9
>+++ config.h	16 Jan 2003 15:25:30 -0000
>@@ -63,9 +63,7 @@
> // export/import #define's for building a win32 dll
> # ifdef CPPDOM_EXPORTS
> #  define CPPDOM_API __declspec(dllexport)
>-# endif
>-
>-# ifdef CPPDOM_IMPORTS
>+# else
> #  define CPPDOM_API __declspec(dllimport)
> # endif
> 
>  
>

[xml-cppdom-devel] Patch for Win32 dllexport goop

[Patrick H. <pa...@vr...>]

Does anyone have any objections to the attached patch?  The preprocessor 
would be unhappy if both CPPDOM_EXPORTS and CPPDOM_IMPORTS were defined, 
and I don't think it should be necessary for user code to define 
CPPDOM_IMPORTS.

  -Patrick


-- 
Patrick L. Hartling                     | Research Assistant, VRAC
pa...@vr...                | 2624 Howe Hall: 1.515.294.4916
http://www.137.org/patrick/             | http://www.vrac.iastate.edu/

Re: [xml-cppdom-devel] Re: [xml-cppdom-checkins] cvs commit: cppdom/cppdom cppdom.cpp cppdom.h xmlparser.cpp xmltokenizer.cpp xmltokenizer.h

[Ben S. <bs...@ia...>]

Hmm ... that's a good point. It certainly would be nice to support i18n
in the future. However, we were not actually using XMLString in that way
and it appeared to add a bit of ambiguity to the library, so I removed
it. Should we support i18n in the future, we can put it back in, but
this time doing it properly.

cheers,
-----
Ben Scott
Research Assistant
VR Juggler Team
Virtual Reality Applications Center
bs...@vr...

Patrick Hartling wrote:
 > Is the XMLString (ha ha, Dvorak is for suckers!) stuff really nonsense?
 > It seems to me that strings of XML text should be made up of 16-bit
 > characters to ensure that i18n works properly.  Of course, this is
 > coming from someone who has never implemented an XML parser nor read the
 > XML specification.  Regardless, if CppDOM is going to catch on, it is
 > going to have to be less US-centric, and forcing the use of std::string
 > isn't going to achive that.
 >
 >  -Patrick
 >
 > Ben Scott wrote:
 >
 >> nonchocoboy    2003/01/02 14:47:47 PST
 >>
 >>   Modified files:
 >>     cppdom               cppdom.cpp cppdom.h xmlparser.cpp
 >>                          xmltokenizer.cpp xmltokenizer.h   Log:
 >>   Removed xml_node_type and XWLString nonsense.
 >>     Revision  Changes    Path
 >>   1.19      +12 -12    cppdom/cppdom/cppdom.cpp
 >>   1.45      +31 -39    cppdom/cppdom/cppdom.h
 >>   1.16      +7 -7      cppdom/cppdom/xmlparser.cpp
 >>   1.10      +7 -7      cppdom/cppdom/xmltokenizer.cpp
 >>   1.9       +18 -18    cppdom/cppdom/xmltokenizer.h
 >>
 >> 
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xml-cppdom/cppdom/cppdom/cppdom.cpp.diff?r1=1.18&r2=1.19&diff_format=h 

 >>
 >> 
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xml-cppdom/cppdom/cppdom/cppdom.h.diff?r1=1.44&r2=1.45&diff_format=h 

 >>
 >> 
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xml-cppdom/cppdom/cppdom/xmlparser.cpp.diff?r1=1.15&r2=1.16&diff_format=h 

 >>
 >> 
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xml-cppdom/cppdom/cppdom/xmltokenizer.cpp.diff?r1=1.9&r2=1.10&diff_format=h 

 >>
 >> 
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xml-cppdom/cppdom/cppdom/xmltokenizer.h.diff?r1=1.8&r2=1.9&diff_format=h 

 >>
 >>
 >>
 >> -------------------------------------------------------
 >> This sf.net email is sponsored by:ThinkGeek
 >> Welcome to geek heaven.
 >> http://thinkgeek.com/sf
 >> _______________________________________________
 >> Xml-cppdom-checkins mailing list
 >> Xml...@li...
 >> https://lists.sourceforge.net/lists/listinfo/xml-cppdom-checkins
 >
 >
 >
 >

[xml-cppdom-devel] Re: [xml-cppdom-checkins] cvs commit: cppdom/cppdom cppdom.cpp cppdom.h xmlparser.cpp xmltokenizer.cpp xmltokenizer.h

[Patrick H. <pa...@13...>]

Is the XMLString (ha ha, Dvorak is for suckers!) stuff really nonsense? 
It seems to me that strings of XML text should be made up of 16-bit 
characters to ensure that i18n works properly.  Of course, this is coming 
from someone who has never implemented an XML parser nor read the XML 
specification.  Regardless, if CppDOM is going to catch on, it is going 
to have to be less US-centric, and forcing the use of std::string isn't 
going to achive that.

  -Patrick

Ben Scott wrote:
> nonchocoboy    2003/01/02 14:47:47 PST
> 
>   Modified files:
>     cppdom               cppdom.cpp cppdom.h xmlparser.cpp 
>                          xmltokenizer.cpp xmltokenizer.h 
>   Log:
>   Removed xml_node_type and XWLString nonsense.
>   
>   Revision  Changes    Path
>   1.19      +12 -12    cppdom/cppdom/cppdom.cpp
>   1.45      +31 -39    cppdom/cppdom/cppdom.h
>   1.16      +7 -7      cppdom/cppdom/xmlparser.cpp
>   1.10      +7 -7      cppdom/cppdom/xmltokenizer.cpp
>   1.9       +18 -18    cppdom/cppdom/xmltokenizer.h
> 
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xml-cppdom/cppdom/cppdom/cppdom.cpp.diff?r1=1.18&r2=1.19&diff_format=h
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xml-cppdom/cppdom/cppdom/cppdom.h.diff?r1=1.44&r2=1.45&diff_format=h
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xml-cppdom/cppdom/cppdom/xmlparser.cpp.diff?r1=1.15&r2=1.16&diff_format=h
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xml-cppdom/cppdom/cppdom/xmltokenizer.cpp.diff?r1=1.9&r2=1.10&diff_format=h
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xml-cppdom/cppdom/cppdom/xmltokenizer.h.diff?r1=1.8&r2=1.9&diff_format=h
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Xml-cppdom-checkins mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xml-cppdom-checkins



-- 
Patrick L. Hartling			| Research Assistant, VRAC
pa...@13...				| 2274 Howe Hall Room 2624
PGP: http://www.137.org/patrick/pgp.txt	| T: +1.515.294.4916
http://www.137.org/patrick/		| http://www.vrac.iastate.edu/

Re: [xml-cppdom-devel] Compile error with VC++7

[Ben S. <bs...@vr...>]

I don't believe this will cause a problem with VC6 unless the operator< is 
implemented as a member function. I say we should go ahead and apply your 
fix. nice work!

cheers,
-----
Ben Scott
Research Assistant VRAC
bs...@ia...

On Wed, 29 May 2002, Patrick Hartling wrote:

> I was looking at the shared_ptr implementation in Boost 1.28, and they no 
> longer specialize std::less<T> for shared_ptr's.  Instead, they overload 
> operator<.  If I comment out the specialization of std::less<T> and add 
> the overloaded operator<, the code compiles and the tests pass.  Is this 
> a valid change, or will it break something with VC6?
> 
>   -Patrick
> 
> Patrick Hartling wrote:
> > Any idea what would cause this error with Visual Studio 7 when trying to 
> > compile xmlparser.cpp?
> > 
> > C:\cygwin\home\patrick\juggler\external\cppdom\cppdom\shared_ptr.h(266) 
> > : error C2065: 'T' : undeclared identifier
> > C:\cygwin\home\patrick\juggler\external\cppdom\cppdom\shared_ptr.h(266) 
> > : error C2687: cannot define a nested UDT of a template class out of line
> > C:\cygwin\home\patrick\juggler\external\cppdom\cppdom\shared_ptr.h(266) 
> > : fatal error C1903: unable to recover from previous error(s); stopping 
> > compilation
> > 
> >  -Patrick
> > 
> > 
> 
> 
> 
> 

Re: [xml-cppdom-devel] Compile error with VC++7

[Patrick H. <pa...@13...>]

I was looking at the shared_ptr implementation in Boost 1.28, and they no 
longer specialize std::less<T> for shared_ptr's.  Instead, they overload 
operator<.  If I comment out the specialization of std::less<T> and add 
the overloaded operator<, the code compiles and the tests pass.  Is this 
a valid change, or will it break something with VC6?

  -Patrick

Patrick Hartling wrote:
> Any idea what would cause this error with Visual Studio 7 when trying to 
> compile xmlparser.cpp?
> 
> C:\cygwin\home\patrick\juggler\external\cppdom\cppdom\shared_ptr.h(266) 
> : error C2065: 'T' : undeclared identifier
> C:\cygwin\home\patrick\juggler\external\cppdom\cppdom\shared_ptr.h(266) 
> : error C2687: cannot define a nested UDT of a template class out of line
> C:\cygwin\home\patrick\juggler\external\cppdom\cppdom\shared_ptr.h(266) 
> : fatal error C1903: unable to recover from previous error(s); stopping 
> compilation
> 
>  -Patrick
> 
> 



-- 
Patrick L. Hartling                     | Research Assistant, VRAC
pa...@13...                         | 2624 Howe Hall -- (515)294-4916
http://www.137.org/patrick/             | http://www.vrac.iastate.edu/