Menu
▾
▴
libxmlplusplus-general — Open discusions about libXML++
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(157) |
Dec
(87) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(78) |
Feb
(246) |
Mar
(83) |
Apr
(32) |
May
(99) |
Jun
(85) |
Jul
(34) |
Aug
(24) |
Sep
(65) |
Oct
(60) |
Nov
(45) |
Dec
(90) |
| 2004 |
Jan
(8) |
Feb
(40) |
Mar
(12) |
Apr
(17) |
May
(56) |
Jun
(13) |
Jul
(5) |
Aug
(30) |
Sep
(51) |
Oct
(17) |
Nov
(9) |
Dec
(20) |
| 2005 |
Jan
(16) |
Feb
(22) |
Mar
(14) |
Apr
(6) |
May
(12) |
Jun
(41) |
Jul
(21) |
Aug
(26) |
Sep
(7) |
Oct
(42) |
Nov
(10) |
Dec
(7) |
| 2006 |
Jan
(6) |
Feb
(9) |
Mar
(19) |
Apr
(7) |
May
(1) |
Jun
(10) |
Jul
(5) |
Aug
|
Sep
|
Oct
(8) |
Nov
(9) |
Dec
(3) |
| 2007 |
Jan
(1) |
Feb
|
Mar
(7) |
Apr
(5) |
May
(10) |
Jun
(32) |
Jul
(6) |
Aug
(8) |
Sep
(10) |
Oct
(3) |
Nov
(11) |
Dec
(2) |
| 2008 |
Jan
(3) |
Feb
|
Mar
(11) |
Apr
|
May
(6) |
Jun
(4) |
Jul
|
Aug
(3) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
(6) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(5) |
Aug
|
Sep
|
Oct
(1) |
Nov
(4) |
Dec
(3) |
| 2010 |
Jan
(3) |
Feb
(6) |
Mar
(16) |
Apr
(2) |
May
|
Jun
|
Jul
(7) |
Aug
(3) |
Sep
(4) |
Oct
(3) |
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Edd D. <ed...@us...> - 2003-02-11 23:47:32
|
So, I was chatting with Murray on IRC and wanting namespace awareness in
libxml++. He challenged me to do some hacking on it myself, so I had a
go this afternoon. Daniel Veillard indicated that libxml2 is never
likely to get SAX2, and that for namespaces he'd encourage the use of
the XmlTextReader interface.
Please be aware that my C++ skills are definitely in the "apprentice"
category, and I probably indented incorrectly to someone's great
irritation.
That said, here's a preliminary wrapper and example program for the
XmlTextReader stuff from libxml2. It's a diff against today's CVS HEAD
plus these new files I added:
examples/reader/Makefile.am
examples/reader/main.cc
examples/reader/example.xml
libxml++/parsers/reader.cc
libxml++/parsers/reader.h
It's only partially complete, in particular only the constructor where
you pass a filename is done.
The biggest trouble so far is that the underlying XmlTextReader stuff
handles allocation and freeing of things differently than the normal
parsers. This means that the construct() and destruct() functions just
don't work. I disabled them entirely for the purposes of this wrapper,
but it needs figuring out properly -- a bit beyond the scope of one
evening's hacking for me, unfamiliar as I am with the magic of libxmlpp
internals. However, this disabling meant I couldn't implement the two
methods which allow sniffing of the current Node and Document.
The other thing to note is that every time you get an xmlChar* back from
a method, it's your responsibility to free it with xmlFree().
I hope that this is a good enough start for someone with more clues than
I to improve. Alternatively, I'd be happy to receive a few pointers
from folk on how best to make the wrapper more C++ idiomatic, and in
particular solve the construct/destruct issues.
The *good news* is that this stuff works for parsing namespace-enabled
XML documents.
cheers
-- Edd
|
|
From: Stefan S. <se...@sy...> - 2003-02-11 22:00:18
|
Ole Laursen wrote: > So each of these <message> and <presence> elements are small documents > in themselves. If I could get a DOM-representation of each of them, it > would somewhat easier I think. Any hints? well, these chunks are not valid xml documents in themselfs, so you have to treat them as parts of a parent document. Libxml2 supports parsing of chunks, and I think what you are looking for is really an event driven approach, where your sax handler is called per tag that is encountered in the stream. Libxml++ doesn't provide chunk-wise parsing yet... Stefan |
|
From: Ole L. <ol...@ha...> - 2003-02-11 21:42:09
|
Hi,
I've no previous experience with parsing XML, but I'm trying to write
a library for interpreting Jabber XML streams (for a Gnome 2 Jabber
client).
Can I do that with libxml++? The problem is that my data comes in
unpredictable chunks from a network socket - I get a signal from
libgtcpsocket whenever it happens. I've thought about using the
SaxParser, but I can't feed it small chunks, can I? Suggestions?
Also, the SaxParser seems to be a little bit inconvenient. The XML
comes in chunks:
<stream:stream to='host' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
... new chunk arrives
<message from='node@host' to='receiving-ID'>
<body>Watson come here, I need you!</body>
</message>
... new chunk arrives
<message from='node@host' to='receiving-ID'>
<body>Watson come here, I need you!</body>
</message>
... new chunk arrives
<presence to='node@host' from='blabla@somewhere'>
<status>Online</status>
</presence>
...
</stream:stream>
So each of these <message> and <presence> elements are small documents
in themselves. If I could get a DOM-representation of each of them, it
would somewhat easier I think. Any hints?
--
Ole Laursen
http://www.cs.auc.dk/~olau/
|
|
From: Stefan S. <se...@sy...> - 2003-02-11 14:22:14
|
Jonathan Wakely wrote: [...] > Not that this should dictate .h/.cc policy in any way, I'm just being a > C++ bore again! The separation is useful to encapsulate interface from implementation, i.e. to reduce dependencies and make changes more managable. Including .cc files into .h files totally defeats that. What's the point of the separation then I wonder ? Stefan |
|
From: Stefan S. <se...@sy...> - 2003-02-11 14:19:36
|
Jonathan Wakely wrote: > What if a NodeList cannot be constructed from a const NodeList ? > e.g. its copy ctor takes a non-const reference like auto_ptr, or it has > private copy ctor to make it non-copyable. a const container of objects is not the same as a container of const objects. What you are describing is a const container, while what we want is a container of const objects. > That would allow a const Node to return a const NodeList, which can't be > turned into a non-const NodeList, and so will only yield read-only > const_iterators. yeah, that may work. > It might still be necessary to have a separate ConstNodeList class, but > IMHO it would be better if "deep-constness" can be done correctly with a > single NodeList class. well, I don't think it can (conceptually). That's the point of defining 'const_iterator' instead of just having 'const iterator'. Stefan |
|
From: Christophe de V. <cde...@al...> - 2003-02-11 13:37:07
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Mardi 11 F=E9vrier 2003 14:18, Jonathan Wakely a =E9crit : > On Sun, Feb 09, 2003 at 04:25:11PM +0100, Christophe de Vienne wrote: > > Le Vendredi 7 F=E9vrier 2003 23:10, Stefan Seefeld a =E9crit : > > > The full C++ code now lives in a set of headers. There > > > was just not enough code independent of the actual > > > character type to be put into .cc files. > > > > As far as this particular point, what I personnaly do with templated > > class is that I still separate declaration and implementation into a .h > > and a .cc/.cpp file. > > Then I include the .cc/.cpp in the .h file so the templated > > implementation is still visible by user code. > > This make header much more clean and readable, and if one day we have t= he > > chance to have a c++ compiler which support the 'export' keyword, then > > adaptation will be as easy as comment 1 line of code. > > "export" is widely misunderstood. It doesn't mean separate compilation > of templates, and I'd be surprised if it sees much use even when more > compilers support it. Herb Sutter has done some interesting articles on > his experiences with the Comeau compiler, which now supports "export", > and my impression is that the complications it raises outweigh the > benefits (which apparently don't even result in quicker compilation!) > > Not that this should dictate .h/.cc policy in any way, I'm just being a > C++ bore again! You're certainly right about export. If ever it is supported efficiently it= =20 will be time to use it and construct the application around it. Not now. As far as keeping .h/.cc separation for templated class, it is essentially = for=20 readability. Christophe =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+SPxjB+sU3TyOQjARAupAAKDMVjW5BoH37o+Z8xn8dqNGQGioygCaApB0 tWoqJE7oDanradhRh6fj6Uo=3D =3DIZ6t =2D----END PGP SIGNATURE----- |
|
From: Jonathan W. <co...@co...> - 2003-02-11 13:23:38
|
On Fri, Feb 07, 2003 at 04:20:50PM -0500, Stefan Seefeld wrote:
> it seems we are converging towards the following:
>
> class Node
> {
> public:
> NodeList get_children();
> NodeList get_attributes();
> //...the rest
> };
>
> class NodeList
> {
> public:
> class iterator;
> class const_iterator;
> iterator begin();
> //...and the rest
> };
[snip]
> With my proposed NodeList class (which will comply to STL API), only
> a single xmlNode pointer needs to be copied, as the 'iterator' now
> can be implemented in terms of libxml2's internal linked list structure,
> not as an iterator over a std::list. That's the main benefit.
Nice.
> There is one remaining issue: we'd need a 'ConstNodeList' type that
> provides read-only access to the children. If you hold a const
> node reference, you shouldn't access child nodes in r/w mode, i.e
> the corresponding 'get_children() const;' method shouldn't return
> a NodeList, as you get r/w access with that.
> (The issue exists since we don't return a reference to an internal
> container, but a new one, so we can't restrict access).
What if a NodeList cannot be constructed from a const NodeList ?
e.g. its copy ctor takes a non-const reference like auto_ptr, or it has
private copy ctor to make it non-copyable.
That would allow a const Node to return a const NodeList, which can't be
turned into a non-const NodeList, and so will only yield read-only
const_iterators. This gives the desired effect of not being able to
modify the children of a const Node.
It might still be necessary to have a separate ConstNodeList class, but
IMHO it would be better if "deep-constness" can be done correctly with a
single NodeList class.
jon
--
"The tools we use have a profound (and devious!) influence on our
thinking habits, and, therefore, on our thinking abilities."
- Edsger Dijkstra
|
|
From: Jonathan W. <co...@co...> - 2003-02-11 13:22:23
|
On Sun, Feb 09, 2003 at 04:25:11PM +0100, Christophe de Vienne wrote: > Le Vendredi 7 Février 2003 23:10, Stefan Seefeld a écrit : > > The full C++ code now lives in a set of headers. There > > was just not enough code independent of the actual > > character type to be put into .cc files. > > As far as this particular point, what I personnaly do with templated class is > that I still separate declaration and implementation into a .h and a .cc/.cpp > file. > Then I include the .cc/.cpp in the .h file so the templated implementation is > still visible by user code. > This make header much more clean and readable, and if one day we have the > chance to have a c++ compiler which support the 'export' keyword, then > adaptation will be as easy as comment 1 line of code. "export" is widely misunderstood. It doesn't mean separate compilation of templates, and I'd be surprised if it sees much use even when more compilers support it. Herb Sutter has done some interesting articles on his experiences with the Comeau compiler, which now supports "export", and my impression is that the complications it raises outweigh the benefits (which apparently don't even result in quicker compilation!) Not that this should dictate .h/.cc policy in any way, I'm just being a C++ bore again! jon -- "When a true genius appears in the world you may know him by this sign: that all the dunces are in confederacy against him." - Jonathan Swift |
|
From: Stefan S. <se...@sy...> - 2003-02-10 02:29:08
|
hey Murray,
I think our current situation can be summed up simply like this:
I'v got a libxml2 C++ wrapper library up and running, which, rather
than maintaining and using it all alone, I'd much prefer to integrate
into libxml++.
Further, the way you request me to collaborate is inacceptable for me,
as you essentially want to be able to approve each single line of
suggested change. Yet you don't want to write those changes yourself,
asking me to 'show the patch'.
This makes me wonder whether you are really interested in my
contributions. Your phrasing at least seems to indicate the only
one being interested into the changes is me.
I just don't have the time for this. I'll gladly show the code I
use, so you can adapt it to your hearts content. But don't expect
me to provide you with patches and then wait weeks to get each one
individually approved and checked in. That's not going to work.
Stefan
PS: as to my first mail in this thread: we *did* discuss the change
I suggested, and I only wanted to report *how* it did work out.
Why do we need a patch to discuss this ? Please read up on this
in the ML archives to refresh your memory. There is enough to
"look at and respond to".
|
|
From: Christophe de V. <cde...@al...> - 2003-02-09 15:25:11
|
Hi, As far as the orientation the thread took, I'll just say that I quite agree= =20 with Murray, but don't want to feed the troll. Le Vendredi 7 F=E9vrier 2003 23:10, Stefan Seefeld a =E9crit : > The full C++ code now lives in a set of headers. There > was just not enough code independent of the actual > character type to be put into .cc files. As far as this particular point, what I personnaly do with templated class = is=20 that I still separate declaration and implementation into a .h and a .cc/.c= pp=20 file. Then I include the .cc/.cpp in the .h file so the templated implementation = is=20 still visible by user code. This make header much more clean and readable, and if one day we have the=20 chance to have a c++ compiler which support the 'export' keyword, then=20 adaptation will be as easy as comment 1 line of code. This is to say that even if the unicode compliance of libxml++ means fully= =20 templated classes, this won't mean .cc files suppression, and that a patch = is=20 more than welcome... Best regards, Christophe |
|
From: Christophe de V. <cde...@al...> - 2003-02-08 02:01:07
|
Hi, I'm pleased to annouce the release of libxml++ 0.19. You can download it from SourceForge.net : http://sourceforge.net/project/showfiles.php?group_id=12999&release_id=138728 You will find a ChangeLog here : http://sourceforge.net/project/shownotes.php?release_id=138728 For a more precise informations, please see the ChangeLog inside the package. Have fun with this new release... Christophe |
|
From: Stefan S. <ste...@or...> - 2003-02-07 22:07:57
|
hi there, this is just a little note to let you know that I finished a modified version of libxml++ that is parametrized for the character type. I can thus use this code with whatever unicode library I have (at work this happens to be Qt, in fresco this is the 'Babylon' library, etc.), and all seems to work fine. The full C++ code now lives in a set of headers. There was just not enough code independent of the actual character type to be put into .cc files. Not sure whether this will ever make it into the official libxml++, but I'm going to use it myself. Let's see how/whether it will be accepted by libxml++ developers. May be in a latter release... Regards, Stefan |
|
From: Christophe de V. <cde...@al...> - 2003-02-07 18:09:16
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Vendredi 7 F=E9vrier 2003 19:01, Stefan Seefeld a =E9crit : > Jonathan Wakely wrote: > > I'm now thinking that ForwardContainer migh be a better choice of STL > > concept to model, as it has fewer requirements so might be simpler to > > implement 1) while still supporting an STL-style interface. This would > > mean you can get an iterator from any Node, not just from some container > > type. > > agreed. In fact, the more I think about suggestion 2) the more I like > it: the 'Node' class has a 'get_children()' and a 'get_attribute()' > method returning both a NodeList. So far it's almost as it was. > However, instead of typedefing NodeList to be 'std::list<Node *>', > I'd suggest we define it such that creation of a NodeList only implies > a single copy: that of the first child node / attribute of the given > node. The iterator is then implemented to traverse the libxml2 linked > list, not the STL container as it did before. > > Does this sound satisfactory to everybody ? > Yes. We can already revert current iterators implementation on main branch. Then I'd like to see this as a patch before commiting something. For now I= =20 consider this more like a proposition (very interesting one though). Regards, Christophe =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+Q/YsB+sU3TyOQjARArcYAJ9uGL9K5SHYQUsVlfm5kWQoTeVa1QCePo6V taCm/GXsYut9cPJfjphGdcw=3D =3Dbe21 =2D----END PGP SIGNATURE----- |
|
From: Stefan S. <se...@sy...> - 2003-02-07 17:58:34
|
Jonathan Wakely wrote: > I'm now thinking that ForwardContainer migh be a better choice of STL > concept to model, as it has fewer requirements so might be simpler to > implement 1) while still supporting an STL-style interface. This would > mean you can get an iterator from any Node, not just from some container > type. agreed. In fact, the more I think about suggestion 2) the more I like it: the 'Node' class has a 'get_children()' and a 'get_attribute()' method returning both a NodeList. So far it's almost as it was. However, instead of typedefing NodeList to be 'std::list<Node *>', I'd suggest we define it such that creation of a NodeList only implies a single copy: that of the first child node / attribute of the given node. The iterator is then implemented to traverse the libxml2 linked list, not the STL container as it did before. Does this sound satisfactory to everybody ? Stefan |
|
From: Jonathan W. <co...@co...> - 2003-02-07 17:36:27
|
On Fri, Feb 07, 2003 at 10:34:22AM -0500, Stefan Seefeld wrote: > It seems there are two ways to do this without creating too much > overhead: > > 1) let the 'Node' object itself act as the container (which it actually > is in libxml2), using 'child_iterator' and 'attribute_iterator'. > > 2) provide a thin 'NodeList' interface that provides the STL API. 'Node' > would then have two methods 'NodeList get_children()' and > 'NodeList get_attributes()'. > > > 1) is what I currently propose, while 2) is a slight modification of > what a) exists now and b) Jonathan suggests. The advantages over the > original suggestion (just using an STL container 'NodeList') is that it > could avoid unnecessary copying. So, while 2) still uses one (IMO) > unnecessary indirection (you have to access the 'children' container > to iterate it, instead of directly accessing the 'child_iterators') > It seems to be quite reasonable performance-wise. I'm now thinking that ForwardContainer migh be a better choice of STL concept to model, as it has fewer requirements so might be simpler to implement 1) while still supporting an STL-style interface. This would mean you can get an iterator from any Node, not just from some container type. I'm going to think more about this over the weekend, look at xmlwrapp again, and maybe look at how some examples of use would differ with the two proposals. jon -- "Fanaticism consists in redoubling your efforts when you have forgotten your aims." - George Santayana |
|
From: Stefan S. <se...@sy...> - 2003-02-07 15:31:42
|
Christophe de VIENNE wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>>ok. What are the remaining issues with the iterator proposal ? Could
>>you please sum up so we can get ahead with this ?
>>
>
>
> Personnaly I think that implement strictly one of the STL container idiom
> would be nice.
> Jonathan proposed sequence. Since it is quite simple and probably complete
> enough I think it is a reasonnable choice.
It seems there are two ways to do this without creating too much
overhead:
1) let the 'Node' object itself act as the container (which it actually
is in libxml2), using 'child_iterator' and 'attribute_iterator'.
2) provide a thin 'NodeList' interface that provides the STL API. 'Node'
would then have two methods 'NodeList get_children()' and
'NodeList get_attributes()'.
1) is what I currently propose, while 2) is a slight modification of
what a) exists now and b) Jonathan suggests. The advantages over the
original suggestion (just using an STL container 'NodeList') is that it
could avoid unnecessary copying. So, while 2) still uses one (IMO)
unnecessary indirection (you have to access the 'children' container
to iterate it, instead of directly accessing the 'child_iterators')
It seems to be quite reasonable performance-wise.
Comments ?
Stefan
|
|
From: Christophe de V. <cde...@al...> - 2003-02-07 15:07:51
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > ok. What are the remaining issues with the iterator proposal ? Could > you please sum up so we can get ahead with this ? > Personnaly I think that implement strictly one of the STL container idiom would be nice. Jonathan proposed sequence. Since it is quite simple and probably complete enough I think it is a reasonnable choice. On the other hand, the fact that the element type is itself a container may be problematic. So far I'm sure what would be the right thing. Christophe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+Q8ujB+sU3TyOQjARAreHAJ0cJW2gjs4DX6H+aRTZSjsrfTFrEACgllvt +t1isLsWUCdwfExpkj3Dng8= =X5fb -----END PGP SIGNATURE----- |
|
From: Christophe de V. <cde...@al...> - 2003-02-07 14:58:14
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Vendredi 7 F=E9vrier 2003 15:45, Stefan Seefeld a =E9crit : > > There is quite a lot to change if we really wanted to be compliant > with this. I'm not against providing a DOM-C++ API. But again, I think > we should take advantage of C++ techniques whenever we can, and > provide the DOM API on top of it. > I don't think providing a DOM-C++ API is a priority. However if there is a real need for this one day we may do it. Cheers Christophe =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+Q8lnB+sU3TyOQjARAjj4AKC3fuaKREzSgULcqP/vW47z1MMJxACg3E+N Sw8xC3ni0PeNAc+NseMDnPA=3D =3DU+ur =2D----END PGP SIGNATURE----- |
|
From: Stefan S. <se...@sy...> - 2003-02-07 14:11:52
|
Paul Tan Hock Lai wrote: > I am looking for some XML-based configuration software that can perform configuration-specific : can you elaborate a bit ? What exactly do you want the software to do ? Stefan |
|
From: Paul T. H. L. <ta...@i2...> - 2003-02-07 02:39:01
|
Hi,
I would like to know if there are any C++ wrapper using libxml++.
I am looking for some XML-based configuration software that can perform =
configuration-specific :
<config>
<name>Paul</name>
<email>paul@com</email>
<iface>
<ipaddr>172.16.3.111</ipaddr>
<nic>wlan-802.11<nic>
</iface>
<iface>
<ipaddr>192.168.2.1</ipaddr>
<nic>ether<nic>
</iface>
</config>
Thanks.
Cheers,
Paul
|
|
From: Christophe de V. <cde...@al...> - 2003-02-06 23:07:32
|
Good evening, I have a small doubt : Initialising the _private field of xmlNode structures is done this way (for element in the exemple) : node->_private = new xmlpp::Element(node); so the xmlpp::Element pointer is stored in a void *. when reading it in destruct, the _private field is cast to a Node * for deletion. At _private initialisation, shouldn't the pointer cast to Node * before being cast to void *, since we have some virtual functions ? Or would it be the case only if Element herit virtualy from Node ? Comments/lights appreciated. Christophe |
|
From: <mu...@t-...> - 2003-02-06 19:16:05
|
On Thu, 2003-02-06 at 20:09, Stefan Seefeld wrote: > Murray Cumming wrote: > > Stefan, even after we talked about this and I had to remove such changes > > from your patch, you have continued to make changes such as: > > - Removing parameter names from method declarations in header files. > > - Changing "Something* " to "Something *". > > > > Please do not. I'm serious. > > ok. I'm sorry, especially for the first. As to the second, that's > strictly a 'coding style' issue. Yes. Please conform to existing standards. > And as the current libxml++ code > contains both styles, No, Something* is used widely, and has been agreed upon for this project. "Something *" is used only in the SaxParser code, which I said I would fix, and which I tried to fix already but whose corrections I lost because of your own faulty patch. You know this. This is not news to you. > I just continued to use my own, which happens > to be 'Something *'. You mentioned that you didn't consider this to > be correct. Why ? It's not a matter of correct. It's what we want to do for this project. It's bad enough to change code to use your own style. It's even worse to changed code to your own style while making no other changes on that line. And it's even worse to change code to your own style when I have already told you once not to do it. > However, please put some 'coding guidelines' somewhere if ever you > want contributors to respect them. It's arbitrary, so it has to > be fixed. In the absence of guidelines, contributors should conform to existing styles as found in source files, even if different source files have different styles (they don't). That's normal. Please tell me that you have agreed to this. -- Murray Cumming mu...@us... www.murrayc.com |
|
From: <mu...@t-...> - 2003-02-06 19:04:40
|
Stefan, even after we talked about this and I had to remove such changes from your patch, you have continued to make changes such as: - Removing parameter names from method declarations in header files. - Changing "Something* " to "Something *". Please do not. I'm serious. -- Murray Cumming mu...@us... www.murrayc.com |
|
From: Stefan S. <se...@sy...> - 2003-02-06 19:02:36
|
Jonathan Wakely wrote:
> If the interface conforms fully to the STL concept of a Sequence then it
> can be documented as such, and users can know _exactly_ what to expect
> and what not to expect in terms of complexity guarantees.
As I said in another mail, STL doesn't define its algorithms like
template <typename container>
void loop(const container &c)
{
for (container::iterator i = c.begin(); i != c.end(); ++i)
// do something
}
but rather
template <typename iterator>
void loop(iterator begin, iterator end)
{
for (begin; begin != end; ++begin)
// do something
}
which is much more flexible (as you don't necessarily want to iterate
over the whole range) and simple (precisely because the way you
construct the iterators, i.e. whether via 'begin()' or
'children_begin()' is unconstrained).
If you absolutely want to look at a node as a container, you'd need
to consider two containers: one for the children, one for the
attributes.
> Maybe the iterator should only be available from the Document object,
> giving access to all children, not available on each Node.
Even then you'd want different iterator types: you can iterate in
different orders, you can iterate only over a restricted region,
such as direct children of a given node, or just over the attributes
of a given node.
I think this proves that it is really a bad idea to pass the container
directly to an iterating function, as lots of STL algos do. It's much
simpler to pass the first and one-past-last iterators.
Stefan
|
|
From: Jonathan W. <co...@co...> - 2003-02-06 18:52:36
|
On Thu, Feb 06, 2003 at 10:04:56AM -0500, Stefan Seefeld wrote: > In the context of manipulating a DOM tree, an important question is > (as I already mentioned) how to take out a subtree, put it into > another context, or even another document. That's something that > hasn't been addressed yet, and which should be added before the > API can be considered complete. I've been thinking about this subject, in relation to my mail of a few minutes ago talking about iterators belonging to the Document (or other enclosing container) rather than to a Node. Maybe some kind of "root-node" type is needed, to which other nodes are attached and which can be iterated over. A Document would have (or be a refinement of) a root node, and a sub-tree that is copied from another tree could be attached to a new root-node. The root-node could even serve as Stefan's ClipBoard concept for owning orphaned Nodes. Kind of thinking out loud, you can ignore me until I can show a patch along these lines. jon -- "The tools we use have a profound (and devious!) influence on our thinking habits, and, therefore, on our thinking abilities." - Edsger Dijkstra |
949 messages has been excluded from this view by a project administrator.
