I suspect that one reason you have had no response to this carefully
argued email is that us old-timers don't want to open this discussion
again. The VXL book has a short summary of these discussions at
last paragraph bears repeating
There have been two significant propositions
to accept a level 0.5 library - for smart
pointers, and binary IO. In both cases it
turned out to be relatively straight forward
to provide the required functionality without
the 0.5 library, and indeed the proposers
have found the alternative implementations
superior in many ways.
I was the joint-author of one of those proposals, and I have to agree
that the current design is much neater than if we had added it as a 0.5
library. The basic problem is that it is very difficult to avoid putting
new things in the 0.5 library once it exists.
I'm still somewhat equivocal on the need for a 0.5 level library. Just
recently, I could really have used mbl_log's run-time control facilities
in the optimisers in vnl_algo. However, the discipline of orthogonal
level 1 libraries and no level 0.5 lib has kept VXL's core nicely
organised and segmented. This is no mean feat on such an open-source
library, where every developer has better things to be doing with their
time. Note that the optimiser problem could be better solved by creating
a call-back function that queries a public interface to the optimisers.
As for the promotion of mbl_log, I'm always happy to see more of my code
in the core. However it is very new code, and was still being developed
and had significant bugs only a few weeks ago. If you can confirm that
you are successfully using it, and no-one objects I'll move it into vul.
I wrote vil_exception as an initial experiment to see if that pattern is
useful in core VXL - We already use exceptions in our private codebase.
I haven't had much feedback, but if people like it, it is pretty cheap
to copy to all the other level-1 libs.
Miguel A. Figueroa-Villanueva wrote:
> Hello everyone,
> Lately, I've been missing a few features in the core libraries, which I
> think should be available. I know this probably has been discussed
> heavily, but given that I am relatively new to this list and that there
> have been some changes in compiler support as well as some efforts to
> reduce the restrictions on core library code, I would like to get an
> idea of what is the consensus of the community about this.
> If there is no interest in other points of this message, at least I
> would like to propose the promotion of mbl_log to vbl (for use in
> libraries like vidl and vgui).
> Some of the main features I would like to see available are:
> 1. consistent error handling - I think having exceptions (like
> vil_exception.h) and an error logger (mbl_log.h) is a good idea.
> Currently, there is vil_exception.h, vul_debug.h, vnl_error.h, but no
> consistent method. Also, for error logging I see a few '#if DEBUG's
> around, but again nothing consistent.
> 2. smart pointers - I guess this one is pretty well handled, except I
> would argue that a boost like smart pointer would be ideal for inclusion
> in vbl (i.e., so that one could do vbl_smart_ptr<vxl_object> without
> having vxl_object inherit from vbl_ref_count).
> BTW, what would be the way to pull out stuff from boost (like
> smart_ptr.hpp, any.hpp, etc). Pull it to v3p or create a fork and
> rename, reshape to vxl standards, and add to vbl, for example.
> 3. templated singleton - these I think are simply missing from the core
> except as hardcoded into the places that is needed duplicating code around.
> 4. templated factories - same as singleton.
> I understand and support the modularity found in vxl. However, I think
> that there is a difference in purpose/hierarchy between libraries that
> are useful for developing the core vision libraries of vxl (as well as
> higher level code) and the core vision libraries. In other words, I
> would argue that vbl,vul,vsl? should be at a lower level (0.5 level)
> than vil,vgl,vnl.
> An alternative would be to have a light-weight header-only library that
> includes things like those pointed out above (vbl type things). I guess
> this avoids having to link to another library, but increases compilation
> Of course, the other way is as it is done now... put things in vbl and
> if used in the core carefully duplicate the code. The problem is when
> the number of things that we are duplicating increases. With only,
> exceptions and smart pointers we might be able to reduce code
> duplication to a manageable size, but if we add log system, templated
> singletons, factories, etc it can start building up. So, the question is
> are we there yet?
> Thanks in advance for considering these issues.