The C++ standards committee's Library Working Group has proposed a schedule for library changes and extensions: * October 2005: cutoff date for C++0x major library proposals * October 2006: cutoff date for library TR2 proposals * April 2007: cutoff date for C++0x library clean-up papers The usual rule-of-thumb is that new library components go in TR2, while changes to existing components go in C++0x. The LWG will consider exceptions to the rule on a case-by-case basis. The LWG is planning to issue a "Call for Proposals" with details, but in the meantime Boost developers might want to start thinking about which Boost libraries they want to propose to the LWG. Because most proposals go through one or more revisions before being accepted, it helps a proposal's chances if it reaches the committee as many meetings as possible before the final cut-off. So far there are plans to propose Boost.Threads, Boost.Filesystem, and Boost.Signals. As well as proposals for some of the more major libraries, I personally hope someone will do a sweep through Boost looking at some of the smaller utilities and helpers for a possible "Small Additions" proposal. --Beman
On Fri, 22 Apr 2005 14:26:23 -0400, Beman Dawes wrote
Short answer --> I'm working on it. Ridiculously Long answer --> It's taken much, much longer than I expected or wanted to get things to a place where I thought I could begin to make a coherent proposal to the committee. Since the first release I thought the core concepts time points, time durations, time periods, iterators, clocks, etc were the right ones. I also felt the 2 main implementations of these concepts (dates and times) where the most useful to the broadest range of applications. Experience has held up my expectations there. That said, there has been some really valuable evolution and conveniences added over the last few years as the library has been used in the real world. OTOH, since the first release I've felt the weakest elements of the library have been the handling of local times and i/o. It took a long time for me to see 'the light' on i/o. The first implementations of streaming facets were just too clunky and were too hard for users to use and extend. And the bottom line is that every project/person/standard has their own format for date-time i/o -- it's impossible to standardize what users want here. Luckily last summer Martin Andrian showed me the light with a partial implementation of a 'format string' based i/o facet (basically you can write: date_facet->format("%Y-%b-%d") to reset the format of a date in a stream). This approach solved a long standing issue on my standardization todo list --> how does i/o fit in with the existing format string concepts in the standard lib. Not to mention that it is almost infinately flexible in terms of how the various types can be streamed. This code will be the standard i/o facet in the 1.33 release. The local time issue turned out to be non-trivial. Early versions of the library had some under-powered attempts at solving this problem. 1.33 will contain an industrial strength solution. This includes an abstract timezone type and a couple implementations so that arbitrary timezones to be constructed from posix_strings or by using regional data via a variation of the tz generated from the 'timezone database' (a csv file the maps regions to zone rules). This, of course, includes all the gnarly daylight savings time rules. (At the end of the email I've included the code for my original challenge from 2002 to write a program that calculates the local departure / arrival times of a flight that crosses several timezones and 'flys thru' the daylight savings transition). So as 1.33 gets ready to ship I feel I'm now in a position to really work on drafting a proposal for the committee. I've written an initial outline and some text, but date-time is a non-trivial topic I have some tricky issues to explain. Best case scenario is the fall meeting -- worst case is...well I won't predict anymore ;-) Jeff //don't try this in JAVA -- it will hurt! //setup some timezones for creating and adjusting times typedef boost::shared_ptr<time_zone_base> zone_ptr; tz_database tz_db; tz_db.load_from_file("date_time_zonespec.csv"); zone_ptr nyc_tz = tz_db.time_zone_from_region("America/New_York"); zone_ptr phx_tz(new posix_time_zone("MST-07:00:00")); //local departure time in phoenix is 11 pm on april 2 2005 //ny changes to dst on apr 3 at 2 am -- luckily you don't need to //know that unless you want to be sure the answer below is correct local_date_time phx_departure(date(2005, Apr, 2), hours(23), phx_tz, local_date_time::NOT_DATE_TIME_ON_ERROR); time_duration flight_length = hours(4) + minutes(30); local_date_time phx_arrival = phx_departure + flight_length; local_date_time nyc_arrival = phx_arrival.local_time_in(nyc_tz); std::cout << "departure phx time: " << phx_departure << std::endl; std::cout << "arrival phx time: " << phx_arrival << std::endl; std::cout << "arrival nyc time: " << nyc_arrival << std::endl; Output: departure phx time: 2005-Apr-02 23:00:00 MST arrival phx time: 2005-Apr-03 03:30:00 MST arrival nyc time: 2005-Apr-03 06:30:00 EDT
Jeff, do you mind if I throw a wildcard in here? Why not drop facets altogether and use a stream format manipulator instead: std::cout << set_date_format("%Y-%b-%d") << mydate << std::endl; The format would be stored in the iostreams iword/pword (that's what they're for). You could still have a facet if you really wanted uses to change the *algorithm* used for io, but I guess what I'm trying to say is that: algorithms go in facets. configuration data goes in the iostream object itself. Just my 2c worth, Hope this doesn't cloud things up to much! John.
On Sat, 23 Apr 2005 10:43:17 +0100, John Maddock wrote
Not at all...
Sure, that would be easy enough to add now, but...
I think there are some other considerations here with date-time. What if you want to replace the short or long strings associated with a month output? Or I want the 'days of the week' be 'day1', 'day2', instead of 'Sun', 'Mon', etc. For these cases I think the strings need to get associated with a facet instead of a fleeting i/o manipulator. So for example //let's change all the short month names to have stars around them const char* const month_short_names[]={"*jan*","*feb*","*mar*", "*apr*","*may*","*jun*", "*jul*","*aug*","*sep*", "*oct*","*nov*","*dec*"}; std::vector<std::basic_string<char> > short_month_names; int main() { using namespace boost::gregorian; std::copy(&month_short_names[0], &month_short_names[12], std::back_inserter(short_month_names)); date_facet* datefacet = new date_facet("%Y %b"); datefacet->short_month_names(short_month_names); std::cout.imbue(std::locale(std::locale::classic(), datefacet)); date d(2005,Apr, 20); std::cout << d << std::endl; //2005 *apr*
Just my 2c worth,
Hope this doesn't cloud things up to much!
No, not at all. I'm sure there will be some tweaking and optimizations of the i/o concepts... Jeff
Jeff Garland wrote:
You are right. However there are legitimate cases where I might want both. That is, override the locale-specific month names using a facet _and_ choose a strftime-style date format independently. So I think that you need both a facet (for storing locale-dependent information for %a, %A, %b, %B, %c, %p, %r, %x, %X, and the other locale-dependent specifiers) and a manipulator for the format string.
On Sat, 23 Apr 2005 20:40:05 +0300, Peter Dimov wrote
Yep -- each element is individually replaceable. So you can change your date format, month strings, day of the week strings, period formatting, etc a piece at a time. To reset the format you just call 'format' with the new string. Jeff
I think I may have to disagree with John's premise:
algorithms go in facets. configuration data goes in the iostream object itself.
It is easy enough to store data in a facet. Perhaps even easier than into iword/pword. And you can use manipulators to store into the facet, or even create them: #include <iostream> #include <locale> struct my_facet : public std::locale::facet { explicit my_facet(const std::string s) : data_(s) {} std::string data_; static std::locale::id id; }; std::locale::id my_facet::id; struct my_manip { explicit my_manip(const std::string& s) : data_(s) {} std::string data_; }; std::ostream& operator<< (std::ostream& os, const my_manip& m) { os.imbue(std::locale(os.getloc(), new my_facet(m.data_))); return os; } struct A { }; std::ostream& operator<< (std::ostream& os, const A&) { const my_facet& mf = std::use_facet<my_facet>(os.getloc()); return os << mf.data_; } int main() { A a1, a2; std::cout << my_manip("some data"); std::cout << a1 << '\n'; std::cout << a2 << '\n'; } It seems to me you can have both facets and manipulators, and have them all work seamlessly together (unless I'm missing something, which is of course completely possible). The manipulator can check if a facet exists, and if it does read data from it, and at any rate either replace the existing data or create a whole new facet. I'm not a big fan of the whole locale/facet thing. But for this purpose it works a whole lot better for storing data than the pword/iword thing, unless all you really need to store is a non-heap pointer or an int. -Howard PS: Look Ma, no blimey virtual functions in my facet. Just data!
Why not drop facets altogether and use a stream format manipulator instead:
std::cout << set_date_format("%Y-%b-%d") << mydate << std::endl;
The problem with manipulators is that you need access to the stream. How do you use manipulators with lexical cast and program options?
I'd say that the date format is a localization thing and as such belong in a facet. The standard is consistant on keeping localization things in facets However, the standard is broken when it comes to date and time issues which makes it difficult. Normally format specifiers are in one facet (num_punct, money_punct) while the actual formatting/parsing occurs in another (num_put/get, money_put/get). For date_time there is no time_punct facet (anyone know why?). The standard only says that time_put formats the date as specifed in a strftime format string. It says nothing about where this string should come from. Maybe the intention was to allow the date format as a modifier but I doubt it since it makes it impossible to implement time_get correctly (how do you parse '%x').
On Sat, 23 Apr 2005 16:00:07 +0000 (UTC), Martin wrote
Good point -- although last I checked you don't have access to the stream for lexical cast either so I'm not sure this helps :-(
Interesting point. My take on the standard time facet stuff is that it was a simple solution just built the C standard. It didn't really attempt to extend the state of the art much...
Well the input half of the current standard is certainly problematic. While you can specify an output format for time_put you can't do that for time_get. So you can't do round trip i/o using the facet (well ok, you can build a parser on top of the facet functions, but it's obviously non-semmetric). There's also no easy way other than creating a locale to replace the strings used for parsing. The new Boost date-time allows the user to control all the strings and allows for semetric i/o based on the format strings. Of course Boost date-time has other considerations not addressed by the current standard like output of period and duration types, output of the generator classes, and handling of special values (not-a-date-time, infinities, etc). I've also tried to abstract a few of the common formats like iso so you can do common formats without having to know the actual format strings (date_facet->set_iso_format()). Jeff //an input example: const char* const month_short_names[]={"*jan*","*feb*","*mar*", "*apr*","*may*","*jun*", "*jul*","*aug*","*sep*", "*oct*","*nov*","*dec*"}; std::vector<std::basic_string<char> > short_month_names; int main() { using namespace boost::gregorian; std::copy(&month_short_names[0], &month_short_names[12], std::back_inserter(short_month_names)); //and now for a real trick std::istringstream ss("2005 *apr* 01"); date_input_facet* dif = new date_input_facet("%Y %b %d"); ss.imbue(std::locale(std::locale::classic(), dif)); dif->short_month_names(short_month_names); date fools; ss >> fools; }
Both lexical cast and program options uses the global locale. In theory you can change the date format for these by altering the global locale. (In practice you don't want to do that in a multithreaded application). I have asked for program_options to have an imbue method and lexical_cast to take a locale argument but the authors didn't like the idea (which is sad because it means I can't use these libraries in my applications).
Well the input half of the current standard is certainly problematic. While you can specify an output format for time_put you can't do that for time_get.
time_get contain the functions to parse the "tricky" format elements (e.g. "% x" and weekday etc) but since there are no time_punct facet you can't control the behaviour of these functions without replacing the facet.
Take a look at the libstd++ implementation of the facets. libstd++ adds a non- standard __time_punct facet which among other things contains the "real" format string for "%x", date and time separator etc. This means that formatting and parsing always uses the same format (it is ofcourse still possible to create formats that can't be parsed correctly). Dinkumware choosed another way. They are just passing "%x" to strftime so they have no idea what the local format looks like. This means that parsing is done "blindly" and doesn't work very well (e.g. my locale uses '-' as date separator which isn't support by dinkumware's time_get).
yes, that is what the standard time_punct facet should have had from start. If you want boost.date_time in the standard I think you should: 1. Move all format strings into a time_punct facet 2. Update the specification of time_put and time_get to use the time_punct facet. 3. Add functions to time_put and time_get facets to handle durations, ranges etc. (for a non-standard boost.date_time keep the current implementation, otherwise the user need to add 3 facets to the locale)
"Peter Dimov" <pdimov@mmltd.net> wrote in message news:015b01c54770$b599c530$6501a8c0@pdimov2...
Yep, sort of an odd case. Because it is a new component, TR2 would seem the logical choice. But with three independent implementations (Boost, Dinkumware, and Metrowerks), existing practice is already considerable and many LWG members are already familiar with Boost.Threads. The Evolution Working Group is apparently also interested in pushing forward with threads for C++0x. Hans Boehm and others are working on core language changes to legitimize C++ threading and other forms of concurrent programming. --Beman
"Beman Dawes" <bdawes@acm.org> wrote in message news:d4bkh6$6ht$1@sea.gmane.org... | | "Peter Dimov" <pdimov@mmltd.net> wrote in message | news:015b01c54770$b599c530$6501a8c0@pdimov2... | > Beman Dawes wrote: | >> The C++ standards committee's Library Working Group has proposed a | >> schedule for library changes and extensions: | >> | >> * October 2005: cutoff date for C++0x major library proposals | >> * October 2006: cutoff date for library TR2 proposals | >> * April 2007: cutoff date for C++0x library clean-up papers | >> | >> The usual rule-of-thumb is that new library components go in TR2, | >> while changes to existing components go in C++0x. The LWG will | >> consider exceptions to the rule on a case-by-case basis. | > | > A threading library is an interesting specimen. Is it a C++0x or a TR2 | > thing? Given that the cutoff dates are a whole year apart... | | Yep, sort of an odd case. Because it is a new component, TR2 would seem the | logical choice. But with three independent implementations (Boost, | Dinkumware, and Metrowerks), existing practice is already considerable and | many LWG members are already familiar with Boost.Threads. The Evolution | Working Group is apparently also interested in pushing forward with threads | for C++0x. Hans Boehm and others are working on core language changes to | legitimize C++ threading and other forms of concurrent programming. Some people in the EWG were working on threads. I belive Lawrence Crowl was heading the group; I told to contact Kevlin Henney to let him make the proposal; So I don't think we need to worry about this in boost. -Thorsten
Beman Dawes wrote:
What other forms of concurrent programming? I also wonder how work on accepting libraries can be done before or concurrently :o) with language changes that render them legitimate. This has been a thorny issue for the memory model group. We basically have decided to finish the memory model first. In face of other threading libraries being proposed (by the way does any of the three support lock-free programming?), we might have to obey market laws and start working on a library as well, because we have a good idea on how it would look like. Andrei
I dont know if this thread is the best place to make this question, but... Where do I find the proposals about threads in C++? libs, core language modifications, memory model and etc... ? And I've seen somewhere that there's some group discussing about those things either, but I had only access to it through a page... maybe there's somehow for others to receive those mails? Even havent permission to reply any? I'm really interested about it, but I fear things like atomicity garantees to volatile and static variables and some others too strong garantees... Thanks in advance On 4/27/05, Andrei Alexandrescu (See Website For Email) <SeeWebsiteForEmail@moderncppdesign.com> wrote:
-- Felipe Magno de Almeida UIN: 2113442 email: felipe.almeida at ic unicamp br, felipe.m.almeida at gmail com, felipe at synergy com I am a C, modern C++, MFC, ODBC, Windows Services, MAPI developer from synergy, and Computer Science student from State University of Campinas(UNICAMP). To know more about: Unicamp: http://www.ic.unicamp.br Synergy: http://www.synergy.com.br current work: http://www.mintercept.com "There is no dark side of the moon really. Matter of fact it's all dark."
On 4/27/05, Felipe Magno de Almeida <felipe.m.almeida@gmail.com> wrote:
The latest thinking seems to be not to change anything that would incur overhead as per the latest mailing: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1777.pdf This is in keeping with the seemingly fundamental c++ principle of not paying for what you don't use. <quote> The consensus within our group (grudgingly for some of us) is that it would be preferable to leave the semantics of data races undefined, mostly because it is much more consistent with the current C++ specification, practice, and especially implementations. In the absence of objections from the committee, we plan to follow that path. </quote> Though I find much of the paper of interest the useful portable implementation of such is such a long way away that boost cover much of this territory via libs. For some architectures such a library approach may not be possible. For example, I'm not sure you can do a load_store barrier by library on ia64 when I look at the JSR133 docs. This seems to be the only example of popular architecture where a library approach may not be possible. In the meantime so things such as statics in functions should perhaps just be declared as concurrently unsafe and avoided. I think boost should do a few things: 1) memory model Acknowledge there is none. Therefore must assume a data race. Have a practical portable memory barrier available: Have a load_load, load_store, store_store, store_load primitive set of functions for memory barriers modelled after the JSR 133 cook book guidelines: http://gee.cs.oswego.edu/dl/jmm/cookbook.html This should also introduce platform labels for architectures in boost in addition to the current compiler / OS #defines. I think we need to assume that lock/unlock synchronisation of a non-null mutex is a full barrier. Is that correct? Perhaps having such primitives queriable by trait is enough... 2) atomic read writes There should a type trait for a type that returns if the type is sufficiently small for atomic reading or writing to memory for the given architecture being compiled for. This type trait may be used for generic or macro methods of introducing or, perhaps more importantly, avoiding synchronisation. I use such a technique in some of my code successfully. Especially useful for helping with synch-safe property style interfaces. 3) assuring real memory Not just a promotion to register. This is required so that when a memory barrier is invoked it is acting on the necessary parts of the code we expect it to and the variable we are interested in sharing is actually shareable and not aggressively optimized into a cpu specific feature. Is volatile a practical way to do this (perhaps in co-operation with compiler optimization settings)? Can we assume "volatile" assures this and the var will not be a register only optimisation. Is there a better way. I think this is the only guarantee we need from volatile. Atomicity of reads and writes might be nice for volatile, but this is out of scope of a library. 4) further synch primitives a synch lib that provides the usual suspects of atomic ops such as inc, dec, add, sub, cas. These are normally defined for an architecture on a certain width of bit field. Thus a trait mechanism should indicate native support for a type. Perhaps a trait mechanism for what type of memory barrier equivalent guarantees have been provided by the operation. Perhaps generic implementations that, at worst, use a full mutex, for wider types. 5) better generic synchronization api for mutex operations Should be able to use null_synch, simple_synch and shared_synch ( or rw_synch ) primitives in a policy like manner so that we can write concurrent aware constructs to a shared/exclusive model and have that work for no concurrency, exclusive concurrency and shared/exclusive concurrency by policy. ACE has had something similar for over ten years. I use a simple type translation layer over boost::thread to achieve a similar outcome. 6) threading api Then we can worry more about an appropriate threading api and the religion of cancelling threads, OS specific operations, propagation of exceptions, and the like. 7) cost model It would be nice to include traits with approximate relative costs for architectures for some operations as these can be vastly different. Many ops on many architectures might be zero cost. For example the stronger memory model of x86 gives you a NOP, zero cost, for load_store and store_store barriers. This will become increasingly important in developing, so called, lock free methods. I call them "so called" as they usually require memory model guarantees through barriers or atomic ops, such as CAS, and these can be very expensive on some architectures. Lock free algorithms are often more complicated and if the non-locking concurrency costs are sufficiently high the benefits can quickly dissipate. For example, locking operations on an intel P4 are expensive. On an Athlon and ia64 they are considerably cheaper by more than a factor of two. This, and varying barrier, synch primitive costs, changes the appropriateness of an algorithm for an architecture but I can imagine fairly simple compile time formulae for determining 80% of class / algorithm selection problems transparently to a user. $0.02, matt matthurd@acm.org
On 4/27/05, Matt Hurd <matt.hurd@gmail.com> wrote:
On 4/27/05, Felipe Magno de Almeida <felipe.m.almeida@gmail.com> wrote:
<snip>
<snip explanation of what is going on>
$0.02,
Thank you, a lot more than two cents, I was still googling for information on this topic at this right moment, thank you very much.
-- Felipe Magno de Almeida UIN: 2113442 email: felipe.almeida at ic unicamp br, felipe.m.almeida at gmail com, felipe at synergy com I am a C, modern C++, MFC, ODBC, Windows Services, MAPI developer from synergy, and Computer Science student from State University of Campinas(UNICAMP). To know more about: Unicamp: http://www.ic.unicamp.br Synergy: http://www.synergy.com.br current work: http://www.mintercept.com "There is no dark side of the moon really. Matter of fact it's all dark."
Matt Hurd wrote:
Have a load_load, load_store, store_store, store_load primitive set of functions for memory barriers [...]
The "unidirectional label" model proposed by Alexander Terekhov is better.
I think we need to assume that lock/unlock synchronisation of a non-null mutex is a full barrier. Is that correct?
No, lock+unlock is not a full barrier, although it imposes ordering with respect to another lock+unlock on the same mutex.
The canonical definition of "lock free" is that the system as a whole always makes progress. An ordinary lock-based algorithm does not have this property; if the thread that obtained the lock suddenly dies, no other thread can move past that lock.
Not sure what that is. I'll google it up.
OK. Lock / unlock is a full barrier on ia32, but I see it isn't on many other arch.
Thanks for clearing up the definition. Though I do find it confusing as I've seen people call stuff lock-free where the approach uses versioning and retry semantics based on an optimistic concurrency approach. Matt.
Matt Hurd wrote: [...]
The "unidirectional label" model proposed by Alexander Terekhov is better.
Not sure what that is. I'll google it up.
http://tinyurl.com/aj9xa http://tinyurl.com/72ukl regards, alexander.
Thanks Alexander. Your level of comprehension is way beyond mine. Especially after the dizziness of following your links :-) I think there is a place for your detailed approach, however I do think the majority of users are simple folk like myself and straightforward load/store/full fences will be the appropriate level of optimization at the step after needing more performance than regular locking. I'd imagine a taxonomy of sophistication something like... single threaded -> concurrency via frameworks and patterns -> using just mutexes and locks directly -> using barriers appropriately -> going down the rabbit hole into dd,cc,hoist,acq,rel land with Alex... ;-) That said, for naive users do you have an opinion on the memory semantics locking and unlocking a mutex should provide to deliver "the least surprise" to a user. x86 and sparc deliver a full fence for these AFAIK but I worry that memory visibility could cause seemingly safe mutex protected code to trip up on weaker memory models due to memory visibility surprises from point of view of those from the great unwashed x86 land (like me). I'm thinking that a PBD could provide full fence (or perhaps just a store fence is appropriate on releasing a lock to deliver least surprise) semantics by default that may be overridden by explicit policy by an aware user. Your thoughts on memory vis requirements for locking and unlocking mutexes for the least surprise? matt.
Matt Hurd wrote: [...]
Solaris (including x86-incarnation AFAIK) have locks that don't need interlocked read-{modify-}write in unlock() (similar to spinlocks). On x86, such unlock() has pure release semantics, not fully-fenced silliness. [...]
Uhmm, how about <http://tinyurl.com/77hvz>? regards, alexander.
On 4/29/05, Alexander Terekhov <terekhov@web.de> wrote:
As a short term solution (several years??), until C++0x saves us, I think a store fence or release semantics requirement for an unlock() on a mutex will provide for the least surprise for the majority of cases. Being able to override this behaviour by policy with something more sophisticated, such as behaviour from your msync primitives provides the finer control for more sophisticated users. Given default release behaviour on unlock(), is there any need to require the overhead of an acquire for a lock() for the typical use of a mutex(). I'm tempted to say why not as it seems to be the norm for most architectures anyway, but it doesn't seem necessary from the typical case if the unlock is the equivalent of a store fence/release... For the special cases, naive users can break down to a boost::fence::xxx and sophisticated users can try a msync op... This would get us to the place where chunky memory visibility ops are available to boost and lock / unlock have defined visibility semantics (or the appropriate lack thereof ;-)). Adding traits for atomicity of reads and writes of particular contiguous sizes and providing basic atomic ops with generic mutex emulations for missing ops and extended sizes with a primitive cycle cost model for the arch would provide the necessary tools for a user of my limited desires. Further sophistication would require something more akin to Terekhov msync and friends. It doesn't solve compiler oriented issues such as optimizers relocating code beyond barriers but that is outside the realm of what a lib can do and will have to stay in its current realm of optimization / test / debug / fool compiler trickery. Does that seem reasonable without courting too much disaster? Perhaps it is a waste of time as the user group may be too small. Users like me, moderate concurrency users that want some memory visibility guarantees and control, but are not at the level of sophistication of a Dimov or Terekhov, might just be too few in number to matter. I dunno. Matt.
"Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail@moderncppdesign.com> writes:
What other forms of concurrent programming?
I don't know what Beman was referring to, but process-based concurrency and distributed concurrency are not usually considered "threading."
I also wonder how work on accepting libraries can be done before or concurrently :o) with language changes that render them legitimate.
You make some educated guesses rather than waiting for all the details to settle. I don't think the major elements of the new memory model are still in doubt.
I think it would be dangerous to do otherwise. There simply isn't enough time. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"Beman Dawes" <bdawes@acm.org> wrote in message news:6.0.3.0.2.20050422110501.042b2a20@mailhost.esva.net... | So far there are plans to propose Boost.Threads, Boost.Filesystem, and | Boost.Signals. As well as proposals for some of the more major libraries, I | personally hope someone will do a sweep through Boost looking at some of | the smaller utilities and helpers for a possible "Small Additions" | proposal. I believe Alisdair was considering to work on boost.format. Besides, boost.date_time I think these other libs are good candidates (maybe with slight modifications): 1. conversion 2. optional 3. string algorithms 4. utility 5. variant 6. iostreams I will submit do boost.range together with Walter Brown. -Thorsten
On Sat, 23 Apr 2005 23:32:22 +0200, Thorsten Ottosen wrote
Agree on these.
5. variant
Is variant used widely enough to spend the time to standardize?
6. iostreams
Agree on this too. Should we be considering some of the new collection types: circular_buffer, mutli_array, multi_index, ptr_containers? Or are the uses too esoteric for standarization? What about serialization -- it's a big library, but really important. In the "yet-to-be-developed would use it on almost every major project wish list" (alternatively called the "we should use Java because C++ doesn't have these libs wishlist") --> relational database access --> logging I realize we've had a bunch of discussion here, but i wonder if someone should consider submitting log4cxx from apache http://logging.apache.org/log4cxx/. No reason why boost has to the the source of all the good libs ;-) --> number types (unlimited / fixed point) --> process management I realize all this would be a stretch, but I was just reading Bjarne's CUJ musings about how the LWG should be aggressive in standarizing libraries... Jeff
Jeff Garland wrote:
I heavily agree on this last remark. Mr. Ramey has done a fantastic job with serialization, even with some really broken compilers, and it works very well with largely conforming C++ compilers. C++ really needs a standard serialization library, especially because IMO serialization is an absolute necessity of C++ RAD programming environments, and I hope to see many more C++ IDE's supporting RAD programming in the future once all the pieces are in place for doing it purely with standard C++.
Edward Diener <eddielee@tropicsoft.com> writes:
No argument from me, except that how a library does with broken compilers has zero bearing on its standardizability. For the standard, you wouldn't want to make any design compromises to accomodate nonconforming implementations. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Edward Diener wrote:
I heavily agree on this last remark. Mr. Ramey has done a fantastic job with serialization, even with some really broken compilers, and it works
Boost.Serialization uses XML for reading and writing (besides other formats). If it's going into C++ standard (no matter if C++ 0x or TR2) then both should really go separatelym, then make serialization partly depend on XML. I mean, there is really no need to "force" someone who needs only XML to bother with whole serialization thing. Even simple XML support in the C++ standard library would be a good thing. And this obviously will require unicode encoding (like UTF-8) support in the standard. B.
"Jeff Garland" <jeff@crystalclearsoftware.com> wrote in message news:20050423224553.M84538@crystalclearsoftware.com... | On Sat, 23 Apr 2005 23:32:22 +0200, Thorsten Ottosen wrote | > 5. variant | | Is variant used widely enough to spend the time to standardize? maybe not. | > 6. iostreams | | Agree on this too. | | Should we be considering some of the new collection types: circular_buffer, | mutli_array, multi_index, ptr_containers? I asked abuot ptr_containers and the answer was "not yet". | Or are the uses too esoteric for | standarization? probably. I wouldn't write any proposal before hearing what the committee thinks; In Lillehammer we rejected a policy-based smart pointer and it should never have gotten that far; I mean, David H. spent a lot of time writing the proposal and that time could have been saved. | What about serialization -- it's a big library, but really | important. people are working on a proposal about reflection for C++0x which would give automatic serialization; so we'd better wait with this. | --> number types (unlimited / fixed point) unlimited types where also rejected on the grouns it serves too few people compared to how hard it is to implement. -Thorsten
On Sun, 24 Apr 2005 18:43:31 +0200, Thorsten Ottosen wrote
Hmm, not sure what to make of that. I guess one of the interesting questions moving forward is 'when being in boost is enough'. Practically speaking it's clear that some things in boost will probably never make it into the standard, but it doesn't matter that much because they are available for all. Boost.graph appears to be in that category -- widely used, but probably doesn't need to be in the standard. For example, maybe there's no real advantage in trying to get standardized xml processing capabilities -- it's too big and there plenty of them out there for free. So the market is already saturated and adding the stamp of the standard isn't helpful.
That's too bad. I really hope this doesn't mean that David is going to stop working on the library....
I doubt this. What would the format of the serialization take - xml, ascii, binary? There is no doubt that reflection could simplify the the implementation of serialization for many common cases, but a library extension is clearly needed because the application needs control of the output format as well as the serialization details on a class by class basise. There are nasty problems like when I don't want to actually serialize all the data members of something -- a pure reflection solution can't easily cover these cases.
What a shame. Anyone that wants to do any kind of financial numerics is basically out of luck with C++ due to a lack of these types. Every scripting language (and JAVA of course) has these types -- someone must find them useful. It's these sort of deficiencies that get C++ rejected as an application development langauage. And actually I thought Beman had indicated earlier that there is a proposal for some new numeric types based on IEEE work? Jeff
"Bronek Kozicki" <brok@rubikon.pl> wrote in message news:426BF209.6010804@rubikon.pl...
There's a small champaign to get people to refer to this proposal as "decimal types", since they include decimal floating point, fixed point, and integers. People sometimes fixate on the floating point aspects, but the others are important too. --Beman
This is important point. Thanks for correction. B. -- Bronek Kozicki brok@rubikon.pl http://b.kozicki.pl/
"Jeff Garland" <jeff@crystalclearsoftware.com> wrote in message news:20050424184116.M16781@crystalclearsoftware.com... | On Sun, 24 Apr 2005 18:43:31 +0200, Thorsten Ottosen wrote | > | Agree on this too. | > | | > | Should we be considering some of the new collection types: | > circular_buffer, | mutli_array, multi_index, ptr_containers? | > | > I asked abuot ptr_containers and the answer was "not yet". | | Hmm, not sure what to make of that. I guess one of the interesting questions | moving forward is 'when being in boost is enough'. Practically speaking it's | clear that some things in boost will probably never make it into the standard, | but it doesn't matter that much because they are available for all. | Boost.graph appears to be in that category -- widely used, but probably | doesn't need to be in the standard. For example, maybe there's no real | advantage in trying to get standardized xml processing capabilities -- it's | too big and there plenty of them out there for free. So the market is already | saturated and adding the stamp of the standard isn't helpful. Well, I think it is a good thing that the committee is acting more focused so that its time is spend on libraries that can benefit as many users as possible. | > | Or are the uses too esoteric for | > | standarization? | > | > probably. I wouldn't write any proposal before hearing what the | > committee thinks; In Lillehammer we rejected a policy-based smart | > pointer and it should never have gotten that far; I mean, David H. | > spent a lot of time writing the proposal and that time could have | > been saved. | | That's too bad. I really hope this doesn't mean that David is going to stop | working on the library.... I hope that too; the thing is that getting it into boost is also an important goal; we simply can't put everything in the standard. -Thorsten
Thorsten Ottosen wrote:
Having a reflection facility in C++ does not obviate the need for a serialization library. Furthermore since the reflection work is closed to those outside of the committee, AFAICS, it may be too late to have a serialization library by the time the reflection work is complete. So I still think having a serialization library, which may need to be retrofitted once the C++ reflection work is done and published to the outside world, is still important. Of course as far as Boost serialization is concerned that is up to Mr. Ramey. I will be sorely disappointed if C++ does not have serialization in the next C++ standard, but perhaps the C++ committee is working on that also.
Edward Diener <eddielee@tropicsoft.com> writes:
What can you see that indicates the work is closed to those outside the committee?
You can pretty much tell what the committee is working on by looking at the contents of the publicly available mailings. There haven't been any serialization papers in any mailings I've seen. If you want to avoid disappointment, I suggest you write and submit a proposal. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
1) I asked Gabriel Dos Reis to participate in the work on reflection and was told that my input was not needed, but if they needed someone to test things out, I could volunteer. In effect I was told to get lost, evidently because I was not a member of the committee or was not considered smart enough or important enough to contribute. 2) Where is the information regarding reflection and the work being done on it published ? If it is not closed to those outside the committee, then the ongoing work on it should be accessible to others, and others should be able to comment on it and contribute to it.
I was promoting the idea that the Boost Serialization library be submitted. If the Boost serialization library is not submitted, and the C++ committee is not intending to have a serialization library, I think it will be a big mistake but I have no serialization library of my own to submit as I think the Boost one is better than anything I could do and better than anything else I have ever seen using standard C++. I will be glad to work with Mr. Ramey on the writing up a proposal part, since I am a fairly good writer, but it is obviously up to him and not me whether he wants to propose the library to the committee. In favor of serialization I will say that all RAD programming environments I have ever seen must do some form of serialization in order to store and load property and event values. Outside of that, serializing data so that it can be transported across heterogenous environments is a fundamental concept of distributed object programming. It would be a great advantage for C++ to have a mechanism of its own for doing this rather than having to adjust itself to fit into other environments, each with their own pecularities and limitations.
On 4/26/05, Edward Diener <eddielee@tropicsoft.com> wrote:
I agree with you that the boost serialization library would be a very good addition to the Standard. I find myself using it all the time... I haven't seen any serialization library with half the qualities of the boost serialization library.
-- Felipe Magno de Almeida UIN: 2113442 email: felipe.almeida at ic unicamp br, felipe.m.almeida at gmail com, felipe at synergy com I am a C, modern C++, MFC, ODBC, Windows Services, MAPI developer from synergy, and Computer Science student from State University of Campinas(UNICAMP). To know more about: Unicamp: http://www.ic.unicamp.br Synergy: http://www.synergy.com.br current work: http://www.mintercept.com "There is no dark side of the moon really. Matter of fact it's all dark."
Edward Diener <eddielee@tropicsoft.com> writes:
I wouldn't draw too many conclusions from what Gaby says. He's just one guy with a not-always-smooth email demeanor. Never forget that the committee is made up of individuals, and that people working on proposals are not necessarily tied to the committee in any particular way. I would also not conclude from this that Gaby would welcome your help if you were a committee member. In other words, "closed to those outside the committee" is probably not the right conclusion. Those working on the reflection project may still not be interested in your input for whatever reasons, of course, but you might try knocking on a few other doors.
2) Where is the information regarding reflection and the work being done on it published ?
I don't think any information is being published. This is not a "committee project," at least not yet. This is some people working on a project that they *may* eventually bring to the committee in the form of a proposal, if they ever finish it ;-)
Not neccessarily. Who the people on that project decide to accept contributions from is really up to them.
My suggestion applies perfectly. Why don't you propose it?
Pete Becker proposed, essentially, the Boost.Threads design. It doesn't have to be "your own."
Not really. If you really want this to happen, *you* should commit yourself to proposing it, and then invite Mr. Ramey to join you. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
I disagree on this. It is clearly wrong, in my eyes, to propose any library to the C++ standard committee when that library is someone else's work. I greatly respect Mr. Ramey for the work he has done and is doing to make the Boost serialization library as good as it is but I would never want to propose such a library for inclusion as a standard library unless the creator of the library wanted to promote it also. It is also unfair to put that creator in such a position of extra work which standardizing a library might entail.
<snip entire quoted thread> Please limit the amount of quoted text in your postings. Edward Diener <eddielee@tropicsoft.com> writes:
Why do you think so?
If that's the only reason, it's easily dealt with. The creator of the library isn't obliged to do anything to enable standardization. It can be your effort entirely. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Let me try to understand this. Are you saying that you ( the proverbial 'you', not the personal 'you' ) would take a library that someone else had developed, even if it is admittedly in the public domain, and propose it as a standard library to the C++ committee, making whatever changes might be necessary to get it accepted ? I am asking this quite seriously and not facetiously because for my own Regular Expression Component Library I took an earlier version of Boost regex++, made some small additions and changes to it, and incorporated into my own non-templated library interface which I have made available freely. I felt justified in doing this not only because Boost tells me this is legally OK but also because John Maddock generally understood what I was doing, and was helpful to me. But I would never have thought that it was right proposing my own slightly altered version of just the regex++ part of it to the C++ standards committee if John Maddock hadn't proposed regex+++ himself ( and of course a much improved regex++ than what I had used ). It still seems clear to me that if a public domain library developer wanted to have his library accepted as part of the C++ standard, that is his prerogative, not someone else's, and that attitude is a personal one not a legal one. I also can anticipate problems having someone else propose the library, and I am not talking about anything having to do with the effort of understanding internally how the library works. The biggest problem centers around changes that might have to be made in the library to satisfy the C++ standards committee. Once those changes are made there are now two stewards to the library and two slightly different versions of that library. I do not think this is a good situation. One now gets into arguments about what is better, which direction new decisions and designs should take, and the rest of that rigamarole which means difficulties and arguments to no good end. In the current Boost model, a single developer creates a library and others are free to chime in with suggestions, discussion, and even bug fixes, but it is still the resposnibility of that developer to be the author of that library. I like that model and only in vary rare situations, like with you and Aleksey with MPL, is that model different. For these general reasons I see it as a distinct disadvantage for having someone propose a library which they themselves have not developed. If Mr. Ramey were to say to me, go ahead and propose the library to the C++ standards committee, it is your call to learn the library and make whatever changes might be necessary to have it accepted, I would do it. But I do not know him and he does not know me and I would not want to put him under any pressure regarding this. I still feel very strongly that serialization should be part of the C++ standard so that instead of having every C++ implementation invent their own individual methods of serializing data to and from some persistent store, as many RAD and semi-RAD environments now do, there would be one standard way of doing things in this area. Needless to say a standard C++ library for serialization would also admirably serve the purposes of data transport between systems where the language is C++ on both ends.
Edward Diener <eddielee@tropicsoft.com> writes:
Let me try to understand this. Are you saying that you ( the proverbial 'you', not the personal 'you' )
I don't know what you mean by the "proverbial you;" I can only answer for the "personal me."
Yep. Of course the original author would be duly credited for his or her work. I'd certainly let the author know what I was doing, and if she or he objected I would certainly try to understand the reasons for the objection, and I might think twice about proceeding.
I still don't know why it's clear to you, but perhaps it's just one of those things that has to be taken on faith.
That's good, because internals (apart from implementability) are not all that relevant to standardization.
I understand your worries, but these things usually work themselves out. I don't want to suggest that your concerns are entirely unfounded, but at the same time it's easier to worry than to begin a proposal ;-)
How is it different there?
I guess you have to decide whether those risks are worse than the risk that no serialization library would be standardized.
That's very considerate. Really. But I doubt anyone whose library has successfully been through a pair of failed/accepted Boost reviews is going to be made very uncomfortable if you ask him to let you propose his interface design for standardization.
I guess you have to decide how to balance your various considerations. Good luck! -- Dave Abrahams Boost Consulting www.boost-consulting.com
Edward Diener wrote:
I believe Robert said some time ago that he didn't think Boost.Serialization was (then) a good candidate for standardization, because it was large and could use more support from the core language. If you disagree, I don't see anything wrong with your proposing Boost.Serialization for standardization. Suppose it is accepted into a TR with some small changes. Then Robert will naturally make the corresponding changes to the Boost version, and drop the Boost version entirely when the standard version is universally available. On the other hand, if the library is accepted with major changes, then assuming the Boost version retains some advantage over the standard version, the libraries can coexist peacefully. Jonathan
"Thorsten Ottosen" <nesotto@cs.auc.dk> wrote in message news:d4gi2c$2jd$1@sea.gmane.org...
In Lillehammer we rejected a policy-based smart pointer...
That isn't what happened. The committee's wiki describes the LWG's position: "No support for a policy-based framework at this time. This is a refinement of Loki, but, while Loki is in use, this refinement isn't. We'll consider such a proposal later, if there is widespread practice and strong arguments for it." "No support ... at this time." is very different from rejection. I know I'm really looking forward to the day when a policy-based smart pointer is ready for standardization. I suspect others will feel the same way when they see the work completed. But the work isn't done yet, even though it may be pretty close to done.
unlimited types where also rejected on the grouns it serves too few people compared to how hard it is to implement.
Again, the idea of extended precision integers wasn't rejected. There was no support for the particular proposal, because "We haven't seen an analysis of use cases, so we don't know which communities this is important to, what their needs are, and whether this type meets their needs. There's also lack of implementation experience, and of precise specification of some of the operations." If there really is a need, that analysis is easy enough to do, and the other issues are also easy to resolve. The existing proposal can be updated, or perhaps someone else will come forward with a different proposal. --Beman
"Beman Dawes" <bdawes@acm.org> wrote in message news:d4k44t$9b9$1@sea.gmane.org... | | "Thorsten Ottosen" <nesotto@cs.auc.dk> wrote in message | news:d4gi2c$2jd$1@sea.gmane.org... | | > In Lillehammer we rejected a policy-based smart pointer... | | That isn't what happened. The committee's wiki describes the LWG's position: | | "No support for a policy-based framework at this time. This is a refinement | of Loki, but, while Loki is in use, this refinement isn't. We'll consider | such a proposal later, if there is widespread practice and strong arguments | for it." | | "No support ... at this time." is very different from rejection. maybe, I didn't mention why it was "rejected" but I don't see any conceptual difference; I strongly encourage people to not write a proposal before they know the committee are willing to accept it. I see it like this: we are very limited in resources in the library working group and we want to focus on libraries that can be used by as many users as possible. And that means a policy-based smart pointer is probably not going into the standard. I think the comments on the wiki underestimates the objection towards the proposal; When Andrei presented it in Seatle, he was left with the feeling that people really liked the idea; so Dave wrote the proposal only to get it "put on hold". A lot of waisted work IMO. We should be more honest about this stuff in the LWG so we don't push away people trying to help us. Ideally every proposal should be pre-approved by the comittee and at least one guy from the LWG should cooporate with the team doing a specific library to ensure it turns out to be what the LWG is looking for. I don't mind doing work for free---as long as it is not waisted; waisted work would **** me off. -Thorsten
Gennadiy Rozental wrote:
I don't agree with this statement at all. Making things more flexible incures a semantic dilution (not to speak of the added complexity necessary to support that flexibility) that encourages users to just 'roll their own' solution. I'm not saying that flexibility or genericity is bad. But it comes with a price. Regards, Stefan
Sorry . I do not get this.
(not to speak of the added complexity necessary to support that flexibility)
More flexible solution is not nesseserility more complex. It's maybe just better designed with flexibility in mind. Actually I believe that in general Policy based designs tend to lead to more simple solution, since they clearly separate independent notions and each one of them is quite easy to implement separately. It does require good original component design though.
that encourages users to just 'roll their own' solution.
Why? And having inflexible solution doesn't? Did you notice how many times in his list people comes up with threads like: lets have another smart pointer (guard, manager e.t.c.) like this ....?
I'm not saying that flexibility or genericity is bad. But it comes with a price.
What kind of price? Perforamce, usability, space?
Regards, Stefan
Gennadiy
Gennadiy Rozental wrote:
More flexible solution is not nesseserility more complex.
I agree. I'm not saying that flexibility is to be avoided. It's just something to be careful with. As you say, it requires good modeling.
End-users work in a problem domain with its own vocabulary and semantics. Libraries / frameworks such as boost have their own, and so there's already a potential for an impedance mismatch. The more a user is required to learn about aspects unrelated to his own problem domain just because the tools he wants to use are generic and applicable to a broad range of domains the larger is this gap. It's a trade-off. Regards, Stefan
Yes. To use a tool you may need first invest time to learn it. And yes it's a trade-off. But: 1. In case of plain memory management PBSP present exactly the same semantic as any existent solution. So we could expect the "ordinary" user to be familiar with it and do not require time to learn how to use it. 2. Above also imply that it shouldn't be that difficult to make one more step to learn about possibilities of configuring it's behavior. 3. Resource management tasks are quite wide-spread. So whatever time you spend getting hold of PBSP the time saving of writing specific simple policies will overcome it. So the trade-off is quite reasonable IMO. Gennadiy
"Stefan Seefeld" <seefeld@sympatico.ca> wrote in message news:426E4259.4070209@sympatico.ca... | Gennadiy Rozental wrote: | | > IMO | > the more flexible the solution is - the more users it will end up | > attracting. | | I don't agree with this statement at all. Making things more flexible | incures a semantic dilution (not to speak of the added complexity | necessary to support that flexibility) that encourages users to just | 'roll their own' solution. | | I'm not saying that flexibility or genericity is bad. But it comes | with a price. I don't think it is unfair to see it as an expert tool and not something the ordinary user need to use or worry about learning. That implies that we do want it in boost, but that it might not be a good candidate for std::. There has been a lot of discussion about a CPAN thing for C++; a place where good libraries can jsut be found. Unless someone does all the work, I don't see that happening for C++. However, Boost has a unique position and chance to become a de-facto repository for high-quality C++ libraries (CPAN don't really guarantee any quality). I imagine that will happen over the next few years as we close more and more gabs in the C++ library world. -Thorsten
"Thorsten Ottosen" <nesotto@cs.auc.dk> wrote in message news:d4lgqm$83h$1@sea.gmane.org...
I do not know how "expert" it is, but I am quite sure that ordinary user will find it very useful. How many times ordinary C++ user is faced with resource (of any kind) management tasks? My guess a lot. And in many many cases it would be more easy to write a policy for PBSP instead of writing everything from scratch. boost::smart_ptr does cover a lot of ground. But it's still incomparable (IMO) with power presented by PBSP solution.
That implies that we do want it in boost, but that it might not be a good candidate for std::.
I think that standard containers are way more "expert". But we still want them in stl, aren't we? Gennadiy
By PBSP, do you mean policy-based smart pointers in general, or a Loki-derived smart pointer in particular?
You may say in general or Loki-derived - depend on point of view. I have many objections to Loki solution (and some of it's derivatives). But what I have in mind is similar. Do you have any other alternative model? Gennadiy
Gennadiy Rozental wrote:
If you ask me for my personal opinion: I have little use for the Conversion and the Checking policies. However I do need an easier way of specifying a deleter (ala Howard's unique_ptr) and a ConstPropagation policy (with the default being No for shallow copy and Yes for deep copy). In addition, I'm not happy with the integration of shared/weak/intrusive_ptr in the current model. To be really flexible, a policy-based incarnation of a reference counted pointer needs to leave its aspects configurable, covering the whole spectrum from a simple counted_ptr to full-featured shared_ptr (with or without weak_ptr support in both cases) and possibly covering the unsafe/basic/strong thread safety axis as well. This might imply a policy controlling whether conversions from smart_ptr<T> to smart_ptr<U> are allowed (because disallowing these allows alternative implementations or omitting one pointer from the control block.) My needs may not be typical, of course.
"Peter Dimov" <pdimov@mmltd.net> wrote in message news:03d401c54a75$d3a71a20$6401a8c0@pdimov2...
Checking policy could be very convenient for implementing Debug only extra checking. Similar to STLPort debug mode. Conversion is just a matter of satisfying legacy interfaces.
I hope David is listening to this and can comment. I am a bit out of date with details of PBSP design/implementation to comment on that. Gennadiy
On Apr 26, 2005, at 11:37 AM, Peter Dimov wrote:
ConstPropagation policy (with the default being No for shallow copy and Yes for deep copy).
I've been toying with a smart pointer adaptor for this one. I really haven't fully fleshed out the thinking on it though... template <class SP> class deep_const { public: typedef SP pointer; private: pointer sp_; typedef decltype(*pointer()) reference; public: deep_const() {} deep_const(const pointer& p) : sp_(p) {} deep_const(pointer&& p) : sp_(std::move(p)) {} deep_const(const deep_const& p) : sp_(p.sp_) {} deep_const(deep_const&& p) : sp_(std::move(p.sp_)) {} deep_const& operator=(const deep_const& p) {sp_ = p.sp_; return *this;} deep_const& operator=(deep_const&& p) {sp_ = std::move(p.sp_); return *this;} reference operator*() {return *sp_;} const reference operator*() const {return *sp_;} //... }; deep_const<shared_ptr<std::string> > sp; -Howard
"Peter Dimov" <pdimov@mmltd.net> wrote in message news:093101c54aa9$6be49c80$6401a8c0@pdimov2... | Howard Hinnant wrote: | > On Apr 26, 2005, at 11:37 AM, Peter Dimov wrote: | > | >> ConstPropagation policy (with the default being No for shallow copy | >> and Yes for deep copy). | > | > I've been toying with a smart pointer adaptor for this one. I really | > haven't fully fleshed out the thinking on it though... | > | > template <class SP> | > class deep_const | | Yes, conversion and checking can be implemented as adaptors, too. | | But a really smart pointer would have the right default for const | propagation depending on the ownership policy. :-) could you explain what that default would be? (I think I know the answer; I definitely know what I think the answer should be, but I would like Howard hear you say it) -Thorsten
On Apr 26, 2005, at 5:44 PM, Peter Dimov wrote:
Would that be the prescient_ptr? :-) I've got 3 ownership policies on my mind: 1. shared 2. unique 3. cloned And if anything I'm leaning towards shallow const on all of them. However I also believe deep const versions of all of these would probably be valuable as well. And I'm especially looking at signatures like: template<class T, class U> bool operator==(const shared_ptr<T>& a, const shared_ptr<U>& b); shared_ptr today is a shallow const animal, and I think that is good. But the above signature assumes deep const. It would be nice to have a zero-overhead way to express and enforce that assumption. So would it be better to code a const-policy into them all (and whatever other smart pointers crop up)? Or would it be better to make a single adaptor (like stack is for containers), that would take any shallow const smart pointer and adapt it to a deep one? Or maybe there is a third solution that has escaped me. Or perhaps this is an academic problem and really requires no solution. I'm not claiming to know the answer to my question. I'm simply grateful I have a place to ask it. -Howard
"Peter Dimov" <pdimov@mmltd.net> wrote in message news:011801c54c25$f9f3c2d0$6401a8c0@pdimov2... | Howard Hinnant wrote: | > I've got 3 ownership policies on my mind: | > | > 1. shared | > 2. unique | > 3. cloned | > | > And if anything I'm leaning towards shallow const on all of them. | > However I also believe deep const versions of all of these would | > probably be valuable as well. And I'm especially looking at | > signatures like: | > | > template<class T, class U> | > bool operator==(const shared_ptr<T>& a, const shared_ptr<U>& b); | > | > shared_ptr today is a shallow const animal, and I think that is good. | > But the above signature assumes deep const. It would be nice to have | > a zero-overhead way to express and enforce that assumption. | | I'm not sure I understand. Why does the above assume deep const? It's just | the shared_ptr equivalent of: | | template<class T, class U> | bool operator==(T * const & a, U * const & b); it's unreasable to requrie the state of T and U to be avaiable through non-const member functions. -Thorsten
On Apr 28, 2005, at 3:10 PM, Peter Dimov wrote:
I didn't state myself clearly. I meant that the semantics of operator== on shared_ptr (regardless of the actual signature) imply that not only will the shared_ptr remain unchanged, but also what it points to. I.e. the implied semantics of operator== is: template<class T, class U> bool operator==(const T * const & a, const U * const & b); But the actual signature that we use is the one you wrote (with non-const pointee). It would be nice if we had a zero-overhead way to express deep const on the operator== signature. With shared_ptr we could: template<class T, class U> bool operator==(const shared_ptr<const T>& a, const shared_ptr<const U>& b); and I believe it would compile and work as expected, and now deep const semantics are guaranteed by the complier. However the above isn't zero-overhead (shared_ptr<T> will convert to shared_ptr<const T> for the operation), and thus is unacceptable. And the same idea flat wouldn't compile for unique_ptr. If we had a deep_const smart pointer adaptor that adapted either smart pointers, or references to smart pointers, and had a non-explicit converting constructor, then the following might work (haven't actually tried it) with zero overhead: template<class T, class U> bool operator==(const deep_const<const shared_ptr<T>&&>& a, const deep_const<const shared_ptr<U>&&>& b); But that's getting pretty darned ugly and I immediately wonder if the cure isn't worse than the disease. :-) -Howard
"Thorsten Ottosen" <nesotto@cs.auc.dk> wrote in message news:d4lgqm$83h$1@sea.gmane.org...
The plan we talked about several years ago was that if the standard library has a PBSP, there would also be classes (or similar typedef templates, depending on core language changes) like: template<class T> class shared_ptr : public smart_ptr<T, one set of policies> {...}; template<class T> class scoped_ptr : public smart_ptr<T, another set of policies> {...}; etc. These would be recommended to non-expert users. One of my personal criteria for a good PBSP is that it can supply the feature set needed to provide those pre-configured smart pointers. --Beman
"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:
Speaking as someone who has been involved in this process since 1996, IMO that's very bad advice. There's hardly any way to even get an inkling of whether the committee are willing to accept most proposals without writing and submitting them.
To all who are reading: I just want to emphasize that this is Thorsten's personal viewpoint and doesn't neccessarily reflect the opinion of others.
I think it's very wrong to imply there was any dishonesty involved, and especially in this forum where the LWG members can't respond. If you want to have this conversation you should do it on the LWG reflector.
Ideally every proposal should be pre-approved by the comittee
I'd ask what you mean by "pre-approved," but that should really be discussed on a committee reflector, not here.
The LWG and the committee aren't of one mind; it's a group of people with varied outlooks and shifting opinions. Getting an experienced committee member to champion any proposal is a smart thing to do, but it's the responsibility of the proposer, not the committee.
I don't mind doing work for free---as long as it is not waisted; waisted work would **** me off.
If you want to be sure to avoid wasted work you need to participate in the committee process and build consensus on the reflectors between meetings... and even then it is possible to fail. Dave H. didn't do that AFAICT. There's no good reason to think that Andrei's impression that "people really liked the idea" should be enough to ensure that the next proposal would be accepted. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:ufyxd8ra6.fsf@boost-consulting.com... | "Thorsten Ottosen" <nesotto@cs.auc.dk> writes: | | > "Beman Dawes" <bdawes@acm.org> wrote in message | > news:d4k44t$9b9$1@sea.gmane.org... | > | "Thorsten Ottosen" <nesotto@cs.auc.dk> wrote in message | > | news:d4gi2c$2jd$1@sea.gmane.org... | > | > In Lillehammer we rejected a policy-based smart pointer... | > | That isn't what happened. The committee's wiki describes the LWG's | > | position: | > | "No support for a policy-based framework at this time. This is a | > | refinement of Loki, but, while Loki is in use, this refinement | > | isn't. We'll consider such a proposal later, if there is widespread | > | practice and strong arguments for it." | > | "No support ... at this time." is very different from rejection. | > | > maybe, I didn't mention why it was "rejected" but I don't see any | > conceptual difference; I strongly encourage people to not write a | > proposal before they know the committee are willing to accept it. | | Speaking as someone who has been involved in this process since 1996, | IMO that's very bad advice. There's hardly any way to even get an | inkling of whether the committee are willing to accept most proposals | without writing and submitting them. Well, both me and Doug asked explicitly about our respective libraries. I got a "not yet" and he got an "ok". That's easy; no time wasted. | > I see it like this: we are very limited in resources in the library | > working group and we want to focus on libraries that can be used by | > as many users as possible. And that means a policy-based smart | > pointer is probably not going into the standard. | | To all who are reading: I just want to emphasize that this is | Thorsten's personal viewpoint and doesn't neccessarily reflect the | opinion of others. What else could "I see it like this" possibly mean? That it was your oppinion???
but how should people know if their proposal has got a chance if not by asking? -Thorsten
"Thorsten Ottosen" <nesotto@cs.auc.dk> wrote in message news:d4lpbs$ftq$1@sea.gmane.org...
It makes sense sometimes to ask if there is interest in a proposal. But no one should consider "interest" to imply any kind of commitment. It doesn't make sense to ask the LWG (let alone the committee as a whole) to pre-approve a proposal they haven't seen. They won't do it. --Beman
"Beman Dawes" <bdawes@acm.org> wrote in message news:d4mg0e$gbs$1@sea.gmane.org... | | "Thorsten Ottosen" <nesotto@cs.auc.dk> wrote in message | news:d4lpbs$ftq$1@sea.gmane.org... | > | | > | If you want to be sure to avoid wasted work you need to participate in | > | the committee process and build consensus on the reflectors between | > | meetings... and even then it is possible to fail. Dave H. didn't do | > | that AFAICT. There's no good reason to think that Andrei's impression | > | that "people really liked the idea" should be enough to ensure that | > | the next proposal would be accepted. | > | > but how should people know if their proposal has got a chance if not by | > asking? | | It makes sense sometimes to ask if there is interest in a proposal. But no | one should consider "interest" to imply any kind of commitment. | | It doesn't make sense to ask the LWG (let alone the committee as a whole) to | pre-approve a proposal they haven't seen. They won't do it. the other case is also interesting: should "no interest" imply any kind of rejection? IMO, yes. -Thorsten
"Thorsten Ottosen" <nesotto@cs.auc.dk> wrote in message news:d4mgtc$iq0$1@sea.gmane.org...
"No interest" is mild rejection, "don't like it" or "standardization not needed" is stronger rejection, while "over my dead body" is total rejection (at least by whoever said that). All are red flags that a proposal could well be a waste of time, at least until something changes. --Beman --Beman
"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:
Maybe, but getting an "OK" in a LWG straw poll doesn't amount to "knowing the committee are willing to accept" an as-yet-unwritten proposal. First of all, the LWG is not the whole committee. Secondly, the LWG that looks at the proposal the proposal may be composed of different people than the LWG that responds to a straw poll. Finally, an unwritten proposal idea that is not blatantly inappropriate is usually met with the response that the LWG needs more information in order to form an opinion. If you had said, "I encourage people to get a feel for the opinion of the LWG on an idea before writing a proposal," I'd have said that was good advice. What you wrote seems to encourage an attempt to get guaranteed acceptance before even making a mature proposal. That is likely to result in antagonism that would undermine your proposal's chances.
Nothing else, but it is very common for statements of individual committee participants to be interpreted as "the mood of the committee," despite being clear statements of personal opinion. I wanted to make sure that wouldn't happen here.
By all means, ask if your proposal has a chance -- but you cannot "_know_ the committee are willing to accept" anything until you submit it. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Tue, Apr 26, 2005 at 07:28:04PM -0400, David Abrahams wrote:
"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:
[snip]
Dave, I fully accept the spirit of your post and of Beman's preceeding posts and I think I pretty much get the gist. However, the implication ofn the above is that if I am not a member of the committee then my proposal is at a disadvantage because I can not lobby on the reflectors. Could you or Beman elaborate on the position of a boost member who is not a member of the comittee and the process that they can follow for making a proposal to the committee without being a member. Are we at a disadvantage? /ikh
"Iain K. Hanson" <ikh@hansons.demon.co.uk> wrote in message news:20050427003528.A6662@titan.hansons.demon.co.uk...
Large (and very important, technically complex) portions of TR1 came from John Maddock and Peter Dimov, who are not members of the committee and AFAIK have never attended a committee meeting. They gained the respect of the committee with their proposals, have been invited to participate on the committee's reflectors, and are often quoted by committee members as authoritative experts.
One way is to come to a meeting (and present your proposal, if it is ready). See http://www.boost.org/more/cpp_committee_meetings.html; there is a slightly updated version in CVS. If that isn't possible, it helps to find a committee member to act as your proposal's champion. There are six or eight Boosters who attend most meetings, and even more who attend occasionally. One or more of us usually acts as a champion for any proposals coming out of Boost when the proposer isn't present. Boosters who are also committee members also comment on private drafts of proposals, and that hopefully helps round off rough edges. Proposals don't have to be 100% perfect to gain the committee's attension, either, particularly version 1 proposals.
Are we at a disadvantage?
Not really. John Maddock and Peter Dimov are existance proofs of that. Any proposal coming out of Boost tends to have lots of credibility - we have such a wonderful track record that committee members sometimes have to remind themselves that good proposals can come from non-boost sources, too. Almost all committee members are supportive of Boost, even if they are not active participants. --Beman
On Tue, 2005-04-26 at 21:49 -0400, Beman Dawes wrote:
"Iain K. Hanson" <ikh@hansons.demon.co.uk> wrote in message news:20050427003528.A6662@titan.hansons.demon.co.uk...
[snip] Thanks for the information and link. I thought it might be something like that, but just wanted to make sure. /ikh _______________________________________________________________________ This email has been scanned for all known viruses by the MessageLabs Email Security System. _______________________________________________________________________
On Wed, 27 Apr 2005 00:35:28 +0000, Iain K. Hanson wrote
The committee members can confirm this, but as I recall I was told they would put me on the LWG reflector if I submitted a proposal. So my understanding is that if there is a need you are included even if you aren't a committee member. Taking your question another way, John Maddock wrote at least a couple of the accepted TR1 proposals and he isn't a committtee member -- so maybe it is an advantage ;-) Jeff
"Thorsten Ottosen" <nesotto@cs.auc.dk> wrote in message news:d4la6g$91f$1@sea.gmane.org...
The LWG is never willing to say for sure they will accept a proposal until after they have seen it. And most proposals have to be revised and resubmitted several times before acceptance. Even a slam-dunk proposal, like hoisting C99 stuff into TR1,wasn't accepted until the proposal was actually delivered. The most you can expect from the LWG is a straw vote that they are "interested" in seeing a proposal. You always have to supply the actual proposal before they will accept it. And even then, there are no sure bets. Several components (dynarray, etc.) were voted into the standard (by the full committee, not just the LWG), edited into the document, and then finally removed because the STL proposal surfaced and was deemed so superior as to make the pain of removing components worthwhile.
Few would argue with that. The argument starts when a particular proposal is seen as widely useful by some LWG members, and less useful by others.
And that means a policy-based smart pointer is probably not going into the standard.
Not into C++0x, but TR2? TR3? Remember that some of the stuff the committee is asking for as high priority now (like threads and networking) were considered "no, never" and "over my dead body" a few years ago. Committee membership changes over time, and attitudes of long-time members change, too. What users ask for changes. Proposals mature.
That remains to be seen. It is way too early to tell. If and when the library gets accepted by Boost and becomes widely used, maybe with some commercial implementations, then the LWG could fall in love with the PBSP proposal. It is very similar to shared_ptr. Remember shared_ptr (then called counted_ptr) was rejected by the full committee (although approved by the LWG) back in 1994 or 1995.
That might be the "ideal" way to do it, but the committee doesn't work that way. Nothing happens until a proposal appears in a mailing. It is all arm waving until then. An expression of interest is the best anyone can hope for.
Understood, but that's the way the cookie sometimes crumbles. An unexpected proposal can always come out of the blue which causes your proposal to be rejected. --Beman
On Mon, 2005-04-25 at 21:10 -0400, Beman Dawes wrote:
Is the requirement for a library to be in "widespread" use general for all libraries or specific to policy_ptr because the TR1 already has smart_ptr? /ikh _______________________________________________________________________ This email has been scanned for all known viruses by the MessageLabs Email Security System. _______________________________________________________________________
"Iain K. Hanson" <iain.hanson@videonetworks.com> wrote in message news:1114524401.14534.421.camel@dev-ihanson.ct.uk.videonetworks.com...
It isn't specific to shared_ptr. Every proposal is evaluated on it's own merits, but lots of LWG regulars look for "existing practice". How widespread that has to be is up to the judgement of individual members. In the case of the STL, the LWG (and full committee) were willing to accept the lack of widespread existing practice because the perceived advantages seemed so great. --Beman
Thorsten Ottosen wrote:
Although I understand "rejection" is an overstatement, I wonder how the committee deals with conflicts of interest. The ideological competitor to policy_ptr is shared_ptr, and while the former has zero backing up inside the committee, the latter is backed up by people who also get to lobby and vote. Now I'm not sure about others, but in such situation I'm biased. I mean, if I were to propose and back up X, I would naturally believe X is better than Y, Z, and even \Omega, and I won't be 100% objective. I wouldn't be unreasonable, but as soon as it would come about things that are hard to objectify, I'd assign more weight to negative arguments against the competing design (policies are complicated, not enough experience, too much choice etc.) than to arguments in favor of that design (the inclusion relationship between policy_ptr and its technical superiority that is obvious to me - but then hey, I'm biased). It's human nature. Case in point: shared_ptr fosters binary compatibility across calls to shared libraries with different allocators and all that jazz. That's an advantage, no doubt about that. But then people who proposed and back up shared_ptr assign a lot of weight to that argument, which I believe reflects their bias. Here's why. If people would really really believe this is a crucial advantage, they'd be looking at the rest of the standard and they would shriek in horror: "There's absolutely NO other component in the standard library - no string, no vector, no map, no allocator, no NOTHING that offers the same compatibility! But wait! There's even no standardization of dynamically-linked libraries!" So if they'd really be objective, they'd be into working on implementing the same stuff in containers and/or allocators like white on rice. But the truth is, nobody cares about string and vector not being passable across binary module boundaries. Now really - nobody blinks an eye. But whenever talk comes about shared_ptr, oh yes, that's essential! And that comes in conveniently with the argument that there is too much configurability ("too many notes") in policy_ptr, and therefore, what a wreck, each library will just misuse that configurability to create incompatible smart pointer stuff just for kicks. (At this point it is also very convenient to forget about things like good ole default template arguments, policy convertibility, and the upcoming type aliases.) So the question would be, how does the committee deal with conflict of interests like that? Because honest, if I were on the committee, every misplaced comma in the shared_ptr proposal would stick like a sore thumb to me, and I'd sure manage to convince others of the same. Andrei
"Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail@moderncppdesign.com> writes:
That is an extremely volatile phrase and I suggest you choose a different one. A "conflict of interest" suggests that LWG members have a personal agenda that conflicts with the best interests of the C++ community. The agendas of committee members come into play for all kinds of reasons: implementors are concerned about how much work it will be to build and test things, for example. Is that a "conflict of interest?" Consider what happened with export.
You get to lobby just like anyone. As for voting, the designer of shared_ptr doesn't show up at meetings, and you should know that I wasn't around the LWG for discussions of Dave H.'s proposal, so I exerted no influence on the reaction to it. I don't know about other Boost members who happen to be on the committee, but I consider my opinions on the designs to be fairly objective and certainly I have no kind of "personal glory" at stake in what happens with PBSPs in the standard. I hope you'll tell me I'm wrong, but it sounds like you're saying that Boost members who attend committee meetings, rather than voting based on their best judgement of the technical issues, would try to push out a PBSP design in order to somehow "win" ideologically. That would be an extreme sort of pettiness; being accused of it would be very insulting to me, at least.
Now I'm not sure about others, but in such situation I'm biased.
<snip sarcastic mockery of arguments against PBSPs> Everyone has biases, and they affect the way the process goes. You can't design that out of the process no matter what you do.
So the question would be, how does the committee deal with conflict of interests like that?
You really ought to take up question about how the committee works on a committee reflector; this is the wrong place for it. There are only a few people here who can respond and we don't represent the whole committee.
Did you get any indication that Dave H.'s proposal was nitpicked to death over things like commas? -- Dave Abrahams Boost Consulting www.boost-consulting.com
In support of Dave's response to Andrei: Every one of the individuals in the room at the time that the PBSP proposal was discussed is responsible, professional, and open-minded. One healthy component of responsibility and professionalism, in the context of a committee responsible for a very important international standard, is conservatism. Every individual member of the LWG has different criteria for evaluating proposals to TR2 or C++0x, but I think that there is silent agreement that the following are at least worth considering: 1. is it implementable? 2. has it been implemented? 3. has the implementation been tested? 4. has it been used? how widely? 5. is it sufficiently useful? 6. can it be specified rigorously for a standard? 7. does it integrate well with the rest of standard C++? .. This is not meant to be an exhaustive list, and I don't mean to imply that every proposal needs to score an A+ with respect to each of these criteria in order to win the favor of the individuals that participate in the LWG. My point is that these are the sorts of questions that guide the thinking of each of the people who were hearing proposals in Lillehammer. I can't speak for anyone else, but personally, I felt the answer to too many of the questions that I've listed above is "no" or (especially in the case of #6) "we don't know." That was the reason that I, at least, didn't support the proposal. It's easy to petulantly assert that the people who expressed "no support .. at this time" are motivated by conflict of interest or evil spirits, but the simple fact is that a group of responsible and professional agents didn't find the proposal compelling enough. That's the thing about proposals; you need to sell them. There are lots of powerful ways to sell an idea, and attending a meeting to address concerns and reservations is only one of them (for example, Boost is a brilliant mechanism for proving the value of a proposal, and TR1 demonstrates that). Disparaging the folks to whom you want to sell an idea is not an effective sales technique and, obviously, it's counter-productive since it impairs your credibility. As I said, LWG members are open-minded. Any (and perhaps all) of them could eventually be compelled change his mind with respect to the questions in the above list. Yes, that means more work for the proposer, and that work could consume many years of effort. As has been noted already, shared pointer had a gestation period of about a decade. That's the way it goes, and that's why there will probably be a TR3 and a TR4. A proposer may not be willing to devote the time and care to develop a proposal over such a long period (and it is still no guarantee of acceptance), but that's his or her decision. Bottom line: proposers should be prepared to sell their proposals. This might take a long time. Proposals that are based on accepted Boost libraries are already somewhat pre-sold, since they are assumed to satisfy categories 1 to 4, and maybe even 5. If you don't want to have to sell a proposal, or you can't deal well with constructive criticism or rejection, find a collaborator who can help you. Accept that your proposal might never be accepted -- it's up to you to decide whether time spent on a rejected proposal is time wasted, but I think it generally isn't. -- Robert Klarer
klarer@ca.ibm.com wrote:
How many of these criteria were applied to export? :o) And to illustrate bias again, why weren't: 8. can it be implemented efficiently? 9. could users pay for features they're not using? there? That's where policy_ptr might be in better shape than shared_ptr. If I were around, I would have made sure those criteria are included as well.
Hey, nobody disparaged anyone; I took time to explain how I myself am biased, and how others might be biased, and I also gave an example of a potential bias. From there to "evil spirits" it's a long way. Maybe "conflict of interest" ain't the proper syntagm, and "unintentional bias" would be. Library design and appreciation is subjective; that makes it hard to stay unbiased towards a particular design. I know I am biased myself, albeit not to the point of being unreasonable. Naturally I'd believe others might be as well, and I don't think I dispense offense in saying that. At the end of the day, it's very true: one has to sell one's design, and that happens exactly because appreciating ("buying" :o)) a design is an experience that has a strong subjective aspect to it. Andrei
So be it. You couldn't (and most probably shouldn't) do anything about it. If policy based design indeed superior (which I believe it is) it will find it's way to hearts and minds of people. Give it some time and put it some efforts. One big step (IMO) would be a boost acceptance. As well as boost rejection would hurt it a lot (I think). So let's make sure it wouldn't happened. Gennadiy
"Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail@moderncppdesign.com> writes:
All of them, to different extents by different people. Some people were very concerned about these criteria. Others apparently (and IMO wrongly) thought the benefits of having export immediately outweighed the potential problems.
Maybe because Robert was listing points upon which the proposal didn't fare well but that he thought were worthy of consideration? You're not helping your case at all by claiming everything points to bias. It just looks paranoid.
You don't seriously think that the LWG fails to recognize and consider these primary concerns about shared_ptr?
Maybe, not but it's not a long way from what you *actually wrote* to "evil spirits." Starting from "conflict of interest" connected to lobbying and voting and then proceeding to a suggestion that people are claiming something they don't "really really believe" and "convenient" forgetting of crucial facts, there's a lot in there to take as disparaging.
Maybe "conflict of interest" ain't the proper syntagm,
You bet it ain't proper, whatever syntagm means. What the heck's a syntagm?
and "unintentional bias" would be.
And that would be practically tautological. "How does the committee deal with the fact that members are human beings?" is not a very interesting (or answerable) question.
Think again. Your last post was unreasonable.
Naturally I'd believe others might be as well, and I don't think I dispense offense in saying that.
Whether you dispense offense is in the ear of the listener, and I'm hearing it.
Absolutely correct. As I said, you can't design that out of the system, so you'd better learn to work with it. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
By the way, who was it who just called and hung up??? :oD
Yeah, "conflict of interest" isn't the word because there's not a real "interest" there, but rather a mere subjective opinion. But then let me ask this again: if binary compatibility is assigned such a weight on shared_ptr, then why isn't it a concern for other obvious candidates in the standard library, such as strings and vectors? Shouldn't we measure those guys by the same measure? Again, binary compatibility is a very useful feature, but it should only be assigned so much importance.
You bet it ain't proper, whatever syntagm means. What the heck's a syntagm?
http://www.m-w.com says: syntagm is one of more than 1,000,000 entries available at Merriam-WebsterUnabridged.com. Click here to start your free trial!
Maybe you are particularly sensitive towards yours truly.
Absolutely correct. As I said, you can't design that out of the system, so you'd better learn to work with it.
I think that is fine. Actually I perfectly realize I am lobbying right now, and having a subjective opinion... Andrei
"Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail@moderncppdesign.com> wrote in message news:d4ov22$86i$1@sea.gmane.org... | David Abrahams wrote: | > Maybe, not but it's not a long way from what you *actually wrote* to | > "evil spirits." Starting from "conflict of interest" connected to | > lobbying and voting and then proceeding to a suggestion that people | > are claiming something they don't "really really believe" and | > "convenient" forgetting of crucial facts, there's a lot in there to | > take as disparaging. | | Yeah, "conflict of interest" isn't the word because there's not a real | "interest" there, but rather a mere subjective opinion. But then let me | ask this again: if binary compatibility is assigned such a weight on | shared_ptr, then why isn't it a concern for other obvious candidates in | the standard library, such as strings and vectors? Shouldn't we measure | those guys by the same measure? Again, binary compatibility is a very | useful feature, but it should only be assigned so much importance. Let me wrap up my reasons for not showing that much interest in the proposal: 1. is it worth the effort to standardize it? 2. does it help many users? 3. how does it compare to adding GC instead to the language? 4. won't experts just go to boost to pick up this thing? 5. can many, many smart pointers hurt C++, because it makes interoperability harder? 6. can all these different pointers be hard to use in exception-safe code because they all behave slightly different; some might throw on assignment, some might not etc. -Thorsten
From: "Andrei Alexandrescu (See Website For Email)"
I wondered that, too.
Yeah, I punted and went to dictionary.com (http://dictionary.reference.com/search?q=syntagm): 1. A sequence of linguistic units in a syntagmatic relationship to one another. 2. A sequence of words in a particular syntactic relationship to one another; a construction. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
"Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail@moderncppdesign.com> writes:
What are you implying??? ;oP
I'm not going to belabor this, but what appears to be an attack in your post goes well beyond a mere poor choice of words.
I don't know that binary compatibility *is* "assigned such a weight on shared_ptr," but let's suppose for a minute that it is. Maybe you're looking at it the wrong way. It might be assigned such a weight because it's a nice feature that nothing else has, and that can be used to pass those other things (like strings and vectors) across DLL boundaries.
Shouldn't we measure those guys by the same measure?
I don't see why. We don't measure std::vector by its inability to do O(log N) lookups and insertions. We don't expect std::vector to be a set, nor do we expect it to act like a shared_ptr.
Again, binary compatibility is a very useful feature, but it should only be assigned so much importance.
Perhaps it only _is_ assigned so much importance. How do you know what relevance it's given by the various people deliberating?
Hmm, not a vert useful definition. I'll try http://www.thefreedictionary.com/syntagm
Believe it or not, Andrei, I find I am predisposed to like you and forgive your trespasses. The fact that you have such a likable personality only makes it harder to understand when you let fly this kind of base accusation. -- Dave Abrahams Boost Consulting www.boost-consulting.com
At Wednesday 2005-04-27 14:14, Andrei Alexandrescu (See Website For Email) wrote:
David Abrahams wrote:
[deleted]
and just a little more research http://dictionary.reference.com/search?q=syntagm says: 2 entries found for syntagm. syn·tag·ma P Pronunciation Key (sn-tgm) also syn·tagm (sntm) n. pl. syn·tag·mas or syn·tag·ma·ta (-tgm-t) also syn·tagms 1. A sequence of linguistic units in a syntagmatic relationship to one another. 2. A sequence of words in a particular syntactic relationship to one another; a construction. [New Latin, from French syntagme, from Greek suntagma, suntagmat-, arrangement, syntactic unit, from suntassein, suntag-, to put in order. See syntax.] [deleted] Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
klarer@ca.ibm.com wrote:
Andrei wrote:
How many of these criteria were applied to export? :o)
Sorry, but that's irrelevant to this discussion. The decision to approve export was made a decade ago, in a situation that is very different than the present one, and many of the faces have changed since then. The committee, IMO, made a mistake back then, and some committee members have chosen to draw a lesson or two from the experience. I don't think that you're suggesting that the committee should continue to commit the same kind of mistake, so I'm not sure that I understand your point, here. Andrei wrote:
No bias has been illustrated. As Dave noted, I didn't mention these criteria because they are not pertinent to the present discussion. The fact that my list of criteria was not meant to be exhaustive is signified by the ellipsis that appeared at the end of the list (you chose not to include the ellipsis when you quoted me), and the sentence that reads "this is not meant to be an exhaustive list...." :-) Andrei wrote:
From there to "evil spirits" it's a long way.
Not a long way. You seemed to be presuming, without evidence or other rational justification, that there was a conflict of interest or unintentional bias. I mentioned "evil spirits" in order to draw a parallel to another form of superstition. Andrei wrote:
experience that has a strong subjective aspect to it.
Maybe. But before subjective criteria are considered, folks like me are going to ask questions that can be answered objectively. If the answer to too many of those questions is "no" or "we don't know," then the subjective criteria don't much matter to me. Again, I can't speak for anyone else, but I can say that I applied the same tests to every proposal, and the proposals that failed a large number of these tests didn't receive my support. There is no need to postulate any kind of bias -- intentional or otherwise -- against particular proposals or proposers in order to explain why some papers were less well received than others. -- Robert Klarer
"Jeff Garland" <jeff@crystalclearsoftware.com> wrote in message news:20050423224553.M84538@crystalclearsoftware.com...
Just remember, the LWG doesn't standardize libraries out of thin air. We can't standardize libraries that are never formally proposed. There has to be a written proposal, and it has to meet various criteria. (The LWG is working on a Call for Proposals, with a deadline of this Friday, which will identify the criteria for proposals, but essentially TR2 is the same as TR1.) --Beman
On 4/23/05, Jeff Garland <jeff@crystalclearsoftware.com> wrote:
The various ports of "log4j" seem to take the approach of translating the Java object model to C++ 1:1. I don't think this is necessarily a Good Thing. I've personally looked at or used: log4cxx (URL above) - Stable release is "substantially out of date, has known serious deficiencies". Unclear when next release will be forthcoming. Next release introduces dependency on APR (Apache Portable Runtime) which may be too much baggage for some. log4cpp (http://log4cpp.sourceforge.net/). No stable releases since Jan 2002. Development release actually looks pretty good, but misses some important (IMHO) appenders like RollingFileAppender. log4cplus (http://log4cplus.sourceforge.net/). Similarly devoid of new releases but I think this is the most complete (and probably largest) of the three. I use it in production. Each of these mirrors log4j quite closely, including the IMHO horrible configuration syntax. Each also seems to have lost maintainer-steam as each has a number of missing features or imoprtant bugs. My #1 criticism of all three, though, is that the log4j object model is over-large and should not be the basis of a C++ logging framework. Aside from having contributed a few snippets of code to John Torjo's proposed Boost Logging library, I think it is already better than any of these because it is a clean-room design and is more simple and flexible for it. -- Caleb Epstein caleb dot epstein at gmail dot com
At Saturday 2005-04-23 19:46, you wrote:
if we're going to consider updating any of the algorithms, why can't we somehow update them all so that somealg(c.begin(), c.end(), morepossibleargs) means exactly the same thing as: somealg(c, morepossibleargs) ? More precisely, why don't all the algorithms additionally take ranges as single args instead of pairs of iterators? and then why isn't the name of a container equivalent to the range of all its elements? Sufficiency of the current syntax is an uninteresting answer. calling it "syntactic sugar" is likewise uninteresting as an answer.
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
"Victor A. Wagner Jr." <vawjr@rudbek.com> wrote in message news:6.2.0.14.2.20050423222733.080be828@mail.rudbek.com... | At Saturday 2005-04-23 19:46, you wrote: | | >"Thorsten Ottosen" wrote: | > | > > Besides, boost.date_time I think these other libs are good candidates | > > (maybe | > > with slight modifications): | > > | > > 2. optional | > > | >This would be very useful addition. | > | >It would likely require update of algorithms, e.g. std::sort | >to deal with containers of optionals. | | if we're going to consider updating any of the algorithms, why can't we | somehow update them all so that somealg(c.begin(), c.end(), morepossibleargs) | means exactly the same thing as: | somealg(c, morepossibleargs) | ? Don't worry; I'll propose this as part óf my submission of boost.range. -Thorsten
Thorsten Ottosen writes:
Please be sure to coordinate with other people who worked/are working on the topic, then. See http://article.gmane.org/gmane.comp.lib.boost.devel/120408/, for instance. This is way too important to allow a false start, IMO. -- Aleksey Gurtovoy MetaCommunications Engineering
"Aleksey Gurtovoy" <agurtovoy@meta-comm.com> wrote in message news:m1d5sjfh5l.fsf@tulip.office.meta... Thorsten Ottosen writes:
"Victor A. Wagner Jr." <vawjr@rudbek.com> wrote in message
Please be sure to coordinate with other people who worked/are working on the topic, then. See http://article.gmane.org/gmane.comp.lib.boost.devel/120408/, for instance. This is way too important to allow a false start, IMO.
>>>>>>
Well, I'm not proposing new iterator concepts, although David and Dietmar might be. That said, Ranges pretty much follow whatever iterator categories that exists. I won't have time to look into this stuff for some time. If you feel its important, go do the work. -Thorsten
Thorsten Ottosen writes:
FWIW, the cited posting is not about "new iterator concepts". It discusses building a proper algorithm dispatch scheme, which is central to any library that introduces overloading of algorithm names.
Please read more carefully what I said. It's important to get this right, not to get it into standard ASAP. -- Aleksey Gurtovoy MetaCommunications Engineering
"Aleksey Gurtovoy" <agurtovoy@meta-comm.com> wrote in message news:m18y3561hw.fsf@tulip.office.meta... FWIW, the cited posting is not about "new iterator concepts". It discusses building a proper algorithm dispatch scheme, which is central to any library that introduces overloading of algorithm names.
Please read more carefully what I said. It's important to get this right, not to get it into standard ASAP.
>>>>>
Sorry, I don't have the energy to introduce a new dispatch scheme. -Thorsten
Beman Dawes wrote:
So far there are plans to propose Boost.Threads,
Is this something that's already being worked on? I have some ideas that I've been thinking about to improve Boost.Threads, and some other ideas that have been suggested to me (primarily by Roland Schwarz), that I'd like to at least get other people's opinions of before a Boost.Threads proposal goes too far. Some of the ideas come from the big lock-unification discussion that took place on this list some time ago (although I think I've come up with some interesting ideas on that topic that weren't mentioned in that discussion). I have some other ideas as well that I think people might find intereting. On a related note, my last day at my job was Friday, so hopefully after a bit of transition I'll have some more time actually to work on this and also work on various bug reports before the next release. Mike
Michael Glassford wrote:
See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1682.html Jonathan
Michael Glassford wrote:
I'm interesting in reworking some areas of Boost.Threads that I find lacking, so you should probably announce your plans so that we can avoid duplication of efforts. I'm not sure whether we need to bother, though. The current Boost.Threads already seems "fast-tracked" into C++0x, with Beman, Howard and Pete Becker behind it. Major changes probably don't stand a chance. And I'm not very optimistic about any minor changes, either.
Sorry if this is not the place to discuss it, but if we have some discussion about threads, I always wondered why thread () constructor launches automatically a thread in constructor. This means that when you code an active class (I mean, I class that represent a task in other thread), if you want to start it on demand, you must use dynamic memory constructing the object in heap. I mainly work in embedded systems that may not have dynamic memory and I think an static way should be provided, since those systems do have threads. I would prefer an option like this: class work_in_other_thread { work_in_other_thread(const boost::function0<void>& func) : m_thread(func){} void start_work() { //this function does not exist in boost threads m_thread.start(); } private: boost::thread m_thread; }; instead of : class work_in_other_thread { work_in_other_thread(const boost::function0<void>& func) : mp_thread(0), m_func(func) {} void start_work() { m_thread = new boost::thread(m_func); } private: std::auto_ptr<boost::thread> mp_thread; boost::function0<void> m_func; }; I see also dynamic memory in proxy functions in the code, but I think it's an implementation detail that could be optimized in systems when needed, storing needed data in boost::thread class if it is a joinable thread. Or we could use an internal, hand-made segregated storage pool for data needed by boost::threads. I don't want to start a flame war, but I would suggest a dual start now/start on demand approach, adding a different constructor and a trigger function. I also think that the standarization of the lock interface is important. Currently, I'm working in shmem library mimicking boost locks/conditions for process-shared locks/conditions. Boost threads explicitly checks for multithreaded build when including thread locks (for example scoped_lock) and it would be nice to reuse those locks in single threaded processes using process-shared mutexes. Ditto for xtime structure. Sorry for the lenghty post about threads, it is just that I couldn't resist it! I would be glad to discuss some boost thread aspects if there is a opportunity for this. Regards, Ion
Ion Gaztañaga wrote:
Sorry if this is not the place to discuss it, ...
Where else? ;-)
Use aligned_storage<> and placement new.
This would force you to keep the boost::thread object alive for the duration of the thread; the function object needs to be stored somewhere.
"Peter Dimov" <pdimov@mmltd.net> writes:
Use aligned_storage<> and placement new.
I think boost::optional<> should also work for this job, but the area of the interface that seems like it ought to handle the problem seems to be poorly documented so I can't be sure it does. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Peter Dimov wrote:
Use aligned_storage<> and placement new.
Sorry, I didn't know what aligned_storage was for, boost is really huge. I've seen it uses a union using alignment information from other boost tools. Doing an placement new invalidates automatic destructor, so it sounds to me like the famous ugly pimpl hack to avoid dynamic memory and header dependences, based on max_align. Anyway, it is true that dynamic memory is the best way to make thread lifetime independent from boost::thread object's lifetime, so maybe in those special systems, a singleton memory pool should be used for this, if "new" function is not available. What I don't know if that singleton lifetime can lead to problems because I don't know if threads must exit before static object destructors are called, but this is another topic. I think embedded C++ should be taken in care because C++ is used a lot in this area (for example, eCos embedded OS is written in C++ with a C wrapper API). The C++ phylosophy ("you don't pay for what you don't use") is very nice in these systems, if you know what is happening behind the scenes with C++ (inheritance, constructor/destructors, etc...). It would be nice to have some brainstorming regarding boost threads if it is possible. I don't know if C++0x wants only to include basic functionality in threads but I think developers are waiting for some more complex utilities, like thread pools. Regards, Ion
FWIW I like the thread concepts by Peter A. Buhr in url:<http://jupiter.robustserver.com/pipermail/cpp-threads_decadentplace.org.uk/2005-March.txt.gz> regards Andy Little
< lots of good suggestions snipped > I agree that threading needs to find its way into the standard and hope enough progress is made soon to make this a reality. I hope many aspects from the shmem library and others are considered to enrich the basic functions currently offered by boost threads. This would improve the utility of a 'threads' submission in my opinion. I also think that thread priority and scheduling need to be implemented in some form. I appreciate that in certain OSes this isn't possible, but if such priorities/scheduling types were hints which an implementation were free to ignore then why couldn't these feature as say optional constructor parameters or in a member function for adjusting priority/scheduling type. I couldn't find the mailing list discussion (that I expect did happen) regarding the reasons not to include priority etc.in the interface, but would be interested if their inclusion may be possible in future revisions of boost thread. I also find the notion of creating a new thread and monitoring an existing thread being represented within the same class (with different constructors) as being slightly non-intuitive. This may be one of many areas where boost threads could benefit from a more tutorial-based set of documents rather than a purist model/concept set of docs. Paul
"Peter Dimov" <pdimov@mmltd.net> writes:
AFAIK nothing the LWG is doing now other than TR1 and fixing TR1 defects is going to make it into C++0x.
Major changes probably don't stand a chance. And I'm not very optimistic about any minor changes, either.
I think it's too early to make that judgement. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Peter Dimov wrote:
Oops. (Thanks Dave Abrahams for writing me about this thread.) That's news to the group that is actively working on standardizing a memory model for C++. (See http://jupiter.robustserver.com/pipermail/cpp-threads_decadentplace.org.uk/ for details.) I think I'd be representing the opinion of the entire group by saying that a library-only approach is naive at best. See for example "Threads Cannot Be Implemented As A Library" by Hans Boehm at http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf, paper admitted at the prestigious conference PLDI 2005 (sign that others believe Hans actually makes sense). Actually I believe that any expert in threading would cringe at the thought that Boost.Threads made it in the C++ standard. Speaking for myself about the quality of Boost.Threads' design itself, I would add that it compares unfavorably (to use an euphemism) with many other threading library interface for C++ or other languages - actually all I know of, including unpublicized ad-hoc threading libraries developed in-house at various companies I've worked with. At any rate, if Boost.Threads is to be standardized, then it would be good to let everybody know because that would imply dissolvation of the group that I have started and that Hans Boehm is de facto leading. Andrei
"Andrei Alexandrescu (See Website For Email)" wrote: [...]
You better first fix POSIX (data race-free) memory model. Extending it with atomic<> for lock-free programming is the next step. I've got a bunch of DRs against POSIX XBD 4.10 sitting "open" for ages with no progress on horizon at all. Perhaps cpp-thread "decadence" gang can help, so to speak. http://www.opengroup.org/austin regards, alexander.
"Michael Glassford" <glassfordm@hotmail.com> wrote in message news:d4erir$lhv$1@sea.gmane.org...
Sort of. The extensions working group is encouraging work on core language memory model wording to make threading more legitimate. They have asked someone to coordinate with library folks, but I don't think anything has been done yet. So in the meantime, nothing appears to be happening. That isn't at all uncommon - the committee is all volunteers, so there are periods of inactivity. But there is a lot of interest in threading, so I expect one or more actual proposals to surface.
If you (or Peter, or anyone else) has ideas for improving Boost.Threads, now is the time to get going on them. --Beman
Beman Dawes <bdawes@acm.org> writes:
Really? I have been under the impression for a long time that those plans had withered. What's going on that I don't know about. Progress towards a C++ threading API standard is a big concern for me. Several efforts have been talked about, but none are proceeding in a manner that gives me confidence we're going to get the job done. Part of it may be that any work being done is insufficiently visible to the public eye, i.e. mine ;-). Even if people find it more practical to work in private I think it may be important to make visible status reports. Otherwise the interested community will either be: a. working at cross-purposes, or b. waiting for the other guy to produce results More likely, both. I'm also concerned that none of the practicable dates mentioned above will make the EWG's cutoff date for C++0x, and I'm not sure we can afford to release another standard without threading support. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"Peter Dimov" <pdimov@mmltd.net> writes:
I would if I remembered for sure. I think it's something like, no new proposals considered after the next meeting.
That's a possibility, but it doesn't necessarily align with some strong convictions from experienced concurrent programmers on the committee. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uy8b8kxe6.fsf@boost-consulting.com... | "Peter Dimov" <pdimov@mmltd.net> writes: | | > David Abrahams wrote: | >> I'm also concerned that none of the practicable dates mentioned above | >> will make the EWG's cutoff date for C++0x, and I'm not sure we can | >> afford to release another standard without threading support. | > | > You should probably mention what the EWG cutoff date is. :-) | | I would if I remembered for sure. I think it's something like, no new | proposals considered after the next meeting. | | > As for the "afford to release"... There's always the safe choice of | > <cpthread> + specifying that cancellation is a C++ exception. C++ification | > can then be done in a TR. | | That's a possibility, but it doesn't necessarily align with some | strong convictions from experienced concurrent programmers on the | committee. As I said earlier, Lawrence Crowl is heading a groups looking at a threads library for C++0x. Most importantly, I believe Kevlin Henney will get a chance to submit his work. -Thorsten
Peter Dimov wrote: [...]
That shall better be done first, before "fast tracking" thin OO layer of questionable value. C++ shall simply incorporate Pthreads and provide both legacy C interface and new better OO/GP stuff. Ultimately, some TR or whatnot shall provide reference implementation of legacy stuff using new <thread>, not the other way around. ADA-like highlevel stuff a la protected objects is the next step (C++1X, I'd guess). regards, alexander. -- http://www.google.de/groups?selm=412533CA.82703A04%40web.de
Paris (U.E.), le 04/05/2005 Bonjour In article <6.0.3.0.2.20050422110501.042b2a20@mailhost.esva.net>, Beman Dawes <bdawes@acm.org> wrote:
[SNIP]
Dare I say that this time around I would try to not drop the ball (again) and propose the quaternions and octonions as possible "Small Additions"? Merci Hubert Holin
"Hubert Holin" <Hubert.Holin@meteo.fr> wrote in message news:Hubert.Holin-6DA78B.18275104052005@sea.gmane.org...
Walter Brown and Marc Paterno from Fermilab are the LWG's numerics guys. If they are in favor of such a proposal, it would be a big help. I'd suggest you contact them and ask for their opinions. Contact me privately if you need their email addresses. Normally I would volunteer to champion almost any proposal coming out of Boost, but I don't even know how to pronounce quaternion or octonion! --Beman
"Beman Dawes" <bdawes@acm.org> wrote in message news:d5bav1$fha$1@sea.gmane.org... | | "Hubert Holin" <Hubert.Holin@meteo.fr> wrote in message | news:Hubert.Holin-6DA78B.18275104052005@sea.gmane.org... | > Paris (U.E.), le 04/05/2005 | > | > Dare I say that this time around I would try to not drop the ball | > (again) and propose the quaternions and octonions as possible "Small | > Additions"? My understanding of the quaternions lib is that it is not useful for doing rotations and that stuff needed in the 3D graphics world. If you intend to submit it, I would like to see motifications that made this possible. -Thorsten
Somewhere in the E.U., le 30/05/2005 Bonjour In article <d5bk7j$jg7$1@sea.gmane.org>, "Thorsten Ottosen" <nesotto@cs.auc.dk> wrote:
Could you please elaborate? I did include one possible way of linking with rotations in the library. This work did stem (in part) from some work with rotations specifically for some 3D graphics problem (though this part, interpolation of orientation under constraints, is *not* included in the library).
I am open to any suggestion. I must say this post is something of a surprise to me. Perhaps are you referring to the lack of any "reasonably standard" C++ implementation of rotations in R^3? Merci Hubert
"Hubert Holin" <Hubert.Holin@meteo.fr> wrote in message news:Hubert.Holin-94C135.13380630052005@sea.gmane.org... | Somewhere in the E.U., le 30/05/2005 | | Bonjour | | In article <d5bk7j$jg7$1@sea.gmane.org>, | "Thorsten Ottosen" <nesotto@cs.auc.dk> wrote: | | > "Beman Dawes" <bdawes@acm.org> wrote in message | > news:d5bav1$fha$1@sea.gmane.org... | > | | > | "Hubert Holin" <Hubert.Holin@meteo.fr> wrote in message | > | news:Hubert.Holin-6DA78B.18275104052005@sea.gmane.org... | > | > Paris (U.E.), le 04/05/2005 | > | > | > | > | > Dare I say that this time around I would try to not drop the ball | > | > (again) and propose the quaternions and octonions as possible "Small | > | > Additions"? | > | > My understanding of the quaternions lib is that it is not useful for | > doing rotations and that stuff needed in the 3D graphics world. | | Could you please elaborate? I did include one possible way of | linking with rotations in the library. This work did stem (in part) from | some work with rotations specifically for some 3D graphics problem | (though this part, interpolation of orientation under constraints, is | *not* included in the library). | | > If you intend to submit it, I would like to see motifications that made this | > possible. | > | > -Thorsten | | I am open to any suggestion. I must say this post is something of | a surprise to me. Perhaps are you referring to the lack of any | "reasonably standard" C++ implementation of rotations in R^3? no, I think I'm referring to comment from Gary Powel about this issue (he works in the Games industry, I think) anyway, I don't have seriuos time to investigate this issue, but maybe you could look at scene graph packages like OSG to see if you can do the same: http://www.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/clas... best regards Thorsten
"Thorsten Ottosen" <nesotto@cs.auc.dk> wrote in message news:d7flif$mvb$1@sea.gmane.org... | no, I think I'm referring to comment from Gary Powel about this issue (he | works in the Games industry, I think) I think my reference must be http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1752.html -Thorsten
Somewhere in the E.U., le 02/06/2005 Bonjour I am combining here answers two two posts, which, in unison, I think validate my point. The possible objection to the usefulness of quaternions, for a significant portion of potential users at least, is the absence of a direct link to their favorite - and mutually incompatible - domain-specific API, leading to inefficiencies. This, to me, only betrays the fact that it is these other domain-specific API that need to be optimized for the domain's need (speed or whatever), and perhaps, ultimately, standardized, not a general tool such as quaternions and octonions. Quaternions, while inherently useful to, say, games, are not limited to that domain and, beyond the difficulty of trying to standardize APIs for non-standardized and competing libraries, I believe it would be wrong to not standardize them or specialize early for one problem domain. It would be akin to not standardizing the complex numbers in C++ because no direct link is provided to plane rotations, or including a link to a specific non-standardized API in the standard for C++ complex numbers. I might add that extant libraries only code well-know solutions to problems. I started this work in part because a particular problem had to be solved (interpolation of orientation under constraint, which has real economic meaning for the companies involved). The problem has been solved but has not been officially published (nor sold, for various reasons), so does nor appear (AFAIK, it's been quite a few years since I did that) in libraries today. Using a quaternion library independent from any existing 3D library enables me to solve the problem for all of them. Specializing for one would leave out the others. This is just an example, there are other real problems waiting to be solved, and the right level of abstraction to solve them is not the existing 3D libraries (properly speaking the "proper level of abstraction" is the mathematical realm, but what we propose are "incarnation" of the objects we use). While we are dealing with examples, a related problem, dealing with speed, is *quickly* finding *many* very close rotations, say in the plane, with a lessened emphasis on precision. A naïve way of doing this with incrementing the angle and using transcendental functions usually is not the best way to proceed. Again, thinking within the box of a given 3D API is not the most useful way, unless this API provides us with good incarnations of mathematical objects. One could at least hope that (in the best of worlds...) the standardization process would produce something sensible in that regard. It is an open secret that the lack of a de jure standard C++ way of representing elementary low-dimensional objects such as rotations is hurting us all (from GUI designers to physicists). Proposals for such surface here from time to time, but none has gone so far as to be submitted for review, IIRC, which IMHO is a shame. What I believe would be good would be to standardize the quaternions and octonions on their own, provide non-normative (but efficient) links with specific APIs (in a way similar to the example link I provide with the library), or at least with a few of them to avoid the kind of situation we are in w.r.t. Unicode, and when the other domains have their API standardized as well, finally provide standard links (faster than w.r.t. Unicode ;-) ). It would at least help to prevent each domain-specific library to reinvent the wheel (there are quaternions in many extant libraries, tailored to the local needs...), when what they really need is the vehicle using these wheels, and perhaps help communication between them, paving, perhaps, the way for their own standardization. Let's do things one step at a time (while not being oblivious to the bigger picture). In article <d7flif$mvb$1@sea.gmane.org>, "Thorsten Ottosen" <nesotto@cs.auc.dk> wrote:
In article <429C4777.2090302@hellinc.net>, Martin Slater <mslater@hellinc.net> wrote:
Merci Hubert
I'll openly admit now I read about octonions only once (in a Scientific American article about string theory I believe) and have absolutely no idea about there usefulness for anyone;)
Absolutely, the only point I was making is that without providing all the other bits that go along with quaternions people (within this industry) with have to turn to another library to provide them and that library will undoubtably offer quaternions as well making it likely they will be used in preference to the potentially standardised ones if only for api consistency.
This is one of those areas of a lot of research from the graphics guys in solving problems relating to animation and IK but this is not my area of expertise .
Absolutely, I was only talking of the industry that I'm a part of and have some knowledge about.
I'm not convinced either that the general 3d toolsets out there are the best way. Generalised matrices can be blunt tools and I have experimented in the past with having seperate but related matrices, basis' , coordinate systems, vectors, points to allow more saftey in the actual coding and remove a whole class of errors from doing non-sensicle things with these mathmatical objects. Alas this was quite a few years ago and my skills were not up to producing something I was happy with but it seems it could be a natural progression of with the work mentioned on this list (started by abrahams and gurtovoy?) on dimensional analysis through metaprogramming (ie enforcing the rules through types).
Personally I would love to see all of what I suggested earlier standardised and quaternions / octonions could be a very good starting point for this if only to set a precedent but I am pessamistic about its potential uptake by the games community.
Ah a standadised graphics API, would be beautiful but with Microsoft deciding to not follow the OpenGL standard many years ago and go their own way for their own reasons this is not much beyond a pipe dream at the moment;) Martin -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.322 / Virus Database: 267.4.0 - Release Date: 1/06/2005
Hi Martin, I turned up this old post of yours: It seems that what I'm doing here: http://tinyurl.com/qp56p isn't anything new ! regards Andy Little P.S. (I hope top posting is acceptable in this case) "Martin Slater" <mslater@hellinc.net> wrote in message news:429EEF8A.5010309@hellinc.net...
I'll openly admit now I read about octonions only once (in a Scientific American article about string theory I believe) and have absolutely no idea about there usefulness for anyone;)
Absolutely, the only point I was making is that without providing all the other bits that go along with quaternions people (within this industry) with have to turn to another library to provide them and that library will undoubtably offer quaternions as well making it likely they will be used in preference to the potentially standardised ones if only for api consistency.
This is one of those areas of a lot of research from the graphics guys in solving problems relating to animation and IK but this is not my area of expertise .
Absolutely, I was only talking of the industry that I'm a part of and have some knowledge about.
I'm not convinced either that the general 3d toolsets out there are the best way. Generalised matrices can be blunt tools and I have experimented in the past with having seperate but related matrices, basis' , coordinate systems, vectors, points to allow more saftey in the actual coding and remove a whole class of errors from doing non-sensicle things with these mathmatical objects. Alas this was quite a few years ago and my skills were not up to producing something I was happy with but it seems it could be a natural progression of with the work mentioned on this list (started by abrahams and gurtovoy?) on dimensional analysis through metaprogramming (ie enforcing the rules through types).
Personally I would love to see all of what I suggested earlier standardised and quaternions / octonions could be a very good starting point for this if only to set a precedent but I am pessamistic about its potential uptake by the games community.
Ah a standadised graphics API, would be beautiful but with Microsoft deciding to not follow the OpenGL standard many years ago and go their own way for their own reasons this is not much beyond a pipe dream at the moment;) Martin -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.322 / Virus Database: 267.4.0 - Release Date: 1/06/2005 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hubert Holin wrote:
I wish I had a little more time to forward a more dignified response, but I sincerely hope you are not dissuaded in your work by those whom might otherwise object to fundamental mathematical objects being part of C++ or Boost for that matter. I for one, as you believe - think that we desperately need fundamental mathematical concepts/ objects enshrined in the language; there are too many of us out there needlessly reinventing the wheel when it shouldn't be. -Should I avail myself of more time (don't know when just yet, but I'll let you know when), but I would like to help you down this path if you're interested. Cheers, -- Manfred Doudar MetOcean Engineers www.metoceanengineers.com
This is somewhat limiting from a games programmers perspective. Quaternions on there own are definitely useful but the two common 3d apis (Direct3D and openGL) required conversion to 4x4 matrices before presentation to the API. So without a full range of 4 vectors, 3 vectors, and 3x3, 4x4 matrices at a minimum (and possibly 4x3 matrices as an optimisation) there's little chance that it'll get used by many in the industry. Obviously with 4x4 matrices and 4 vectors you can do anything that you could do with their 3 space counterparts (and more) but speed is always a primary concern with these things. Throw into that mix different "handedness" conventions (openGL is right handed, direct3d left handed) and its extremely hard to satisfy everyone. Octonions just don't have any major use as I know in the games business as a whole;) Anyway both these areas are well served by the D3DX library from Microsoft and others such as Dave Eberly's Wild Magic library so I'm not sure the games industry really needs this kinda thing standardised without going the whole hog and supplying everything. My 2c. Martin -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.322 / Virus Database: 267.3.0 - Release Date: 30/05/2005
Paris (U.E.), le 09/06/2005 Bonjour In article <d5bav1$fha$1@sea.gmane.org>, "Beman Dawes" <bdawes@acm.org> wrote:
[SNIP]
I did (to check if the addresses were the same as a couple of years ago). Did you receive my mail? Sorry for the bother, but I have a nagging suspicion that some of my mail, at least over the last month or so, is getting lost, either inbound or outbound.
That's OK! :-) Merci Hubert
On Fri, Apr 22, 2005 at 11:20:14AM -0400, Beman Dawes wrote:
As I mentionned in Lillehammer, I intend to submit a proposal concerning Boost.Interval (with my co-authors, Hervé Brönnimann and Guillaume Melquiond). It will be a subset of the functionality of Boost.Interval, which we think makes more sense than the full genericity/complexity of the Boost version. Hervé also mentionned to me his intention to propose Boost.Minmax. -- Sylvain
participants (36)
-
Aleksey Gurtovoy -
Alexander Terekhov -
Andrei Alexandrescu (See Website For Email) -
Andy Little -
Beman Dawes -
Bronek Kozicki -
Bronek Kozicki -
Caleb Epstein -
David Abrahams -
Edward Diener -
Felipe Magno de Almeida -
Gennadiy Rozental -
Howard Hinnant -
Hubert Holin -
Iain K. Hanson -
Iain K. Hanson -
Ion Gaztañaga -
Jeff Garland -
John Maddock -
Jonathan Turkanis -
klarer＠ca.ibm.com -
Manfred Doudar -
Martin -
Martin Slater -
Matt Hurd -
Michael Glassford -
Paul Baxter -
Pavel Chikulaev -
Pavel Vozenilek -
Peter Dimov -
Rob Stewart -
Russell Hind -
Stefan Seefeld -
Sylvain Pion -
Thorsten Ottosen -
Victor A. Wagner Jr.