On 1/18/06, Miguel A. Figueroa-Villanueva <miguelf@...> wrote:
> Matt Leotta wrote:
> > On 1/18/06, Miguel A. Figueroa-Villanueva <miguelf@...> wrote:
> >>BTW, vidl2 is intended as a level-2 library, right? In other words, the
> >>restrictions stated in the VXL Book 3.3 don't apply, right?
> > Yes, vidl2 is intended to become a level-2 library.
> > My interpretation for section 3.3 is that RTTI and exceptions are
> > allowed, but not in level-1 core libraries. The rest of the items are
> > not allowed in any level core library, and maybe not in contrib
> > either. Someone correct me if I'm wrong about that. That said, maybe
> > this list needs to be reevaluated. Are we still supporting all of
> > those old compilers?
> I guess maybe we should detail this better, to make sure we're all on
> the same page. Probably after we decide what is the current state of
> affairs regarding compiler usage.
> >>I am using:
> >>- member templates (not supported by SGI CC 7.2.x).
> >>- partial template specializations (not supported by SGI CC 7.2.x).
> >>- non-type parameters in function templates (not supported by SunPro 5.=
> > Your code is very nice and makes good use of generic programming.
> > Unfortunately, I think this use of templates is a bit too extreme for
> > some of the aging compilers that VXL supports. The good news is most
> > of what you want can be done in VXL in an uglier, non-generic way.
> > For example, vgui uses a similar sort of factory for tool-kits and
> > uses the singleton class model for gui managers. You've already had
> > some discussion about exceptions. The only think I haven't seen in
> > VXL is threads. It would be really nice to have a cross platform
> > multi-threading library in VXL, but that's a whole other project.
> I have unit test files (e.g., for the dashboard) for the exception,
> singleton, and factory code. I've tested it in MSVC 7.1 and gcc
> 3.4.2/3.4.4 with no errors or warnings. However, I'm pretty sure it
> won't compile in MSVC 6.0 (but I think even Microsoft doesn't support
> MSVC 6.0 anymore).
> Obviously I put a lot of effort into sorting through and adapting the
> code, because (IMHO) I believe we have reached a point were generic
> programming is widely supported and quite useful. However, I understand
> the reasons for the initial restrictions, so if it is necessary to do it
> differently then that will have to do... That said, I really wouldn't
> like to discard the opportunity to relax these restrictions. If there
> aren't any objections, I would like to follow Ian's suggestion of
> surveying the lists to find out what is the current compilers being
> used. I can also set things up so that the code is unit tested and
> posted in the dashboard to see wether this is feasible.
I completely agree with this, generic programming seems to be
supported quite well these days and is very useful. I would like to
see some of these restrictions relaxed a bit if possible.
To start off your survey, I can tell you that at Brown we use gcc in
Linux and MSVC in Windows. I don't think anyone is using gcc older
than 3.3, and I think everyone here has finally dropped MSVC 6.0. I
will double check this tomorrow and get back to you.
> > Another issue here is namespaces. VXL was designed to avoid
> > namespaces because: " few compilers support namespaces well, and their
> > implications in large-scale development are as yet poorly understood"
> > (VXL Book 1.4.2). I have rarely seen namespaces used in VXL, but I
> > haven't seen anything prohibiting them either. Are namespaces allowed
> > in VXL?
> Yes, I suspected this was going to be an issue... I don't see a problem
> using prefix instead of namespaces in most cases. What about unnamed
> namespaces vs. static qualifier for indicating file scope? If I remember
> correctly, the standard deprecated the use of static qualifier for this..=
I have seen anonymous namespaces used in some of the test programs,
but I don't know the official ruling on if this is allowed.
> Well, I hope we can relax things a bit, but I'll adjust to whatever is