[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mico-devel
Subject:    Re: [mico-devel] No MICO for Sparcworks Solaris 2.7 users
From:       520065607613-0001 () t-online ! de (Frank Pilhofer)
Date:       2001-09-19 15:28:29
[Download RAW message or body]

Andrew Marlow wrote:
>
> I have just been test building the beta 2.3.6 MICO
> on Solaris 2.7 and have found something rather worrying.
>
> I have read the changes log and I understand that people
> despise compilers that STILL don't understand namespaces.
>

   Hi,

 I certainly understand your complaint. The decision to drop non-namespace
support has not been an easy one. Since I'm the one who's ultimately respon-
sible for the change, let me explain.

 It's ultimately a problem with include files, and the order classes are
defined in. With structs for namespaces, the ordering options are pretty
limited, since it is not possible to re-open a class definition. If you
need a forward-declaration of a thing from another namespace, you're
screwed. With namespaces, this problem does not appear.

 Namespaces are a means of organization. In the current MICO code, a lot
of MICO's classes are in the CORBA namespaces for the above reason: because
you couldn't forward-declare them, they had to be moved. It was dirty, but
the only way to get it to work.

 CORBA.h previously used a lot of magic, including some include files more
than once to pull in stuff from various namespaces. But look at it now: it's
simply linear.

 Adding anything to CORBA.h used to be delicate work, because the placement
of the #include depended not only on already-declared stuff, but also on
the namespace.

 Things like the Interface Repository, which is an IDL-generated file, but
also in the CORBA module, were pretty fragile.

 Namespaces make this so much more maintainable.

>
> Unfortunately, this is what it is like with commercial unix
> compilers.
>

 Yes, this makes Mico impossible to work with some compilers, and we have
considered this. However, I believe that for all current commercial Unix
platforms, there are now namespace-aware C++ compilers available.

 As for cfront, well, that's been a kludge to start with. But for whoever
still needs something like that, there are, I believe, commercial C++ to
C converters available that also support templates and namespaces and
such.

>
> I know from previous MICO releases what a pain it is
> to simulate namespaces with structs but this is what 
> commercial ORBs have to do
>

 IIRC, both ORBacus 4.x and Orbix 2000 use namespaces, so this argument
is not really valid.

	Frank


-- 
Frank Pilhofer  ...........................................  fp@fpx.de
Life is what happens to you while you're busy making future plans.
- Alfred E. Neuman
_______________________________________________
mico-devel mailing list
mico-devel@mico.org
http://www.mico.org/mailman/listinfo/mico-devel

[prev in list] [next in list] [prev in thread] [next in thread]