April 2004 - Boost - lists.preview.boost.org

[optional] proposal for extension
by JOAQUIN LOPEZ MU?Z 01 Apr '04

01 Apr '04

In the rationale of Boost.Optional, optional<T> is proposed as a convenient replacement of the time-honored practice of returning a std::pair<T,bool> with the bool indicating whether the T object is meaningful or not. Notably, this is precisely what some STL containers' memfuns do. So why not augment optional<T> with the following: optional<T>::optional(std::pair<T,bool> const&); and the obvious semantics? This would allow for instance to use optional<> like this: std::set<int> s; ... boost::optional<int> oi=s.insert(10); // oi is initialized iff insertion took place. Comments? Apologies if this has been discussed previously. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

6 5

RE: [boost] Re: Region Library?
by Hanson, Iain 01 Apr '04

01 Apr '04

> From: Allan Odgaard [mailto:ML@Top-House.DK] Sent: 30 March 2004 22:25 > > > Yes -- although I personally do need it even when I do not write > operating systems ;) and thus my question really was if there is any > general interest in such a library, since I did exhaustive searching > and was only able to find such region stuff implemented > publicly in the > GDK/GTK library, which is ANSI-C AFAICT, and that led me to the > conclusion that either there is no real use for this stuff > outside GUI > kits, windowing systems, and 2D games or efficient region "logic" is > often skipped for ad hoc workarounds like using bounding boxes or > refreshing more than necessary -- in which case there really ought to > be a library. > I think that there really is a need for such a library. From what I have seen, many libs that need this either use ad hoc solutions as you suggest above, or they re-invent the wheel and the solution they come up with is intimately bound up with their problem space and therefore not easily re-useable. /ikh ------------------------ #include <std_disclaimer> Everything following this line has been provided courtsey of my ISP and I have no control over it. ============================================================================== This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. ==============================================================================

2 1

Re: [boost] geometry2d: Whats the status of geometry2d in theboostvault?
by Tom Brinkman 01 Apr '04

01 Apr '04

>> SFINAE makes it possible, and we have something proprietary along these lines here at work. I'd by happy to elaborate more on specific questions if you are interested to know more. Yes, sounds interestion. While I'm sure that your concerns are valid about this library in its current state, i've found this library to be good enough. It may not be perfect, but its a better rectangle class than any i've seen. I think that we should get it reviewed by others and try to get it added to the main boost cvs. When an improved geometry class comes along, we could add that one to boost as well. Geometry2d is not a complicated library, as it consists of only one header file, and would be easy enough to just add it to the utility folder. Just my thoughts, Tom brinkman __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html

3 2

C++ subranges
by Brian Martin 01 Apr '04

01 Apr '04

Hi Brian Martin wrote: > I have a suggestion for a simple Boost feature - subranges. [...] > The big question is, do any of you think this is a useful enough feature? Maciej Sobczak wrote: >Yes, it is. >What's more, the biggest gain (in my humble opinion, of course) is not >the bare fact that you can have range checking at run-time, but that it >is possible to provide range checking at *compile-time*, thus >strengthening the type system. There are some interesting ideas in your code. The current version of my subrange class does not trap potential compile time errors. Your technique of using template specialisation for this is a good idea but unfortunately the following gets past my (Borland) compiler: range<0, 200> k4(500); and it would be nice to catch this. Also, I don't see how the following can ever be trapped by a compiler: range<0, 100> i(4); i = 98; i++; ++i; surely that is a runtime thing. One possible idea for catching the first one is to redefine the template as follows: template <long L, long U, long V> class range { long v_; public: range() { static_assert<L <= V && V < U>(); v_ = V; } }; I've tried this on a simple example and it seems to work. Unfortunately, what you pass to V has to be a constant expression. Thus this won't compile at all: const long x = 2; range<0, 10, x> my_range; Even though x is in range and const. I suppose it's a const "variable". Drat. Your class doesn't have the concept of a "base type". It's a template restricted to longs. Class subrange allows restriction of any type that supports the appropriate numerical operators (even classes - admittedly a bit dubious). This is similar to the Pascal facility where you can have subranges on any ordinal type (i.e. integral numerical, character or enumeration) e.g. type LowerCaseChar = 'a'..'z'; type UpperCaseChar = 'A'..'Z'; type DaysOfTheWeek = (Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday); // equal to a C++ enum declaration type WorkingDay = Monday..Friday; // For those who don't work weekends! I know that C++ does implicit conversions from say char to int etc. e.g. typedef range<'a', 'z'> lowercase_char; but typedef subrange<char, 'a', 'z'> lowercase_char; is a bit more "self documenting". The specification of the base type char makes it clear we're storing characters and not longs. I'll have another think about some of the compile time check issues. Regards, Brian Martin _______________________________________________ Unsubscribe & other changes: <http://lists.boost.org/mailman/listinfo.cgi/boost>

1 0

C++ subranges
by Brian Martin 01 Apr '04

01 Apr '04

I have a suggestion for a simple Boost feature - subranges. For those of you who may not know, subranges are a Pascal idea. Using un-restricted numeric types such as ints, shorts and floating point types is somewhat dangerous. For example, if you write a function that, given a date, returns the number of the day in the year that date falls on, what type do you return? Most C/C++ programmers would automatically use an int but ints can be negative and -1 as a day of the year is meaningless. So use unsigned types. But then 0 is invalid, as is any value above 365. Subranges to the rescue... In pascal one would write type DayOfYear = 1..365; function NthDayOfYear(const d : Date) : DayOfYear; The type statement declares a new data type that is restricted to the range 1 to 365 and this is used as the return type of the function. If NthDayOfYear has a fault that sometimes generates a value outside this range, you'll get a runtime error. The idea is to have range checking switched on during development, but to switch if off for release code for efficiency reasons, something that all good pascal compilers can do. My own personal experience having used pascal type languages with this feature is that it's very, very useful indeed. On a number of projects, subranges have illuminated obscure bugs in my code that I might otherwise have missed. After having switched to C++ from Pascal, I soon found myself missing subranges so I wrote a class template that emulates them: template <typename T, T min, T max> class subrange; This would contain the usual operators/constructors etc. that I've omitted for shortness. The above example would now become in C++: typedef subrange<int, 1, 365> day_of_year; day_of_year NthDayOfYear(const Date& d); The class is very simple - all it does is store a value and then checks to make sure it's always in the range min to max when you assign variables of type T to it, do arithmetic and so on and throws an exception if the new value is out of range. A preprocessor symbol is used to switch this range checking on or off as required so that you can release code without the checking overhead. The big question is, do any of you think this is a useful enough feature? Regards, Brian

2 1

Service Pack 6 for Visual Studio 6.0 released
by Bronek Kozicki 01 Apr '04

01 Apr '04

Relevant Knowledge Base article with list of fixes is here http://support.microsoft.com/default.aspx?scid=kb;en-us;834001 Actual download (63MB) is here http://www.microsoft.com/downloads/details.aspx?FamilyId=A8494EDB-2E89-4676… I though that Boost.Python users might be interested B.

3 6

simplifying library install names
by Benjamin Kosnik 01 Apr '04

01 Apr '04

When I build boost-1.31.0, like so: bjam -sPYTHON_ROOT=/usr -sPYTHON_VERSION=2.2 -sTOOLS=gcc -sBUILD=release --prefix=/usr I end up with a bunch of oddly-named library files: libboost_filesystem-gcc-1_31.a libboost_filesystem-gcc-1_31.so.1.31.0* libboost_filesystem-gcc.a libboost_filesystem-gcc.so* is there a way to run bjam or configure the build process so I get something sensible, like: libboost_filesystem.a libboost_filesystem.so.1.31.0 libboost_filesystem.so (symlink) ? best, benjamin

2 2

BGL least common ancestor
by Walter Landry 01 Apr '04

01 Apr '04

Greetings, Does anyone have an implementation of least common ancestor (LCA) for the graph library? I could hack something together to fit my needs, but it would be nice if someone already did the work for me. Thanks, Walter Landry wlandry(a)ucsd.edu

1 0