Also spracht Peter Amstutz (Tue, 18 Mar 2008 11:09:24 -0400): > On Mon, Mar 17, 2008 at 07:33:24PM +0000, Lalo Martins wrote: >> Well. I spun off the web MVC stuff into a new library (hypervos). >> That opened a pandora box of generator fun :-) > > Yea, as you've probably figured out by now, writing good C++ is hard, > but automatically generating good C++ is even harder.
:-D >> 2: The #define guards use only the file name. If you have headers with >> the same name in different libraries (eg MVC.hh)... you get my point I >> think. I manually changed them to eg #define _hypervos_MVC_hh_, might >> make the change in the generator later. > > Oops. Yes, the generator should be smarter than that. See my comment > below about directory organization for headers. Fixed in my branch (assuming we agree _hypervos_MVC_hh_ is good enough). >> 3: Much worse happens if you have namespaces with the same name :-) the >> generated code has things like MVC::View all over, which of course >> generate "ambiguous namespace reference" errors galore. > > This is a bit of a pathalogical case, although hopefully now you see the > reason for the site_xxx namespace. > > The brute force solution would be to have the generator go ahead and > qualify everything with the excessively long site_xxx namespace, which I > was trying to avoid purely for the sake of readability. Ah no, you're taking it a step further. I'm referring to VOS Namespace objects, not C++ namespaces in general. See, you already solved this problem ;-) since we encourage each library to ship one Library object, named the same as the library, and then a number of Namespace objects inside it. Splitting a (VOS) Library in different (C++) libraries and/or directories would, yes, be a problem, but we'll cross that bridge when there is even water on the river ;-) What I'm talking about is... - Site 0011223344556677889900aabbccddee - Library vos - Namespace MVC - Site 6879706572766f73203474656877696e - Library hypervos - Namespace MVC See? So that could be handled in C++ (and it's how I solved it by manually editing the files, but that means I can't atm run the generator on mod_vos or my other project) by qualifying it with vos::MVC:: or hypervos::MVC:: >> 4: This is unrelated to the hypervos move, I noticed it earlier. If my >> class "Foo" extends "vos::core::Bar", then Foo.hh will have #include >> "Bar.hh" >> which of course won't work so well... should be <vos/Bar.hh> :-) > > Since I was originally focused on getting the libvos core to work, I > didn't give too much thought to how the C++ headers should be explictly > organized into directories. Again, the brute force solution would be to > have the headers mimic the namespace up to and including the site, which > would be horribly verbose but would eliminate most of the ambigious > cases. Again, you're forgetting we already have the handy Library object, which I'd like to encourage developers to keep unique-ish. So <vos/Bar.hh> would do it (and, bonus of bonuses, already works with our current layout!), and it's what I made the generator do, in my branch. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ _______________________________________________ vos-d mailing list email@example.com http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d