From: Matt L. <mat...@gm...> - 2006-01-17 17:39:49
|
Hello all, Is there currently any static assert mechanism in VXL? By this I mean a macro that evaluates a boolean expression at compile time and produces a compiler error if false. Boost has one (called BOOST_STATIC_ASSERT). I'm looking for something to check for template instantiation with an inappropriate type. I can certainly use a standard assert, but it seems silly since the condition is known at compile time. If I was to add such a macro, where is the appropriate place to put? It would just be a macro in a header file. It seems if it went in vbl or vul it might give the impression that it depends on those libraries. Is vcl strictly limited to standard library functions?=20 Could it go there? Thanks, Matt Leotta Brown University |
From: Ian S. <ian...@st...> - 2006-01-17 18:08:03
|
Matt Leotta wrote: > Hello all, > > Is there currently any static assert mechanism in VXL? By this I > mean a macro that evaluates a boolean expression at compile time and > produces a compiler error if false. Boost has one (called > BOOST_STATIC_ASSERT). In the past we've done it manually, i.e. #if (!asserted_condition) The asserted condition is not true, and these lines are not valid C++ so you will get a compiler error. #endif > If I was to add such a macro, where is the appropriate place to put? > It would just be a macro in a header file. It seems if it went in > vbl or vul it might give the impression that it depends on those > libraries. Is vcl strictly limited to standard library functions? Yes - mostly. > Could it go there? The answer in the past has been no - mostly. A few exceptions have been made for stuff used internally by VXL and not for use by vxl-users. e.g. VCL_DEPRECATED(), vcl_where_root_dir(). Although the latter function is deprecated in favour of CMake supplying the test program with the info at run time, and I don't see how the former couldn't just be provided in vul, and replicatd in any other level-1 libraries that need it.) Ian. |
From: Matt L. <mat...@gm...> - 2006-01-17 18:30:43
|
Ian, On 1/17/06, Ian Scott <ian...@st...> wrote: > > In the past we've done it manually, i.e. > > #if (!asserted_condition) > The asserted condition is not true, and these lines are not > valid C++ so you will get a compiler error. > #endif Unfortunately, this will not work with template instantiation because the condition is known during template instantiation but not during preprocessing. The Boost version is a bit more complicated: http://www-eleves-isia.cma.fr/documentation/BoostDoc/boost_1_29_0/boost/sta= tic_assert.hpp > > Could it go there? > The answer in the past has been no - mostly. A few exceptions have been > made for stuff used internally by VXL and not for use by vxl-users. > e.g. VCL_DEPRECATED(), vcl_where_root_dir(). Although the latter > function is deprecated in favour of CMake supplying the test program > with the info at run time, and I don't see how the former couldn't just > be provided in vul, and replicatd in any other level-1 libraries that > need it.) > I have no problem putting it in vul. I was just wondering if there was a special place for macros like this. Using this macro would not create a dependency on vul, so it seems silly to need to duplicated such a header file. But maybe other level-1 libraries will never need to use it. Thanks, Matt |
From: Miguel A. Figueroa-V. <mi...@ms...> - 2006-01-17 18:52:12
|
BTW, Where whould be the correct place to add things like: 1. singleton: (a simple version motivated from loki library) the usage is as follows: #include <singleton_holder.h> class object_to_be_singled { SINGLETON_PROTECTION(object_to_be_singled); ... }; object_to_be_singled& single_obj1 = dpl::singleton_holder<object_to_be_singled>::instance(); 2. exceptions: is this still prohibited in level 1 libraries? I see vil_exception.h, and I think a mechanism such as this with a hierarchy of exceptions derived from say vxl_exception would be useful... Of course with the ability to turn it off. //----------------------------- - a generic object factory ... giving finishing touches to this... but the idea is to allow something like this: #include <factory.h> #ifdef HAS_DSHOW #include <vidl2/vidl2_directshow_istream.h> #endif ... namespace { factory< vbl_smart_ptr<vidl2_istream> > vidl2_factory_init(void) { factory< vbl_smart_ptr<vidl2_istream> > vidl2_factory; #ifdef HAS_DSHOW vidl2_factory.insert<vidl2_directshow_istream>("DirectShow"); #endif return vidl2_factory; } const factory< vbl_smart_ptr<vidl2_sitream> > vidl2_factory_ = vidl2_factory_init(); } ... //----------------------------- I have all of these implemented in header files, so there is no need to link to libraries. --Miguel |
From: Ian S. <ian...@st...> - 2006-01-17 19:27:10
|
Miguel A. Figueroa-Villanueva wrote: > BTW, Where whould be the correct place to add things like: > > 1. singleton: (a simple version motivated from loki library) the usage > is as follows: > vbl is the obvious location. > > > 2. exceptions: is this still prohibited in level 1 libraries? According to http://paine.wiau.man.ac.uk/pub/doc_vxl/books/core/book_3.html#SEC27 core libraries (i.e. the ones in vxl/core) are not allowed to use exceptions. I bent that rule when I introduced vil_exception.h so that it might read something like "Core libraries should build and run correctly on compiler without exceptions". I think that all of VXL actually needs to compile on platforms without exceptions since at least one of the DART test builds doesn't have exceptions. > I see > vil_exception.h, and I think a mechanism such as this with a hierarchy > of exceptions derived from say vxl_exception would be useful... Of > course with the ability to turn it off. We have been using exceptions for a year or two now in our private codebase, where they are assumed to be available. mbl_exception was developed to provide exceptions that would behave slightly less usefully - but still correctly and meaningfully - if VCL_HAS_EXCEPTIONS is false. I copied mbl_exception to vil_exception when Amitha asked for a way of reporting mismatched vil_image_view conversions that was more visible than the existing "Return empty view" method. It is also on my ToDo list to add a vsl_exception.h and use them instead of the stream error reporting method, and to replace the few vcl_aborts that are buried in vsl. I don't think that there is any need for a centralised vxl_exception, and I believe that it would cause some problems. I want to derive a particular exception from vcl_runtime_error and another from vcl_logic_error. vxl_exception and derivatives can't optionally be derived from particular STL provided exceptions. (I'm not inclined to mess with multiple inheritance here.) See mul/mbl/mbl_exceptions for some examples. Without the need for a centralised vxl_exception, there is nothing else related to exceptions that needs to be shared amongst the core level-1 libraries. vil_exception_error() and vil_exception_warning() functions are trivial and cheap to replicate in each level-1 library. > > //----------------------------- > - a generic object factory ... giving finishing touches to this... but > the idea is to allow something like this: I wrote one of thus a while back - contrib/mul/mbl/mbl_cloneables_factory http://paine.wiau.man.ac.uk/pub/doc_vxl/contrib/mul/mbl/html/classmbl__cloneables__factory.html It is tested and fairly widely used in our private codebase. If it meets your needs, it can be moved to vbl. Or if yours is better - we can add that to vbl. Fred - You are the lead developed for vbl - any objections to this sort of stuff being added to vbl. Ian. |
From: Miguel A. Figueroa-V. <mi...@ms...> - 2006-01-17 20:04:02
|
Ian Scott wrote: > Miguel A. Figueroa-Villanueva wrote: >> 2. exceptions: is this still prohibited in level 1 libraries? > > I don't think that there is any need for a centralised vxl_exception, > and I believe that it would cause some problems. I want to derive a > particular exception from vcl_runtime_error and another from > vcl_logic_error. vxl_exception and derivatives can't optionally be > derived from particular STL provided exceptions. (I'm not inclined to > mess with multiple inheritance here.) See mul/mbl/mbl_exceptions for > some examples. > > Without the need for a centralised vxl_exception, there is nothing else > related to exceptions that needs to be shared amongst the core level-1 > libraries. vil_exception_error() and vil_exception_warning() functions > are trivial and cheap to replicate in each level-1 library. Personally, I don't like deriving from STL exceptions, but rather encapsulating the errors with the subsystem that generated them... That said, with the requirements as you describe and the design philosophy of VXL, I agree that the best thing is to replicate the xxx_exception_error/warning() for each library that wants to use it. >> //----------------------------- >> - a generic object factory ... giving finishing touches to this... but >> the idea is to allow something like this: > > > I wrote one of thus a while back - contrib/mul/mbl/mbl_cloneables_factory > > http://paine.wiau.man.ac.uk/pub/doc_vxl/contrib/mul/mbl/html/classmbl__cloneables__factory.html > yes, actually I looked at it carefully a while ago and I think there is a need for both... If I remember correctly, the cloneables factory implements the Prototype design pattern [GoF], which clones/copies an in-memory object. I think this is useful in many scenarios, but in cases where it is costly to instantiate the objects or have resources initiated (like in video capture (vidl2)) then a design like the one described in "Modern C++ Design" might be more appropriate. In this design the object is not created until it is requested. I'm sure there is a trade-off, I just can't think of it now... for example, there probably are cases when it is cheaper to clone/copy an object than to ask for a new one on the heap? In any case, I'm pretty sure that it would be good to have both in vbl. > > It is tested and fairly widely used in our private codebase. If it meets > your needs, it can be moved to vbl. Or if yours is better - we can add > that to vbl. > > > Fred - You are the lead developed for vbl - any objections to this sort > of stuff being added to vbl. > > Ian. --Miguel |
From: Miguel A. Figueroa-V. <mi...@ms...> - 2006-01-18 12:34:12
Attachments:
vidl2_files.tgz
|
If this is not an appropriate way to submit code for VXL, please let me know the prefered way to submit. -- Matt, I have attached a few files to support factory creation of vidl2_istream. The four *.h files probably belong elsewhere (e.g., vbl), but in the meantime I think they can reside in vidl2. Note that the code is provided for inspection. If it is decided that this is a reasonable approach to solving the problem, then I can go in and fix some naming issues, remove namespaces, etc. to make it more VXL-like. 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? 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.0). which I don't see a way of getting around it so easily. I hope this helps. I'll push hard for a vidl2_directshow_istream next. --Miguel |
From: Ian S. <ian...@st...> - 2006-01-18 17:32:14
|
Miguel A. Figueroa-Villanueva wrote: > If this is not an appropriate way to submit code for VXL, please let me > know the prefered way to submit. You seem to know what you are doing, If you email us with a bit of a description of yourself - what you are using VXL to do - and your Sourceforge username - we'd give you write access to the repository. Basic commit rules: Check with the vxl-maintainers if you are unsure if your change may be suitable for VXL. Make sure your code compiles correctly and warning free on your compiler before you commit. Fix any problems that the dashboard picks up with your own code, or your own changes. > > -- > Matt, > > I have attached a few files to support factory creation of > vidl2_istream. The four *.h files probably belong elsewhere (e.g., vbl), > but in the meantime I think they can reside in vidl2. Note that the code > is provided for inspection. If it is decided that this is a reasonable > approach to solving the problem, then I can go in and fix some naming > issues, remove namespaces, etc. to make it more VXL-like. > > 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? My interpretation of the VXL book is that they do apply. The restrictions in Section 3.3 apply to all code in the VXL repository. The ones specially marked as applying to core apply to all code in VXL/core. The level number is to avoid too much interdependence in the lower level libraries. > > I am using: > > - member templates (not supported by SGI CC 7.2.x). or MSVC 6 > - partial template specializations (not supported by SGI CC 7.2.x). or MSVC 6 > - non-type parameters in function templates (not supported by SunPro 5.0). > > which I don't see a way of getting around it so easily. Well you can find out if a particular feature is provided by looking up the appropriate macro in vcl_config_compiler.h (you shouldn't #include that file directly - it is included by all the vcl*.h files) You could then provide an alternative implementation for those compilers that don't provide it. The rules may be a bit out-of-date - they were written when compiler technology was much less good. Most compilers should support those features now. I'd support a relaxation of those rules having moved off MSVC 6 about 6 months ago. If you want to propose such a relaxation, then I'd suggest surveying vxl-users and vxl-maintainers to see if that was feasible, and to find out what compilers the community is currently using. Ian. |
From: Miguel A. Figueroa-V. <mi...@ms...> - 2006-01-18 21:45:23
|
Hello everyone, I am currently a graduate student at Michigan State University. I work in the Pattern Recognition and Image Processing Lab in the Computer Science and Engineering Department. My interests are mainly in face modeling, and I've been using Dr. Cootes binary distribution of the AAM code for my research. I've also done some fingerprint work. As far as using VXL goes, I've been using the core libraries for image manipulation, smart pointers (vbl), file handling (vul), etc. I have been regularly submitting 4 builds (site miguelf) to the dashboard for a few months now and I am interested in helping with the developement of the vidl2 library, for which I am requesting the developer access. I am also expected as a faculty member next fall at the University of Puerto Rico - Mayaguez Campus (http://www.ece.uprm.edu/) where I expect to promote the adoption of VXL for our research in remote sensing and other areas. Well, at least that's my vision, but I'll certainly continue using it myself (and maybe force a few students ;) )... In case you think it is appropriate for me to be granted developer access, my sourceforge username is: miguelfv If there is any other information you would like me to provide, please let me know. Thanks, Miguel -- Miguel A. Figueroa-Villanueva Ian Scott wrote: > You seem to know what you are doing, If you email us with a bit of a > description of yourself - what you are using VXL to do - and your > Sourceforge username - we'd give you write access to the repository. > > Basic commit rules: > Check with the vxl-maintainers if you are unsure if your change may be > suitable for VXL. > Make sure your code compiles correctly and warning free on your compiler > before you commit. > Fix any problems that the dashboard picks up with your own code, or your > own changes. |
From: Matt L. <mat...@gm...> - 2006-01-18 17:59:44
|
On 1/18/06, Miguel A. Figueroa-Villanueva <mi...@ms...> wrote: > If this is not an appropriate way to submit code for VXL, please let me > know the prefered way to submit. Miguel, maybe one of the VXL administrators can give you developer access so you can check code in using CVS. > 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 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.0)= . Your code is very nice and makes good use of generic programming.=20 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.=20 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. 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? --Matt |
From: Paul C. <ps...@gm...> - 2006-01-18 21:24:00
|
Hi, First a little about me. I'm the intern Brendan mentioned a little while ago. I'm about to enter my honours year at Otago. vxl will be used as part of one of my papers this year. I've already got DirectShow stuff working, it's just a question of making the style more in the form of VXL, and sorting out a few things like that. When I say working, I'm able to capture a single image, or a series of images from either usb or firewire cameras (I'm able to set the various options such as the capture window size, and the palette that the programmer wants to use). I've not done anything about decoding the various types of streams -- I saw the emails on this list, and thought that it was silly to re-do it. There's also code for linux, presently this does *not* work with firewire there's still some work to do there. Is there someone already working on firewire capture in linux? If you'd like to have a look at the code in it's present state, let me know= . On 1/19/06, Miguel A. Figueroa-Villanueva <mi...@ms...> wrote: > [snip] > I hope this helps. I'll push hard for a vidl2_directshow_istream next. > > --Miguel > ------------------------------ Paul Crane ps...@gm... ------------------------------ |
From: Miguel A. Figueroa-V. <mi...@ms...> - 2006-01-18 22:00:46
|
Hi Paul, I also have some code I need to dig out that captures using DirectShow, but I certainly would welcome your code to sort out if we're using the same approach or maybe yours is cleaner and/or more flexible. Actually, I don't think I was using vil images back then, so probably that would also be helpful. The task here is basically reshaping it into the vidl2 naming convention and interface. I am willing to volunteer for this task and would most certainly appreciate your feedback. If you would like to take on the task I can provide you with my code as well. I guess we can continue this discussion off the list since it is just a matter of workforce management :) Thanks, --Miguel Paul Crane wrote: > Hi, > > First a little about me. I'm the intern Brendan mentioned a little > while ago. I'm about to enter my honours year at Otago. vxl will be > used as part of one of my papers this year. > > I've already got DirectShow stuff working, it's just a question of > making the style more in the form of VXL, and sorting out a few things > like that. > > When I say working, I'm able to capture a single image, or a series of > images from either usb or firewire cameras (I'm able to set the > various options such as the capture window size, and the palette that > the programmer wants to use). I've not done anything about decoding > the various types of streams -- I saw the emails on this list, and > thought that it was silly to re-do it. There's also code for linux, > presently this does *not* work with firewire there's still some work > to do there. > Is there someone already working on firewire capture in linux? > > If you'd like to have a look at the code in it's present state, let me know. > > On 1/19/06, Miguel A. Figueroa-Villanueva <mi...@ms...> wrote: > >>[snip] >>I hope this helps. I'll push hard for a vidl2_directshow_istream next. >> >>--Miguel >> |
From: Miguel A. Figueroa-V. <mi...@ms...> - 2006-01-18 22:34:45
|
Matt Leotta wrote: > On 1/18/06, Miguel A. Figueroa-Villanueva <mi...@ms...> 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.0). > > > 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. > 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... Well, I hope we can relax things a bit, but I'll adjust to whatever is decided. Thanks, --Miguel |
From: Matt L. <mat...@gm...> - 2006-01-19 01:39:27
|
On 1/18/06, Miguel A. Figueroa-Villanueva <mi...@ms...> wrote: > Matt Leotta wrote: > > On 1/18/06, Miguel A. Figueroa-Villanueva <mi...@ms...> 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.= 0). > > > > > > 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 > decided. > > Thanks, > --Miguel > --Matt |