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.


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

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

                                               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.
GNU: never give up freedom    

vos-d mailing list

Reply via email to