From: Miguel A. Figueroa-Villanueva <miguelf@ms...> - 2006-02-06 04:10:26
I have collected the results of the VXL Compiler Survey. A tabulation of
the results and a copy of the messages received has been posted at:
In summary, people are using MS Visual Studio 6.0 and above and GCC 3.3
and above. No one reponded with compilers such as Borland, ICC, etc.,
although Fred Wheeler does keep some of these combinations in the dashboard.
In my experience, the people using gcc wouldn't have any problems in
upgrading to a higher version if necessary and tend to be more
up-to-date given the nature of it's distribution (i.e., not commercial
app). Hence, nobody seems to be tied to gcc2.95, for example.
This is not true for people using MSVS. However, most people using VS
6.0 are willing to drop it and move on. This is with the exception of
two responses. Markus Meyer, which also uses gcc, and Brad King on
behalf of ITK. Here Brad King points out that there has been talk in ITK
about dropping it and, more importantly, that "Dropping support for VS 6
does not have to mean all of VXL." It would probably be worth mentioning
at this point that even Microsoft does not support VC++ 6.0 anymore
(retired extended support).
IMHO, I think there are a lot of modern programming techniques that are
useful and which VXL should take advantage of. For example, there was a
discussion in the list recently about static asserts, factories,
singleton_holders, etc. to which Fred Wheeler commented about including
such things in vbl:
"I have no objection and defer to the wisdom of this list. My name is
next to vbl because we decided each library should have a lead
developer, but I have not touched vbl in a long time. If there is a more
appropriate and willing person they are welcome to take over the role."
I think that the responsible approach to take is to create a contrib
library (say contrib/vbl2, which I would volunteer to maintain) or use
an already created one like mul/mbl (although this one has a bit more
than basics, it seems) as a place to test-drive, put up for promotion to
the core, and post for review and comments code such as the static
After we see the effects of each independent piece of code to the
dashboard we can consider what are the ramifications of promoting it to
the core in terms of relaxing rules and compiler support. We will also
gain insight on what parts of the standard are robustly supported and
decide wether to allow these parts on the core in general or not. In
other words, why not take it one step at a time instead of commiting to
changes in the rules prematurely?
Any comments about this proposal?
Finally, I would like to point out the email from Matt Sandler
mentioning that, given modern compilers, maybe there is "an opportunity
to simplify some aspect of the labeling schemas [i.e., abuse of prefix
in names], such as by using namespaces, etc. to improve legibility".
I just point it out for completeness in case it is worth discussing,
since I don't know the history concerning this and suspect there is
little or no interest to change this approach.