Re: [boost] PP lambda?
Paul Mensonides wrote: > Joel de Guzman wrote: > >> Looks good. But why not overload the name "namespace" in as much >> as the CPP overloads #if #else ? I think the syntax should give a >> nice feeling since it is already looks like something C++ >> programmers are >> already accustomed to: > >> Either way, any syntax will do as long as it works :) If you really >> want to go the import/export route, consider a modula-2-ish syntax: > > I actual names of the directives I don't really care about. > #region/#endreg, #scope/#endscope, #module/#endmodule are all fine > with me. I don't personally like #namespace/#endnamespace, but I > could live with it. What I want (and what we need) is the more > general mechanism allowing named scopes. My proposal, including > import/export, would allow both the current model and the more > general model. Yes It's the bicycle shed... again :-) Whichever will do. I do think that the modula-ish export/import is nice. Modula-2's module mechanism is already very mature so I guess if it's based on it, we are on the right track. Now that there's Wave, I guess there's no harm and we can start experimenting on this. Regards, -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] PP lambda?
Joel de Guzman wrote: > Looks good. But why not overload the name "namespace" in as much > as the CPP overloads #if #else ? I think the syntax should give a nice > feeling since it is already looks like something C++ programmers are > already accustomed to: > Either way, any syntax will do as long as it works :) If you really > want to go the import/export route, consider a modula-2-ish syntax: I actual names of the directives I don't really care about. #region/#endreg, #scope/#endscope, #module/#endmodule are all fine with me. I don't personally like #namespace/#endnamespace, but I could live with it. What I want (and what we need) is the more general mechanism allowing named scopes. My proposal, including import/export, would allow both the current model and the more general model. Paul Mensonides ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] PP lambda?
Paul Mensonides wrote: > Joel de Guzman wrote: > >> Hmmm how about namespaces (or modules) ? :o)... >> >> #< BOOST_PP // boost PP namespace >> // blah blah blah >> #> >> >> #< MY_MODULE // my module namespace >> #using BOOST_PP // using boost PP namespace >> // blah blah blah >> #> > > Hi Joel, I'm already in the process of writing a paper with an > alternative version of the above. Problem #1: the operator > directives are evil. They are not visible, and with serve to make > code that includes them hard to read. We need a named alternative at > least. Problem #2: No true scoping is achieved: > > #< > #define DETAIL 123 > #define INTERFACE DETAIL > #export INTERFACE > #> > > INTERFACE // ? Well, I can't speak for the evolution group of WG21 & J16 so you should probably ask them. > This is what I'm going to propose: > > # region // unnamed > #import ABC > #define XYZ > #define INTERFACE 123 > #export INTERFACE > # endreg > > XYZ // XYZ > INTERFACE // 123 > > # region BOOST > #region DETAIL > #define ABC 123 > #endreg > #define INTERFACE BOOST::DETAIL::ABC > #define OTHER 123 > #export OTHER > #region A > #define MACRO 123 > #endref > #region B > #define MACRO 123 > #endif > #export A > # endreg > > ABC // ABC > DETAIL::ABC // DETAIL::ABC > BOOST::INTERFACE // 123 > OTHER// 123 > > A::MACRO // 123 > B::MACRO // B::MACRO > > What do you think? Looks good. But why not overload the name "namespace" in as much as the CPP overloads #if #else ? I think the syntax should give a nice feeling since it is already looks like something C++ programmers are already accustomed to: # namespace // unnamed // blah blah blah # endnamespace # namespace BOOST // blah blah blah # endnamespace Either way, any syntax will do as long as it works :) If you really want to go the import/export route, consider a modula-2-ish syntax: # module BOOST # import ABC # define INTERFACE 123 # export INTERFACE # endmodule -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] PP lambda?
Joel de Guzman wrote: > Hmmm how about namespaces (or modules) ? :o)... > > #< BOOST_PP // boost PP namespace > // blah blah blah > #> > > #< MY_MODULE // my module namespace > #using BOOST_PP // using boost PP namespace > // blah blah blah > #> Hi Joel, I'm already in the process of writing a paper with an alternative version of the above. Problem #1: the operator directives are evil. They are not visible, and with serve to make code that includes them hard to read. We need a named alternative at least. Problem #2: No true scoping is achieved: #< #define DETAIL 123 #define INTERFACE DETAIL #export INTERFACE #> INTERFACE // ? This is what I'm going to propose: # region // unnamed #import ABC #define XYZ #define INTERFACE 123 #export INTERFACE # endreg XYZ // XYZ INTERFACE // 123 # region BOOST #region DETAIL #define ABC 123 #endreg #define INTERFACE BOOST::DETAIL::ABC #define OTHER 123 #export OTHER #region A #define MACRO 123 #endref #region B #define MACRO 123 #endif #export A # endreg ABC // ABC DETAIL::ABC // DETAIL::ABC BOOST::INTERFACE // 123 OTHER// 123 A::MACRO // 123 B::MACRO // B::MACRO What do you think? Paul Mensonides ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] PP lambda?
Paul Mensonides wrote: > Joel de Guzman wrote: > >>> And that takes all the fun out of it. pp-metaprogramming and indeed >>> template metaprogramming, given the current language, is all about >>> _manipulation_ of the language. If you take that away, it is still >>> very useful, but not as "creative", therefore, not as fun. ;) >> >> It would be nice to experiment on new features such as scopes >> and true iteration. I think it is also a good idea to *push* the >> CPP specifications with the future in mind. > > A scoping mechanism is already in being considered (FYI, precisely > because it > *limits* the preprocessor). Scope, IMO, should be the first priority. For one, I would certainly wish to see the BOOST_PP prefix a thing of the past. I always get a mild headache trying to grok Boost.PP expressions. ... Here's a possible syntax (quoted from CLC++M). I'm sure many of you are already aware of this, nevertheless... Francis Glassborow wrote: > In message <[EMAIL PROTECTED]>, James > Kanze <[EMAIL PROTECTED]> writes >> And although it might sound a bit heretical -- the lack of a >> preprocessor, or any other means, of making logging and tracing as >> simple as possible. > > Not heretical these days. We spent time earlier this week in the > evolution group of WG21 & J16 considering ways to take control of the > pre-processor to make it work well in C++. Our current thinking is to > add something like: > > #< // no preprocessor macros can permeate this barrier > // unless explicitly asked for > > #import XYZ // allow that macro through > #define ABC 123 > #define FALSE 0 > ... > #export FALSE > #> // only explicitly exported macros escape > > IOWs create a mechanism to control the scope of pre-processor macros. Hmmm how about namespaces (or modules) ? :o)... #< BOOST_PP // boost PP namespace // blah blah blah #> #< MY_MODULE // my module namespace #using BOOST_PP // using boost PP namespace // blah blah blah #> Regards, -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Quantity library: any interest?
I would say there is. But how do your work compare with SIunits? http://www.fnal.gov/docs/working-groups/fpcltf/Pkg/SIunits/doc/0SIunits.html best regards Thorsten ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Quantity library: any interest?
I wrote Quantity library some time ago and wonder whether it may get added
into Conversion library. If anyone gets interested I will Boostify and
submit it.
Quantity library is used to get safe conversions between different physical
units (like between Celsius and Farhernheit degrees). Instead of bare number
you have specific type and conversion rules are applied automatically.
Example:
typedef struct { float value; } speed_km_per_hour_t;
typedef Quantity
<
float, // numeric type to represent speed in meter/sec
speed_km_per_hour// alternative representation
> speed_meters_per_sec_t;
// conversion rule: define them when it makes sense
void convert_quantity(const speed_meters_per_sec_t& from,
speed_km_per_hour_t& to)
{
to.value = from.value * 3.6;
}
int main()
{
speed_meters_per_sec_t m_p_s(10);
speed_km_per_hour_tkm_p_h;
km_p_h = m_p_s;// OK
// m_p_s = km_p_h; ERROR - this conversion is not defined
km_p_h = static_cast(m_p_s); // OK
}
You can manipulate Quantity value like any other value (add, multiply,
compare), you may add e.g. 1 inch to value of 2.1 meters. This library
helps to avoid really hard to track down conversion errors.
Some conversions may not be needed: e.g. $1.5 money may be converted to
string "one dollar, fifty cents" but not vice versa. Unimplemented and used
conversions result in (relatively) readable linker error.
Ability e.g. to divide length quantity by time quantity and get speed
quantity may be added into the library.
The library is simple and uses Boost.Preprocessor to emulate variable number
of template parameters.
-
Shortened snippet of implementation:
template
class Quantity
{
public:
Quantity() {}
Quantity(const Quantity& other) : value(other.value) {}
Quantity(const MainType& val) : value(val) {}
Quantity(const OtherType1& val) { convert_quantity(val, *this); }
~Quantity() {}
Quantity& operator=(const Quantity& other) { value = other.value; return
*this; }
Quantity& operator=(const MainType& other) { value = other; return
this*; }
Quantity& operator=(const OtherType1& other) { convert_quantity(other,
*this); return *this; }
operator MainType() { return value; }
operator OtherType1() { OtherType1 result; convert_quantity(*this,
result); return result; }
// operators like ==, /, * etc. not shown here
MainType value;
};
-
Name and inspiration was taken from Martin Fowler's article
http://www.martinfowler.com/ap2/quantity.html.
/Pavel
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [mpl]gcc and bcc link errors
Aleksey Gurtovoy wrote: > 'int_' (and other integral constant wrappers) needs to provide a definition > for its '::value' member for the > !defined(BOOST_NO_INCLASS_MEMBER_INITIALIZATION) case. > > I will fix it in a few days. Done in the main trunk now. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
