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-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: 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: 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: 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 |