Re: [boost] quantity.hpp uploaded into files section
If one were to implement currency conversion, how might that be done, in general? Does one need to store the conversion rates between any two currencies (giving an N^2 size table), or might it be possible to convert any currency to some universal currency, and from that again to any other, and still getting the right values (giving a 2N table)? Regards, Terje ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_convertible: rationale and wording
Actually, there is another advantage, which (I think) is at least as
important as the ones you cite. Namely, it is possible to define a built
in operator such that is_convertibleY,X returns false for
class X{};
class Y : X {};
and ambiguous conversion cases that (as far as I can tell) cannot be
implemented in pure C++ (or even with any existing extension of which I am
aware). That means there's no reason for any ill-formed is_convertible
expressions, other than those involving incomplete types. That seems a
good enough reason by itself to reject the template in favor of a built in
operator.
Put another way, the whole point of is_convertible (as I understand it) is
to test a certain property of two types (or a type and an expression, if
you like). In order to perform the test, it should not be necessary to
know whether or not the types or expressions in question satisfy some
other
untestible properties.
The problem is that the question is A convertible to B has four answers:
yes, no, ill-formed, and ambiguous :-(
John.
Any code using the existing template could easily be converted to use a
built in operator. We gain (at least) three distinct and compelling
advantages, and it appears as though we loose nothing. Apart from getting
it standardized, what's the problem?
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_convertible: rationale and wording
I realize that I'm replying to a message that is now quite old. Hopefully what I have to say is still relevant. Apologies if not. Absolutely, there are a couple of procedural points I should make: 1) we are talking about a library only TR at present, core changes aren't allowed just yet. 2) The library TR is not the same as the standard, libraries accepted for the TR won't necessarily make it into the next standard (still several years away). 3) If vendors end up implementing is_convertible in terms of an intrinsic, and if that intrinsic turns out to be more useful than the template, you can guess which one will make it into the standard (the one you want). 4) There has been some concern expressed that meta-programming helpers should not be added piecemeal and that some kind of coherent framework should be created (whether in the core or in the lib). Regards, John. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [thread] Win32 mutex implementation
William E. Kempf wrote: Could this not have been implemented with a critical section and use TryEnterCriticalSection? Why was the mutex approach used for one and not the other? TryEnterCriticalSection is not portable. Specifically, it's not available in the Win9x line. Critical sections in Win32 are much more efficient than mutexes, which sometimes is important thing in multithreaded programs - especially those running on servers. It would be nice to use them in compatible environment ie. WinNT family . There could be some switch like: #define BOOST_THREAD_WIN32_USE_CRITICAL_SECTION which will force use of critical section instead of mutex. Of course program compiled with this switch might not run in Win9x, which is fine. If anybody wants to use mutex (ie. compile for compatibility with old environment) , he/she will just not define above mentioned symbol. I hope this proposal will not introduce maintenance nightmare. Just my $0.02 B. PS. I'm first-time writer here, hello all. PS2. there's old sample of recursive critical section ie. metered section in MSDN, see http://msdn.microsoft.com/library/en-us/dndllpro/html/msdn_metrsect.asp ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Quantity library: any interest?
From: David Abrahams [EMAIL PROTECTED] These are my (only slightly informed) opinions. I've heard Walter Brown talk about angle in this context, which was a big influence. Terje Slettebø [EMAIL PROTECTED] writes: Regarding this angle dimension, should it be treated like the other SI-dimensions? That is, say that you represent an SI quantity/unit with an integer vector giving the exponents: templateint kg,int m,int s,int A,int K,int mol,int cd,int angle class quantity; If you multiply two quantities, you multiply the value and add the exponents, so quantity0,1,0,0,0,0,0,0(10) * quantity0,1,0,0,0,0,0,0(10) = quantity0,2,0,0,0,0,0,0(100) (m * m = m^2) Would this hold for angle, as well? Yes. Angle is a dimensionless scalar (length/length). All its exponents are zero. Yes, Renej (in the posting I replied to) also pointed out that angle is a dimensionless quantity. However, in their real-life experience, they found it useful not to have it dimensionless, but instead having it as an additional dimension, to be able to distinguish things like velocity and angular velocity. It was in this context that I wondered how angle - as a dimension - should be treated. That is, does it make sense to say angle * angle = angle^2? Probably not, but only because angle * angle doesn't make much sense. Does that ever come up in real life? If it's a dimensionless quantity, it wouldn't matter (all exponents would still be zero). However, as a dimension, it would give angle^2. That's what I wondered about. I understand that e.g. angle/s (angular velocity) makes sense, but should a library allow any combination with angle and the other dimensions? Not arbitrarily: I meant - should it allow the same combinations as the other dimensions are allowed. That is (simplified, using only one dimension): quantityd1 * quantityd2 = quantityd1+d2 quantityd1 / quantityd2 = quantityd1-d2 quantityd + quantityd = quantityd quantityd - quantityd = quantityd angle(pi/2) / mass(40); // OK angle(pi/2) + mass(40); // error Let's again cast it in the quantity example template I gave in the last posting, to examine it. Let's say that the angle is expressed in radians. We then have: templateint kg,int m,int s,int A,int K,int mol,int cd,int rad class quantity; typedef quantity1,0,0,0,0,0,0,0 mass; typedef quantity0,0,0,0,0,0,0,1 angle; angle(pi/2) * mass(40) = quantity1,0,0,0,0,0,0,1(pi/2*40) (rad * kg) angle(pi/2) + mass(40) The last one will be an error, as you said. I'm guessing that the answer to my question is, yes, angle, when expressed as a dimension, may be treated like the other dimensions. There's also a question of what then if someone would like to add a money dimension, to avoid having money be interchangeable with dimensionless quantities. However, in this case, multiplying currencies with each other really doesn't make any sense (e.g. USD(10)*USD(10) = USD^2?), which _would_ be allowed, if it used the same framework as above. Therefore, maybe money is better treated in a different way, than with an exponent. Regards, Terje ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Quantity library: any interest?
From: [EMAIL PROTECTED] we use the int-based template approach for a couple of years now in our AGV controller software. We actually sometimes reach the stage that it works when succesfully compiled and linked. Since our control software is physics throughout (field of robotics), the type safety is very important. However, besides the basic SI units we also have 'angle' as a dimension which allows us to distinguish 'velocity' and 'angular velocity' for example. Hence, from out 'real user' experience (engineering point of view) it would be a necessity to add 'angle' as a dimension without breaking already defined quantities. Most (all?) units libraries already define 'angle' to be dimensionless, which is true in scientifically spoken, but pragmatically (engineering ;-) less handy. There's another question. If we add angle as a dimension, then what kind of angle is it? There are several kinds of angles, such as radians (plane angle) and steradians (solid angle). If both were represented by the same angle dimension, then it probably wouldn't make much sense to add radians and steradians (and what would be the resulting quantity?), yet, the library would allow it. Regards, Terje ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: quantity.hpp uploaded into files section
Terje Slettebø [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] If one were to implement currency conversion, how might that be done, in general? Does one need to store the conversion rates between any two currencies (giving an N^2 size table), or might it be possible to convert any currency to some universal currency, and from that again to any other, and still getting the right values (giving a 2N table)? Currency conversion as drop-in library is IMHO not possible - currencies differ from strict units like weight and future applications may require functionality beyond current requirements. Speaking about quantity.hpp uploaded to Yahoo: it is general purpose and lightweight utility to help with conversions. It doesn't know angles or currencies or SI. I prefere to use example of convering between screen pixel and image point - something application specific what cannot be known and implemented in advance by library writer. Conversion between well known physical units is covered by SIunits (and other libraries) and quantity.hpp doesn't try to compete with these. Another examples: - You may need to know date when one currency value was converted into another (to find exchange ratio): quantity.hpp may help here to keep details separated from application code. - Conversion between angle and geometric point (contrived application specific example). - 'Dynamic' conversions: currency is converted into another using available realtime exchange rate. - 'Lossy' and 'one way' conversions: rounding up to nearest $ and (intentionally) with no conversion back. I am interested if such a utility will be found useful. It is very simple code (just few constructors + cast operators + naming convention) but the name quantity probably gives expectations of very specific functionality. I may change the name (Safer Value Conversions would be better but is wordy). /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost regex in 1.30.0
John Maddock [EMAIL PROTECTED] writes: John, what are the correct names? I think I can patch your Jamfile for you. BBv2 is coming very soon, but this is so easy to do in BBv1 that it seems a shame to leave users hanging. The names are documented here: http://www.boost.org/libs/regex/appendix.htm#redist Note that the toolset names vary with toolset version, which probably messes up borland bjam builds (since there is only one bjam toolset, but since we have separate toolsets for vc6 and vc7 already, that should be possible. Done. BTW any chance of a separate toolset for vc71? I've checked in the one I'm using. You can probably figure out how to do the same thing for borland, so you have bcb4, bcb5, and bcb6 toolsets. In the meantime there's a BORLAND_VERSION variable you can set to control the one you want to generate the regex libs for. Please check all configurations to be sure that they work. Thanks, Dave -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [filesystem] new functions proposals
Trevor Taylor [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] So it sounds to me like the :blat is *not* part of the extension. It sounds like the NT file name is made up of three parts: name, extension and stream. In which case I think it is fine to have functions extension() and change_extension() - they just should not report or modify the stream part. To implement them I guess I'd need to know whether the file name was an NTFS filename, and then how to reliably locate the extension part? Functin DeviceIoControl() with parameter IOCTL_DISK_GET_PARTITION_INFO can do it. It is available on NT/W2K. Does it make sense to take into account NTFS drives for Win95/98 (from www.systeminternals.com) or Linux NTFS drivers? /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: is_convertible: rationale and wording
John Maddock [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: The problem is that the question is A convertible to B has four answers: yes, no, ill-formed, and ambiguous :-( John. Obviously, I think there should be only two :) That is, it would be nice to have a test that tells me the whether or not an assignment would or would not succeed. If I want to assign the result of an expression to a variable (or use it as a return value, etc), I don't particularly care WHY an assignment would fail. I just want to know whether it would or not. Perhaps it would be useful to have a set of tests that can tell you whether a conversion would fail for a specific reason, eg, conversion_is_ambiguous X,Y. But the real problem, as I see it, is that is_convertibleX,Y can fail to compile for certain choices of X and Y. That defeats the purpose of the test -- why would I ask if I can convert an X to a Y if I must already know the answer to do so safely? -- Mike Conley ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Quantity library: any interest?
Terje Slettebø [EMAIL PROTECTED] writes: From: David Abrahams [EMAIL PROTECTED] These are my (only slightly informed) opinions. I've heard Walter Brown talk about angle in this context, which was a big influence. Terje Slettebø [EMAIL PROTECTED] writes: Regarding this angle dimension, should it be treated like the other SI-dimensions? That is, say that you represent an SI quantity/unit with an integer vector giving the exponents: templateint kg,int m,int s,int A,int K,int mol,int cd,int angle class quantity; If you multiply two quantities, you multiply the value and add the exponents, so quantity0,1,0,0,0,0,0,0(10) * quantity0,1,0,0,0,0,0,0(10) = quantity0,2,0,0,0,0,0,0(100) (m * m = m^2) Would this hold for angle, as well? Yes. Angle is a dimensionless scalar (length/length). All its exponents are zero. Yes, Renej (in the posting I replied to) also pointed out that angle is a dimensionless quantity. However, in their real-life experience, they found it useful not to have it dimensionless, but instead having it as an additional dimension, to be able to distinguish things like velocity and angular velocity. They are distinguished! Velocity is l/t and angular velocity is 1/t - the same as frequency. Makes perfect sense to me. It was in this context that I wondered how angle - as a dimension - should be treated. That is, does it make sense to say angle * angle = angle^2? Probably not, but only because angle * angle doesn't make much sense. Does that ever come up in real life? If it's a dimensionless quantity, it wouldn't matter (all exponents would still be zero). However, as a dimension, it would give angle^2. That's what I wondered about. I understand that e.g. angle/s (angular velocity) makes sense, but should a library allow any combination with angle and the other dimensions? Not arbitrarily: I meant - should it allow the same combinations as the other dimensions are allowed. That is (simplified, using only one dimension): quantityd1 * quantityd2 = quantityd1+d2 quantityd1 / quantityd2 = quantityd1-d2 quantityd + quantityd = quantityd quantityd - quantityd = quantityd angle(pi/2) / mass(40); // OK angle(pi/2) + mass(40); // error Let's again cast it in the quantity example template I gave in the last posting, to examine it. Let's say that the angle is expressed in radians. We then have: templateint kg,int m,int s,int A,int K,int mol,int cd,int rad class quantity; typedef quantity1,0,0,0,0,0,0,0 mass; typedef quantity0,0,0,0,0,0,0,1 angle; angle(pi/2) * mass(40) = quantity1,0,0,0,0,0,0,1(pi/2*40) (rad * kg) angle(pi/2) + mass(40) The last one will be an error, as you said. I'm guessing that the answer to my question is, yes, angle, when expressed as a dimension, may be treated like the other dimensions. I guess I can't play in that mind-space, because I can't get away from what seems to me like a clear truth: angle is dimensionless. If you give it dimension, you'll get confusing results (like no relationship between angular velocity and frequency). I wonder what happens to physics calculations when frequency is expressed as rad/t? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_convertible: rationale and wording
Mike Conley [EMAIL PROTECTED] writes: John Maddock [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: The problem is that the question is A convertible to B has four answers: yes, no, ill-formed, and ambiguous :-( John. Obviously, I think there should be only two :) That is, it would be nice to have a test that tells me the whether or not an assignment would or would not succeed. If I want to assign the result of an expression to a variable (or use it as a return value, etc), I don't particularly care WHY an assignment would fail. I just want to know whether it would or not. The problem I was trying to point out with is_const_or_int_convertible was that if you want it to just work you really want some way of grabbing context at the interface to any metafunction that might need it, and passing it all the way down into is_convertible, so that it gets evaluated in the context of the outer invocation whatever that is. Perhaps it would be useful to have a set of tests that can tell you whether a conversion would fail for a specific reason, eg, conversion_is_ambiguous X,Y. Which begs the same question as the one I'm harping on above. But the real problem, as I see it, is that is_convertibleX,Y can fail to compile for certain choices of X and Y. That defeats the purpose of the test -- why would I ask if I can convert an X to a Y if I must already know the answer to do so safely? That's a whole different (and soluble, in the core) matter. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: is_convertible: rationale and wording
David Abrahams [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: That completely scuttles the ODR, as far as I can tell. Naturally, you wouldn't want to use a built in is_convertible this way. Better to pass it as a template parameter directly, rather than wrapping it: and_is_constT, is_convertibleT,int . If you know that the result of is_convertible depends on context, and you know about the ODR, then you know not to use is_convertible to as part of a metafunction's return value without also making it part of the metafunction's type (ie, using it as a template parameter). -- Mike Conley ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: is_convertible: rationale and wording
David Abrahams [EMAIL PROTECTED] wrote in
news:[EMAIL PROTECTED]:
The problem I was trying to point out with is_const_or_int_convertible
was that if you want it to just work you really want some way of
grabbing context at the interface to any metafunction that might
need it, and passing it all the way down into is_convertible, so that
it gets evaluated in the context of the outer invocation whatever
that is.
Right. But you only have that problem if you want to wrap
is_convertible inside a metafunction. Better to just use and_ directly.
The way to capture the context is to make it part of the type of your
metafunction:
template class T, bool ic
struct my_metafunction { /* ... */ };
// is_convertible operator applied in current context passed to
// my_metafunction.
my_metafunctionint, is_convertibleint, double
This also neatly solves any ODR problems. I'll admit it isn't as
usable, though.
But the real problem, as I see it, is that is_convertibleX,Y can
fail to compile for certain choices of X and Y.
That's a whole different (and soluble, in the core) matter.
What sorts of changes would be (or are being) considered?
--
Mike Conley
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Re: is_convertible: rationale and wording
Mike Conley [EMAIL PROTECTED] writes:
David Abrahams [EMAIL PROTECTED] wrote in
news:[EMAIL PROTECTED]:
That completely scuttles the ODR, as far as I can tell.
Naturally, you wouldn't want to use a built in is_convertible this way.
Better to pass it as a template parameter directly, rather than wrapping
it: and_is_constT, is_convertibleT,int .
If you know that the result of is_convertible depends on context, and you
know about the ODR, then you know not to use is_convertible to as part of a
metafunction's return value without also making it part of the
metafunction's type (ie, using it as a template parameter).
It doesn't matter if it's a template parameter. It's an ODR violation
to have:
template
struct is_whateverX
{
static bool const value = false;
};
and
template
struct is_whateverX
{
static bool const value = true;
};
in the same program, which is essentially the effect if is_whatever
uses a context-dependent is_convertible in its body.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Quantity library: any interest?
From: [EMAIL PROTECTED] we use the int-based template approach for a couple of years now in our AGV controller software. We actually sometimes reach the stage that it works when succesfully compiled and linked. Since our control software is physics throughout (field of robotics), the type safety is very important. However, besides the basic SI units we also have 'angle' as a dimension which allows us to distinguish 'velocity' and 'angular velocity' for example. Hence, from out 'real user' experience (engineering point of view) it would be a necessity to add 'angle' as a dimension without breaking already defined quantities. Most (all?) units libraries already define 'angle' to be dimensionless, which is true in scientifically spoken, but pragmatically (engineering ;-) less handy. There's another question. If we add angle as a dimension, then what kind of angle is it? There are several kinds of angles, such as radians (plane angle) and steradians (solid angle). If both were represented by the same angle dimension, then it probably wouldn't make much sense to add radians and steradians (and what would be the resulting quantity?), yet, the library would allow it. in our implementation (plane) angle is sufficient, so we don't bother with solid angle for the moment. However, I think it should have it's own dimension since steradian != radian^2 (although m^2/m^2 = (m/m)^2 ;-) but I think a unit library would reach a much broader audience if it allows to choose what dimensions are handled and how. For my application field it is necessary to incorporate everything related to robotics (time, length, angle, charge, mass), but temp, luminious intensity, amount of substance not really. I think it would be nice to be able to select only those you need in a unit lib and add your own dimensions if needed renej Regards, Terje ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] PP: The Order Programming for CPP Programming
Hi, I have now uploaded a prototype of the Order programming language interpreter to the files-section. Here is a link to the Order-folder: http://groups.yahoo.com/group/boost/files/Order/ Both the Order language and the prototype interpreter implementation still have many many rough edges and can be improved significantly in terms of both performance and expressivity. For the next two weeks I will be very busy with other work and will probably not have time to improve the interpreter. If there is sufficient interest in further development of the library, I will be happy to move it into the boost-sandbox. -Vesa _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
