[boost] Re: Metaprogramming question
John Maddock [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I'm trying to remember, did someone around here come up with some code that can tell at compiler time whether an object has a specific member or not, I can do it for operators, but not a member typedef (which is what I want)... I think this might help http://article.gmane.org/gmane.comp.lib.boost.devel/14119 but I could only do it with comeau back then. best regards Thorrsten ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: string conversion methods
It's only minor: But boost::filesystem and boost::date_time have string conversion methods such as string() native_file_string() to_simple_string() where as boost::format (and also stringstreams in the STL) have str() I don't know about the other libraries? Is there a standard for this in boost or is it up to the libraries? Should they be commonised? Ideally, yes. I would prefer .c_str() for const char* conversion and str() for std::string cheers Thorsten ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Any Interest in an Adapter for Sequences of Pointers?
Hi Alex,
There are many more possibilities beyond those described here. Does this
sound interesting to anyone
I don't have time to comment very thoroughly, but I can say that it does
sound
interesting. In the project I'm working on now I needed to sort the pointers
from
several containers which was not that hard.
// widgets_ and widget_ptrs_ get populated with some values
. . .
for (unsigned int i = 0; i widgets_.size(); ++i)
{
widget_ptrs_.push_back(widgets_[i]);
}
You can avoid your handcoded loop by something like
transform( ..., address_of );
of course you would have to resize the destination vector, but wouldn't you
do that
anyway to save some allocations?
What would have been nice was some kind of template that could generate
oprator, operator= etc
if there was a non-pointerversion of the class.
regards
Thorsten
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] random lib: Quasi-random generators
Hi, Have anyone involved in the random lib and its standardization considered a couple of quasi-random generators? I have recently heard of the fancy named quasi stuff which simply means that the numbers fill the range more uniformly than normal pseudo-random sequences. These sequences are important for Quasi Monte Carlo integration and for applications that need to destribute N samples uniformly in some way without knowing N in advance. regards Thorsten source: Numerical recipes in C++, second edition, p. 313ff ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: What is the status of Container algorithms in sandbox
Alisdair Meredith :
Hmmm, it looks like we are trying to achieve slightly different things.
From my perspective, the standard library works with semi-open ranges
and iterators. I am not trying to change that, merely make more
explicit when a pair of iterators in the parameter list form the bounds
of a range.
Can you ive some examples of this explicitness?.
This is clear when we look at algorithms that take a range for input and
an output iterator, eg transform. Where I see a range and an iterator,
your library tries to see two containers. I'm not entirely convinced
this is the way to go.
Neither am I. I think I'm actually for making the second arg. an iterator.
I originally thought it was good because one could do certain assertions on
the
size of two containers, e.g:
copy( const C1, C2 )
{
assert( size( C2 ) = size( C1 ) );
...
}
but we loose a lot of flexibility by only allowing the C2.begin() iterator
to be passed.
Likewise, for me a container is simply one form of range, but I can
imagine many others. Perhaps I should take a look at the Views
library? To phrase the library in terms of containers seems to limit
it, to me.
How would his range phrasing sound like?
Also, is there a background paper describing the motivation for this
library anywhere? I am currently making big assumptions about its
intent (you may have noticed!) so that might correct some of my
misconceptions :¬ )
there is no such paper, but I guess it would need to go into the
motivation section
of its stil-to-be-written documentation. But I'll summarize it as follows:
syntactic sugar, easier, shorter algorithm use
I'll make sure it is mentioned on Monday and see if we can drum up some
interest ;¬ )
great. :-)
I'll use a couple of minutes on changing the third second parameter to an
iterator.
regards
-Thorsten
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: What is the status of Container algorithms in sandbox
Also, is there a background paper describing the motivation for this library anywhere? I am currently making big assumptions about its intent (you may have noticed!) so that might correct some of my misconceptions :¬ ) when I come to think of it, it was also nice to be able to treat arrays, iterator pairs and stl containers alilke. -Thorsten ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: smart assert (was:ENFORCE/betterassertiontechnique)
Right! However, I think this would be a great feature (and a good name - BOOST_VERIFY) - to allow the same behaviour as ASSERT in release as well. What do you think? Do you think of a better name? how about just VERIFY() :-) -Thorsten ___ 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] Re: random and msvc6
Lapshin, Kirill [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]m01.gsp.gs.com...
Hi All,
[snip]
Thorsten, was the error you observed on intel 7 related to this one?
Unfortunately not. The program I'm trying to compile is this:
#include boost/random.hpp
#include ctime
using namespace boost;
using namespace std;
typedef lagged_fibonacci607 base_generator_type;
base_generator_type´generator( time( 0 ) );
uniform_01base_generator_type uni( generator );
Yesterday I actually gave up because the error was just too wierd:
apparently something as simple as a typedef and
a pointer to a class could not compile.
Since I saw your new mail, I gave it a try again and it turned out to be a
problem with templated constructors within
'lagged_fibonacci_01.hpp'.:
templateclass Generator
explicit lagged_fibonacci_01(Generator gen) { init_modulus();
seed(gen); }
I don't fully understand what the real cause for the error is; I've tried to
reconstruct the error without luck.
Anyway, I guess my local copy of the file will just have those two lines
commented out.
regards
Thorsten
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: exception context
Darren Cook [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [snip] I wanted something like the call stack that shows in python or java when an uncaught exception occurs; I tried to start a discussion on something similar, although I wanted language support. However, one of my points also were (and is) that it would be nice not only for uncaught exceptions, but also for running programs. My concern is that we have no standard mechanism for inspecting the errors in running programs when they (perhaps) have shipped to the customer. What is particularly irritating is that one instance of a program might work perfect whereas another instance may contain errors. If we cannot inspect those errors, we're in trouple if we cannot redo these errors . The entire thread can be found here: http://groups.google.com/groups?hl=dalr=ie=UTF-8selm=b1g8ca%2497i%241%40s unsite.dk regards Thorsten ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] random and intel v7
Hi, random and intels compiler v7 does not work together. Does anyone know what it would take to make it work? regards -Thorsten ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: random and intel v7
random and intels compiler v7 does not work together. Does anyone know what it would take to make it work? An active maintainer for the Boost.Random library ;-) I was more thinking about what compiler features that are prohibiting the intel compiler from working with the library. Since I'm not really an expert in random number theory, I cannot be a maintainer. Anyway, If somebody knows what's needed for a fix, but doesn't have time, I might give some of it a look (since I might need it for my ongoing project). regards Thorsten ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: how to avoid inclusions?
David Abrahams [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Thorsten Ottosen [EMAIL PROTECTED] writes:
my code does not include vector, list or map, but it does need
iterator.
Some of the functionality of the container_traits are shown here:
template typename C
bool is_container()
{
return boost::container_traitsC::is_container();
}
...
Yes, you can take an approach like this one, but it will cause false
positives in some circumstances. If that's acceptable for your
application, then it's a good answer.
I guess you're thinking about classes with eg. an iterator typedef.
Couldn't the procedure be improved a little by doing something
like
template typename C
true_t is_container( const C, const typename C::iterator =
typename C::iterator(),
const typename C::const_iterator = typename C::const_iterator(),
more of the same here );
That way we would reduce the likelyhood of false positives a lot. Or would
we?
regards
Thorsten
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: how to avoid inclusions?
Hereby at least a partial solution which so far works with gcc3.2 and comeau
4.3.0.1.
The complete source can be found in the sandbox :
boost-sandbox/libs/sequence_algo/test/container_traits.hpp
boost-sandbox/boost/sequence_algo/container_traits.hpp
my code does not include vector, list or map, but it does need
iterator.
Some of the functionality of the container_traits are shown here:
template typename C
bool is_container()
{
return boost::container_traitsC::is_container();
}
template typename C
bool is_sequence()
{
return boost::container_traitsC::is_sequence();
}
template typename C
bool is_contiguous_sequence()
{
return boost::container_traitsC::is_contiguous_sequence();
}
template typename C
bool is_associative()
{
return boost::container_traitsC::is_associative();
}
int main()
{
using namespace boost;
using namespace std;
typedef listint list_t;
typedef vectorint vector_t;
typedef mapint,int map_t;
assert( is_containervector_t() );
assert( is_sequencevector_t() );
assert( is_sequencelist_t() );
assert( !is_sequencemap_t() );
assert( is_contiguous_sequencevector_t() );
assert( !is_contiguous_sequencelist_t() );
assert( !is_contiguous_sequencemap_t() );
assert( is_associativemap_t() );
assert( !is_associativevector_t() );
assert( !is_associativelist_t() );
}
--
The implementation uses SFINAE and relys on some assumptions that I'm not a
100% sure about. The core of the implementation is this:
template typename C
true_t is_container( const C, const typename C::iterator =
typename C::iterator() );
template typename T, std::size_t sz
true_t is_container( const T ()[sz] );
false_t is_container( ... );
template typename C
true_t is_associative_container( const C,
const typename C::key_type =
typename C::key_type() );
false_t is_associative_container( ... );
template typename C
struct tag_generator
{
static C c;
BOOST_STATIC_CONSTANT( bool, is_container_ = sizeof( true_t )
== sizeof( is_container( c ) ) );
BOOST_STATIC_CONSTANT( bool, is_associative_container_ =
sizeof( true_t ) ==
sizeof( is_associative_container( c ) ) );
BOOST_STATIC_CONSTANT( bool, is_sequence_container_ =
is_container_
not is_associative_container_ );
enum { has_random_access_iterator_ =
::boost::is_same std::random_access_iterator_tag,
typename std::iterator_traits
typename container_traitsC::iterator
::iterator_category
::value };
BOOST_STATIC_CONSTANT( bool, is_contiguous_sequence_container_
= ::boost::is_arrayC::value ||
is_sequence_container_
has_random_access_iterator_ );
};
Comments are more than welcome.
regards
Thorsten
PS: How do you all use BOOST_STATIC_CONSTANT together with typetraits that
takes two parameters? As you can see I had to fall back on an enum.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: container algorithms almost complete
Alisdair Meredith [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Thorsten Ottosen wrote: 2. many standard algorithms take a single output iterator as an argument. Currently the argument for output must be a container. Should it be posible to specify an iterator here too? Absolutely! Not all iterators belong to containers eg ostream_iterator I see your point. Does anyone have a nice idea of how to detect when the template argument is an iterator? It's easy with pairs and arrays and the default case is containers. regards Thorsten ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: container algorithms almost complete
Dirk Gerrits [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Dirk Gerrits wrote:
Thorsten Ottosen wrote:
I see your point. Does anyone have a nice idea of how to detect when
the
template argument is an iterator? It's easy with pairs and arrays and
the
default case is containers.
Perhaps you can use Boost's concept check to see if the template
argument models the Input Iterator concept? That's the first thing that
came to mind, I haven't tried it out or anything.
On second thought, that won't work. Concept check causes a compilation
error when the argument does not conform to the concept.
Perhaps you can do it the other way around? Check for a T::begin member
function to see if the type is a container, and assume the type is an
iterator in the default case? I'm not sure what that check would look
like though.
I can't come up with any reason that it should be easier to detect a
container. Here's my initial attempt for iterators based on the assumption
that
all important iterators have derived from std::iterator:
template typename C, typename T, typename D,
typename P, typename R
true_t is_iterator( const std::iteratorC,T,D,P,R );
false_t is_iterator( ... );
template typename C
struct container_traits
{
private:
static C c;
BOOST_STATIC_CONSTANT( bool, is_iterator =
sizeof( detail::container::is_iterator( c ) )
== sizeof( detail::container::true_t ) );
};
but it doesn't seem to work for eg. an ostream iterator. Does anyone know if
the binding in is_iterator is possible with all these templates involved?
regards
Thorsten
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: container algorithms almost complete
David Abrahams [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Thorsten Ottosen [EMAIL PROTECTED] writes: I see your point. Does anyone have a nice idea of how to detect when the template argument is an iterator? Sadly, there is no reliable way. The closest thing I can imagine is to use SFINAE to check that iterator_traitsT has valid types, and that the types are consistent with the iterator requirements. I imagine that will be rather non-portable (Comeau and ?). This seems to work for como, gcc3.2, vc7: template typename C, typename T, typename D, typename P, typename R true_t is_iterator( const std::iteratorC,T,D,P,R ); template typename C true_t is_iterator( const std::back_insert_iteratorC ); template typename C true_t is_iterator( const std::front_insert_iteratorC ); template typename C true_t is_iterator( const std::insert_iteratorC ); template typename T, typename C, typename Tr true_t is_iterator( const std::istream_iteratorT,C,Tr ); template typename T, typename C, typename Tr true_t is_iterator( const std::ostream_iteratorT,C,Tr ); template typename C, typename Tr true_t is_iterator( const std::istreambuf_iteratorC,Tr ); template typename C, typename Tr true_t is_iterator( const std::ostreambuf_iteratorC,Tr ); false_t is_iterator( ... ); but I'm wondering if that is enough. Can anybody come up with some cases which will fail here and which is important? regards Thorsten ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Repost: Lock Classes
First I want to say that I'm not experienced with multitherading, but I would like to see a standard lib to solve these situations. A small question about enforcing correct parameter passing: you have these typedefs : // These locks should never be passed by value to functions. // Instead use the following typedef to pass by reference: typedef const LockOnlyWillOnlyLock; typedef const LockWillLock; typedef const UnlockOnly WillOnlyUnlock; typedef const Unlock WillUnlock; Is this the best way to enforce this? Why not just make lock objects noncopyable? ragards Thorsten ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: How to convert a template parameter into a string
Dirk Gerrits [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
[snip]
At what cost? The strings you generate are indeed very readable, but
specializing spelling for every type that might be a template parameter
someday seems like too much of a burden to me.
Others might disagree though...
I think that is a problem too. Maybe a macro could make things easier:
#define DECLARE_SPELLABLE( a_type ) \
template class spellinga_type { public: static const std::string
result; }; \
const std::string spellingmy_enum::result = #a_type
but this should be preferrable be put in headers, so why not make the static
data into a function instead?
Like this:
template typename T
class spelling
{
public:
const string result() const
{
static const string res = ..;
return res;
}
};
And the macro could be changed accordingly.
regards
Thorsten
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Repost: Lock Classes
Kevin Atkinson [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Sat, 1 Mar 2003, Thorsten Ottosen wrote: First I want to say that I'm not experienced with multitherading, but I would like to see a standard lib to solve these situations. A small question about enforcing correct parameter passing: you have these typedefs : // These locks should never be passed by value to functions. // Instead use the following typedef to pass by reference: typedef const LockOnlyWillOnlyLock; typedef const LockWillLock; typedef const UnlockOnly WillOnlyUnlock; typedef const Unlock WillUnlock; Is this the best way to enforce this? Why not just make lock objects noncopyable? Um, they are. This typedef are strictly for convenience and readability. what convenience and what readability? C++ programmers are use to const XX parameters. Having four extra names makes the concept harder to understand. regards Thorsten ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] container algorithms almost complete
Hi Boosters,
The container algorithms are almost finished (at least for complient
compilers). This means we can do the following for all standard algorithms:
int array[] = { };
std::pairiterator,iterator = ...;
vector v = ;
std::copy( one_of_the_three_containers, one_of_the_containers );
All the conde is in the sandbox in
boost/sequence_algo/(container_traits.hpp|container_algo.hpp)
libs/sequence_algo/test/container_algo.cpp
So I would like to get some feedback on these issues:
1. by overloading some names raises ambiguity. The obvious solution is to
change the name of the algorithm slightly. Currently I have
put those algorithms in an extra namespace ext. Another possibility
was to add an underscore.
2. many standard algorithms take a single output iterator as an argument.
Currently the argument for output must be a container. Should
it be posible to specify an iterator here too?
3. What kind of documentation would be appropriate for this library? I
imagine a very short one.
4. The code implement poor mans partial specialization to enable the
container_traits to work with buggy compilers; so far so good; however,
many compilers cannot even do partial ordering of function templates
which is a real pain in the . I know the workaround might be
to say
template typename C
inline typename
container_traitsC::iterator
begin( C c )
{
return container_traitsC::function_t::begin( c );
}
instead of
template typename C
inline typename
container_traitsC::iterator
begin( C c )
{
return container_traitsC::function_t::begin( c );
}
template typename C
inline typename
container_traitsC::const_iterator
begin( const C c )
{
return container_traitsC::function_t::begin( c );
}
but C can be a huge STL container. Can we assume compilers will inline code
and not copy anything?
5. Should the small boost extensions like iota etc be included with this
realease as well?
regards
Thorsten
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Minor problem with random::lognormal_distribution
Michael Stevens [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
There is a small correction required for lognormal_distribution.
The problem is flagged under GCC3.2
explicit lognormal_distribution(base_type rng,
result_type mean = result_type(1),
result_type sigma = result_type(1))
...
RealType mean() const { return _mean; }
RealType sigma() const { return _sigma; }
should probably read.
RealType mean() const { return _mean; }
RealType sigma() const { return _sigma; }
And while we're at it, we shouldn't use leeding underscores on variables;
these are reserved to the compiler.
regards
Thorsten
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: proposal: safe arithmetic class
[EMAIL PROTECTED] wrote in message 3D8559AE95B4D611B02C0002557C6C8B3C45CF@STH-EXCH">news:3D8559AE95B4D611B02C0002557C6C8B3C45CF@STH-EXCH... [snip] 1) Controlled numeric type promotion and conversion This would be needed for safe(r) expressions; the rules for integral promotions, floating point promotions, integral conversions, floating integral conversions, and the usual arithmetic conversions, would be encoded explicitly in types or implicitly in expressions. Unary and binary expressions are handled to produce the correct resulting type; conversions that would lead to loss of precision or range are invalidated, either at compile time or runtime. It is probably a nontrivial task to find consensus on what to allow; for example, should the special rules for unsigned arithmetic be prohibited or not? [No expression templates required here either, but could potentially simplify and add functionality to the implementation.] Example: Int i=std::numeric_limitsint::max(); Short s=7; UShort us=i+s; // i+s results in a type equivalent to unsigned int, and us is assigned the least unsigned integer // congruent to the source integer (modulo 2n where n is the number of bits used to represent the unsigned type) // , i.e. it wraps around. Should this be legal for this safe type? My personal view would be that it should throw an exception. 2) Complex expression conversion and promotion control If the aforementioned mechanisms for controlling conversions and promotions exist, there is still the matter of more complex arithmetic, involving intermediate steps. This is where the expression templates need to enter the arena, because we can no longer simply evaluate the binary operations; we must consider the expression as a whole. If we don't, seemingly equivalent expressions will be treated differently (just as is the case with built-ins): int x=100; int y=100; int z=100; int r=x*y/z; // Probably a negative number, implementation-defined. safe_numeric throws an exception if all variables are safe_numeric. r=x/z*y; // 100. safe_numeric doesn't throw an exception. As far as possible, a safe numeric is a type that never lead the user into implementation defined behavior. For most of my programs I wouldn't worry about if it meant a slower type; program correctness should be the only concern. I don't think all of the above was the intent of your proposal though? no it wasn't. Of course, I also wanted a discussion because it is often not as trivial as I tend to think. (And also, there might be value in a partial solution for detecting errors/problems/strange results at runtime) The three problems stated above seem to have great potential for solutions through class libraries (and unlimited precision types, where art thou?), and my point has been (and is) that 0) is already covered by numeric_cast, and might not need another solution; the others remain open. I think it might be hard to say if we need three levels of granularity. Anyway, the important thing is that there could be a need for more control of implicit conversions/undefined behavior. As I understand, there have been a proposal to include a recent C-standard header which defines int8_t, int32_t types (which are guarenteed to have the proclaimed size) into C++ too. Maybe these types could be defined with additional safety guarantees in C++ so we could avoid adding too many new names (it might be a bad idea if C programs compiled with a C++ compiler must have the same semantics). regards Thorsten ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: proposal: safe arithmetic class
[EMAIL PROTECTED] wrote in message 3D8559AE95B4D611B02C0002557C6C8B3C45C1@STH-EXCH">news:3D8559AE95B4D611B02C0002557C6C8B3C45C1@STH-EXCH... [snip] I might also be beneficial when you are chaning a variable from one type to another; the change might cause conversion problems some different place in the code and/or require numeric_cast to be inserted. By using wrappers this would be detected. True, but the price of this detection is using wrappers everywhere, which defeats the purpose, IMO; how should a maintainer know which parts of the code contains potential conversion issues when *all* of the code is implying that is the case? I could also imagine a syntax like this: Double d = ...; ... Int i = d.toInt(); That way you can explicitly see where you're requesting narrowing conversion. regards Thorsten ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: proposal: safe arithmetic class
[EMAIL PROTECTED] wrote in message
3D8559AE95B4D611B02C0002557C6C8B3C45CC@STH-EXCH">news:3D8559AE95B4D611B02C0002557C6C8B3C45CC@STH-EXCH...
From: David Abrahams [mailto:[EMAIL PROTECTED]]
The huge advantage appears when you start looking at arithmetic
expressions. The result of
if (t u)
{
x = y + z * w;
}
could be a lot more predictable if we were working with types that
didn't perform implicit lossy conversions.
In some cases, sure. But without some exceptionally creative use of
expression templates, you'd have a situation where the ordering of
variables
determine the validity of the expression
Sorry for not understanding why exceptionally creative use of expression
templates is necessary :-) Could you
elaborate a little on it?
regards
Thorsten
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: proposal: safe arithmetic class
[EMAIL PROTECTED] wrote in message 3D8559AE95B4D611B02C0002557C6C8B3C45BF@STH-EXCH">news:3D8559AE95B4D611B02C0002557C6C8B3C45BF@STH-EXCH... From: Thorsten Ottosen [mailto:[EMAIL PROTECTED]] Hi Boosters, I was wondering if it would be possible to implement a wrapper around built-in types to provide automatic detection of conversion problems: [snip] What would the advantage be over using boost::numeric_cast directly, and thus explicitly? Using these wrappers, it wouldn't be obvious that there are numeric_casts involved (implying possible failure [and therefore try/catch blocks for bad_numeric_cast]). you would't have to worry about if you forgot a numeric_cast somewhere in your code or if you compiled on a platform with different ranges for built-ins which suddenly could make conversion problems appear. As I see it, automatic detection of conversion problems wouldn't buy much unless it could also remedy the problem. that depends on what the problem is. I would say that an _undetected_ false conversion is the biggest problem. Doing it manually, and acknowledging the potential problem by using numeric_cast is (in addition to ensuring correct behavior) self-documenting, a property that I think is rather important. by using a wrapper, you also acknowledge a potential problem. I might also be beneficial when you are chaning a variable from one type to another; the change might cause conversion problems some different place in the code and/or require numeric_cast to be inserted. By using wrappers this would be detected. regards Thorsten ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: [multiarray] compiling problem
[EMAIL PROTECTED] wrote in message 3D8559AE95B4D611B02C0002557C6C8B3C459F@STH-EXCH">news:3D8559AE95B4D611B02C0002557C6C8B3C459F@STH-EXCH... And when creating patches, it's always a good idea to check that one's favorite editor hasn't inserted tabs or changed the line endings (the latter is the case with the submitted multi_array files). sorry for that. Additionally, creating patches using the latest files from CVS makes them very easy to apply. if one have cvs access, I pressume :-) -Thorsten ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [multiarray] compiling problem
David Abrahams [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Thorsten Ottosen [EMAIL PROTECTED] writes: When I just try include boost/multi_array.hpp I get these errors: Comeau C/C++ 4.3.0.1 (Aug 21 2002 15:45:32) for MS_WINDOWS_x86 Copyright 1988-2002 Comeau Computing. All rights reserved. MODE:strict warnings C++ E:\C++\libraries\boost_1_29_0\boost/multi_array/subarray.hpp, line 238: error #20: identifier num_dimensions is undefined assert(other.num_dimensions() == num_dimensions()); ^ Try this- instead: assert(other.num_dimensions() == this-num_dimensions()); E:\C++\libraries\boost_1_29_0\boost/multi_array/subarray.hpp, line 239: error #20: identifier shape is undefined assert(std::equal(other.shape(),other.shape()+num_dimensions(), ^ Likewise. yep. it needs a _big_ bunch of 'this-' to compile. Is Comeau really wrong? Who will make the changes? I guess I can't do it since I only have access to the sandbox regarsd Thorsten ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: [multiarray] compiling problem
Why not do it and post a patch here? done. That's not a patch; those are the complete files. However, I'm sure Ron can work with those. If he doesn't respond in the next week, Bjorn (the maintenance wizard) will get on his case. So what is a patch? regards Thorsten ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: status of array_traits?
Ronald Garcia [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... IIRC, the array_traits library was pulled off of the boost main page and moved into the sandbox a while ago. What is its current status? Is being actively developed or is it currently in stasis? I recently looked into the array_traits because I needed it for the container algorithms if they should work for built.in arrays too. However, after a long time I came to the conclusion that they will never work on non-conforming compilers like vc6/7. The problem is simply the inability to deduce the array size by this overload: template typename T, int sz void foo( T (a) [sz] ); If somebody knows how to remedy this, it would enable array_traits for those compilers. regards Thorsten ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: spirit and compile speed
Vincent Finn [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Hi, I assume this is the right place to post questions on Spirit now that it is part of boost! If not here, where? My question is about compile speed. Is there any way to speed it up or at least seperate it from the project? I have added 2 parsers to my code base and the compile time (VC6) has gone from 10 mins to 30mins :-( I love Spirit for its syntax and ease of use, but I must also admit that compile times are´ very long, even for debug builds. I think I read something about a debug mode in uBLAS which was used to reduce compilation time; Could something similar be done in Spirit? regards Thorsten Ottosen ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: intrusive tagging allows omision of unneeded headers
- Original Message -
From: Dirk Gerrits [EMAIL PROTECTED]
To: Boost mailing list [EMAIL PROTECTED]
Sent: Wednesday, January 08, 2003 6:15 PM
Subject: [boost] Re: intrusive tagging allows omision of unneeded headers
Thorsten Ottosen wrote:
[snip]
class X
{
public:
class tag {};
typedef tag X_tag;
^
};
class bar
{
public:
class tag {};
typedef tag bar_tag;
^^^
};
Why these typedefs? Why would one write X::X_tag instead of X::tag for
example?
how can we specifiy that we want to specialize for a particular class
otherwise? Only by establising a convetion
that all (involved) classes have a unique typedef can we destinguish the
classes. For example
template typename C
void foo_impl( const C c, typename C::bar_tag )
{
cout bar specialised version endl;
}
will only be a candidate when C actually has a typedef bar_tag. due to
SFINAE the instantiation is allowed
to fail for classes that does not have a bar_tag typdef. And because the
above foo_impl is more specialized
than
template typename C, typename Tag
void foo_impl( const C c, Tag t )
{
cout default version endl;
}
the first foo_impl will be chosen as a better match.
regards
Thorsten
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] possible error in documentation of call traits
In note #3 it says that param_type requires partial specialization; however, it seems to work fine with vc7. Does it mean that param_type defaults to const T if partial specialisation is not available? Thorsten Ottosen ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Math constants - (in-)Formal Review?
9 Users extremely strongly prefer to write float area = pi * r * r;
10 There is evidence that some compilers can generate better code from
functions like
double pi() { return 3.1459;}
but that this implies writing pi() instead of plain long double pi.
So the ()s remain the main issue.
Why won't this work:
struct Pi_impl
{
operator float() const
{ return 3.14...; }
operator double() const
{ return 3.14.; };
operator long double() const
{ return 3.14..;}
};
namespace boost
{
const Pi_impl pi;
}
?
Thorsten Ottosen, AAU
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: implicit_cast inventor
Hmm... a lot of energy wasted on whether to use he or she. So lets waste some more time... Here in Denmark the correct way to refer to a person (of both genders) in a representative sense is simply he. Nobody is foolish enough to think its literally a man. So if the persons gender is unknown, simply use he. It's just a convention, but until there is some good reason to change it (and there isn't, BTW) it should stay that way. Now, the most used form is however the incorrect version where the author says he or she or some the first, sometimes the last. The result is that the language has lost its elegantness and consistency; it will at best make confusion. I guess you Englishmen (and all you other folks) have seen the appearence of this kind of language misuse. In Denmark anyway, it started as some kind of women's liberation thing and people we're stupid enough to think it was unpolite not to say or she. Those people complete forgot the negative uses: ...and when the killer/terrorist he or she ... It doesn't really make sense to go away from using the word he as representative and gender neutral. Thorsten Ottosen, AAU [EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Sockets
- Original Message - From: Hugo Duncan [EMAIL PROTECTED] discussions, I have tried to start describing a design at: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket When I look at the examples I'm curious why I see this: socket_base::initialise(); ... socket.close(); socket_base::finalise(); Why doesn't this happen in the constructor/destructor of some object? regards Thorsten Ottosen, AAU ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: new initialization lib, any interest?
- Original Message - From: Rob Stewart [EMAIL PROTECTED] From: Thorsten Ottosen [EMAIL PROTECTED] From: Yitzhak Sapir [EMAIL PROTECTED] On Wed, 9 Oct 2002, Thorsten Ottosen wrote: The problem of missing a value in the assignment to the map is hypothetical. If I wan't to map int to int, I can make the No, it isn't hypothetical. It is a reasonable situation to map from one numeric type to another, and to use integers for the initial values even when assigning to a floating point type. It was hypothetical that the missing value should be a problem, not that maps from 'int' to 'int' are. If you fordot a value, an assertion will be triggered. mapping just as clear by using newline or tabs: set_map( m ) += 1,22,33,45,6; set_map( m ) += 1,2 2,3 3,4; As you can see, tabs can be a problem. At least in mailing lists! ;-) Given that you yourself did not do well in giving an example of separation with whitespace, I think this speaks strongly for a pair-wise syntax. I agree. [snip] Your point, if I understand you correctly, is that the compiler would have complained had you been able to actually attempt to compile the above with a more compliant compiler. no, if I had compiled it at all. No compiler accepts white spaces in identifiers. The parenthesis form is not that hard. Add a space between the values and the parenthesis, and the value isn't buried: init(m)( 1, 2 )( 2, 3 )( 3, 4 ); I don't put spaces within parenthetical expressions, so I'm accustomed to code like this: init(m)(1, 2)(2, 3)(3, 4); I find that perfectly readable. You could then also quickly be accustomed to code like m+= 1,2, 3,4; I don't think we're discussing anything that has to do with ambiguity, simple people's personal preferences for a certain syntax. I think I mentioned in a mail that one could choose to support both syntaxes, but I'm not sure that is a good idea. In this case white space does enhance readability, but the syntax guarantees the user won't make a mistake. I find the spaces distracting, but since they are not required, but merely possible should your own sense of taste dictate them, I have no problem either way. good. :-) neither will he in the other case. ¨The concern is hypothetical and the interface for map and eg vector will be different which is much worse than having both operator= and operator+=. The concern is not hypothetical. If you have a std::mapint, double, you could easily initialize it with only pairs of integers, and the compiler will be happy to convert integers to doubles for you. How can you find an error if the compiler doesn't flag it? How will you learn that you transposed a 2 and a 3 in such a case? It depends upon how that transposition affects the rest of your code. It may be invisible in most circumstances. My imagination is just not good enough, please show an example with both syntaxes and pinpoint where the error appears. Couldn't you use map-like notation: init(m)[ssdsd] = Class(2, Cow(3)), [dfedfe] = Class(2, Cow(3)); The idea is that init(m) would create an object that provides the subscript operator which takes the map's key type as a parameter and returns an object with an assignment operator which takes the map's value type as a parameter. The assignment operator would return the original init object. The init class provides the comma operator to allow chaining as shown. (Add whitespace to taste: init(m) [ssdsd] = Class(2, Cow(3)), [dfedfe] = Class(2, Cow(3)); ) What could be more intuitive? init(m) [sdsds] - Class( 2, Cow(3)); (Efficiency may be another matter, but it's intuitive, right?) yes. might not be such a bad idea. In your case, whitespace might add something, but the user can still make a mistake. Even something like: set_map(m) += 1,2, 2,3, 3,4, 5,6, 7,8, | 9, 9,10, 11,12, 13,14, 15,16 17,18 19,20; With the user screen margin occuring where the | passes is possible. In this case, white space doesn't save him from this mistake. And it could be hard to find. no. as I said earlier, a missing value will be caught at bug-time (~the first time the user runs the code). You're assuming the code path containing that initialization code will always run. What if the situation leading to that code path wasn't tested? That may not bode well for the testing methodology, but the point is that a compile time error is better. I cannot imagine a situation where constant data in a program has not been tested. I agree compile errors are better, but if it means you ruin the interface, it might not be worth it. regards Thorsten ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: String algorithm library
- Original Message - From: James Curran/MVP [EMAIL PROTECTED] While there is a certain elegance to the names, I'd have to vote against those. It's not immediately obvious from the names trim/trimmed which one is inplace and which isn't. well, I would say it is. verbs in the imperative donote mutation, adjectives denote copy. Further, in the matter of lower_cased/to_lower_case, if you guess wrong, the other one isn't nearby in an alphabetic listing of functions. remove or add to_ from one of them? regards Thorsten, AAU ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] minor scoped_ptr/scoped_array feature request
- Original Message - From: Peter Dimov [EMAIL PROTECTED] From: Thorsten Ottosen [EMAIL PROTECTED] From: Peter Dimov [EMAIL PROTECTED] [nip] In general, it is recommended practice to always assert() preconditions in client code, instead of relying on in-library asserts. First, the library is not required to have asserts, and second, the earlier you catch precondition violations, the better (call stacks aren't universally available). I don't get this. It's a poor library if it does not even check its own preconditions in eg. debug mode. Moreover, if you put the precondition in the library, you take the burden away from the client; this is highly recommeded since it encapsulates commen code _one_ place, not O(n) places! Note that recommended practice in my statement above means recommended for library users. When you say highly recommended you mean recommended for library writers. Yes, but note that having both is less fortunate. Either we agree that library writers check preconditions and then clients don't or we agree that clients check preconditions and library writers don't. One reason that C is such a pain in the *** to use is because its the cliets responsibility to check conditions , e.g. int * i = malloc( sizeof( i ) ); assert( i ); Libraries should always check as much as possible. regards Thorsten, AAU ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] String algorithm library
- Original Message -
From: Pavol Droba [EMAIL PROTECTED]
On Fri, Nov 15, 2002 at 06:47:35PM +0100, Thorsten Ottosen wrote:
I would find it more naturally to say
string s = ...;
trim( s );
than to use 'trim_in()'.
[snip]
Well I have reasons to put it in the way I did. Rationale was to allow
usage of the
functions in fuctional way. I consider it quite natural to write something
like
if ( to_lower(trim(s)) == OK )
{
// do somethign with original s
}
There are many cases like this in which you probably don't want modify
input sequence.
So in the functional approach when you usualy stack multiple
transformation in one line
especialy in conditions. When expression gets complicated it could be
quite anoying and
less readable to use variants with suffix of prefix.
Perhaps one could use these names then:
Seq trimmed(...);
void trim(...);
Seq trim( const Seq Input, const std::locale Loc=std::locale() )
Seq trim_in( Seq Input, const std::locale Loc=std::locale() )
and
Seq lower_cased(...);
void to_lower_case(...);
Seq upper_cased(...);
void to_upper_case(...);
Seq tolower( const Seq Input, const std::locale Loc=std::locale() )
Seq tolower_in( Seq Input, const std::locale Loc=std::locale() )
Seq toupper( const Seq Input, const std::locale Loc=std::locale() )
Seq toupper_in( Seq Input, const std::locale Loc=std::locale() )
Your example would become
if ( lower_cased( trimmed( s ) ) = ok )
maybe the suffix _in is not the best, and i'm open to any suggestions, but
I like you to
consider my reasons to keep non-modifying variants as default.
Of course, just consider them suggestions :-)
What is relevant here is that the code below does not call
.begin()/.end(),
but overloaded
freestanding begin() / end() functions. If your code should work with
char
arrays or iterator ranges,
then you could benefit from the container algo. begin/end functions
approach. However, there is a big problem, namely that
the container algorithms don't work on eg. VC6/7.
This sounds interesting. I have seen your library in the sandbox, and I've
even
written a mail to Jeremy who I thought is a co-author of the lib.
He is. But he's pretty busy (aren't we all?). Anyway, it was Jeremy's idea
to
use free standing functions s.t. pairs of iterators could be used and he
laid the basic
tagging mechanism. The free-standing functions also made array support
possible (which will make builtin arrays a _lot_
more useful), so I added that and implemented most of the algorithmic stuff
and a
1000+ lines of test. We still need concept checks and some assertions, but
it has to way till
the traits are running on more platforms.
I'm open to any ideas, but I consider compatibility with compiler like
VC6/7
as an important issue. But I coudl be possible to #ifdef sensitible code
and
keep at least the core of the lib to be usable for everyone.
It would be nice If you can provide me with more details about your work.
As I see it, the free standing begin()/end() stuff would be beneficial to
you, and perhaps
many others. Let's assume that they we're working. Then you would implement
the iterator range version of the algorithms (as you already did) and the
forwarding
in the container versions would use the free-standing begin()/end() and you
would automatically
get support for pair of iterators and arrays too.
I guess we could just make some defines at present s.t. you could use
begin/end in your code
and on compilers with enough support one would be able to use everything.
In that case I guess the traits should be moved to a seperate header, to
make it more appropriate
for different libraries to use it. BTW, the array_traits was written a long
time ago by Dietmar Kuehl.
Anyway, I think the main problem is this statement:
template typename T, size_t
struct some_traits;
template typename T, size_t sz
struct some_traits T[sz] ; // bad bad bad on vc6/7
Unfortunately I don't know a workaround :-(.
regards
--Thorsten
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
