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 protected]
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
