[boost] Re: Proposal: static_string library
Robert Klarer wrote: The syntax for declaring a static_string is unfortunate, but once it has been declared, a static_string's interface is (almost*) the same as that of a const std::string. Yes, you right it's unfortunate and IMHO is not appropriate for a wide use. typedef boost::static_string's', 't', 'a', 't', 'i', 'c', '_' StrType1; This syntax may be good for some specific (and not widely used) tasks such as building hashing algorithm at compile-time for a given set of static strings but not for normal strings. I beveive it's better to wait for a new compiler which can optimize dynamic memory allocations (a possibly even more) away. -- Alexander Nasonov Remove minus and all between minus and at from my e-mail for timely response ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Proposal: static_string library
Robert Klarer wrote: The syntax for declaring a static_string is unfortunate, but once it has been declared, a static_string's interface is (almost*) the same as that of a const std::string. Yes, you right it's unfortunate and IMHO is not appropriate for a wide use. typedef boost::static_string's', 't', 'a', 't', 'i', 'c', '_' StrType1; This syntax may be good for some specific (and not widely used) tasks such as building hashing algorithm at compile-time for a given set of static strings but not for normal strings. I beveive it's better to wait for a new compiler which can optimize dynamic memory allocations (a possibly even more) away. Hmm, but on the other hand, perhaps this is an area that a simple code generator might be practical. If you keep all your string literals (especially localisable strings) in separate files already these string files could be generated to use static_string - and so the syntax would not have to be manipulated. In fact if the code generator took a C++ file of string literal declarations as source and worked both ways swapping them in and out maybe quite trivial. I know code generators are not universally popular and I always template meta-programming where possible, even if a little more complex, but this could be a useful case for those that choose it? I have to admit I like the idea of having a std::string interface without the overhead of dynamic allocation. My biggest reservation would by the char-only restriction... Regards, [)o IhIL.. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Eric Ford's Unit package
This promises to meet a massive need, but for me must wait until I get MSVC 7.1 which I understand includes partial specialisation. (How did MS ever think it wasn't absolutely essential?) Meanwhile, perhaps others can evaluate this? Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Eric Ford Sent: Thursday, March 06, 2003 12:34 AM To: [EMAIL PROTECTED] Subject: RE: [boost] Eric Ford's Unit package This looks most interesting, and there most definitely remains a great need for a units handling package. I presume you have looked at W W Brown's SI units proposal http://home.fnal.gov/~wb/SItempl8.pdf and wonder why you rejected it and how your proposal is different. Yes, I had seen his old code, but not this proposal. (I have not seen a version of his code which implements his proposal. Please let me know if you can point to one.) I share many of his goals, and certainly benefitted from reviewing his code. I'll outline some of the differences below. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [config] BOOST_DEDUCED_TYPENAME
Aleksey Gurtovoy wrote: David Abrahams wrote: Aleksey Gurtovoy [EMAIL PROTECTED] writes: If BOOST_DEDUCED_TYPENAME was introduced for the sake of MSVC only (which seems very likely to be the case) It was. [...] Well, I think you're right, but the question remains: what should we do about it? Should we just replace BOOST_DEDUCED_TYPENAME? That's what I would do. I greped for it and it seems it is not used very often. How about using BOOST_WORKAROUND to keep the code local and thus not hide the actual workaround in a MACRO and spread to knowledge? Especially given it's only a workaround for a single compiler. Or do you think it is comparable to BOOST_STATIC_CONSTANT and will be used a lot in the future and doesn't fall into the category of problems BOOST_WORKAROUND is supposed to solve? Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] solaris, once again
I am having problems with the shared_ptr on Forte 6.2: when I compile my code into an application, it all seems to work. When I am compiling a static library, I had to compile it with the -misalign option. If I don't do this I get a misalignment error in a destructor of the shared_ptr. I do not know whether it was the intentin to use that switch. Should I do something else ? Mark Rodgers [EMAIL PROTECTED]@lists.boost.org on 06/03/2003 07:33:18 Please respond to Boost mailing list [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: Re: [boost] solaris, once again - Original Message - From: Garnet Kin-Lic Chan [EMAIL PROTECTED] there have been a few discussions recently about the status of solaris and boost. as someone whose code relies on the boost::function and boost::bind libraries, and who needs to port to solaris in the very near future, i'm happy to try and help. does anyone know what is needed, and has anyone had any experience with version 7 of the sun compilers? anyone else interested? code now that uses bind and function extensively and having reasonable success with Forte 6.2 (C++ 5.3). I've had to change a few things and will post a list when I've finished. If you're using this version of the compiler two things spring to mind: 1. Define BOOST_NO_INCLASS_MEMBER_INITIALIZATION fixed it. In general, this compiler does support in class member initialisation, but for some reason, the code in type traits causes a compiler assertion. 2. Get the latest patch. This fixes some of the problems you'll find with segmentation faults, notably with function (so for example compiling boost.thread used to fail but now works for me). Mark ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [config] BOOST_DEDUCED_TYPENAME
Daniel Frey [EMAIL PROTECTED] writes: I greped for it and it seems it is not used very often. How about using BOOST_WORKAROUND to keep the code local and thus not hide the actual workaround in a MACRO and spread to knowledge? Especially given it's only a workaround for a single compiler. Or do you think it is comparable to BOOST_STATIC_CONSTANT I do. and will be used a lot in the future Maybe not a lot, but often enough. I'm sure we have quite a few synonyms for it in various headers. Did you search for just TYPENAME? I find BOOST_ARG_DEPENDENT_TYPENAME BOOST_MSVC_TYPENAME BOOST_DEDUCED_TYPENAME BOOST_UBLAS_TYPENAME BOOST_SPIRIT_TYPENAME... etc. OK, I'm tired of typing these now. It really uglifies code to have to add the workaround every place you need it. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Eric Ford's Unit package
Paul A. Bristow [EMAIL PROTECTED] writes: This promises to meet a massive need, but for me must wait until I get MSVC 7.1 which I understand includes partial specialisation. (How did MS ever think it wasn't absolutely essential?) Meanwhile, perhaps others can evaluate this? I don't see why partial specialization should be required for this application. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [config] BOOST_DEDUCED_TYPENAME
David Abrahams wrote: Daniel Frey [EMAIL PROTECTED] writes: I greped for it and it seems it is not used very often. How about using BOOST_WORKAROUND to keep the code local and thus not hide the actual workaround in a MACRO and spread to knowledge? Especially given it's only a workaround for a single compiler. Or do you think it is comparable to BOOST_STATIC_CONSTANT I do. The difference I see is, that BOOST_STATIC_CONSTANT switches between two legal alternatives, while BOOST_DEDUCED_TYPENAME only hides non-conforming code (IIUC) which is required for some compilers. and will be used a lot in the future Maybe not a lot, but often enough. I'm sure we have quite a few synonyms for it in various headers. Did you search for just TYPENAME? No, I greped for BOOST_DEDUCED_TYPENAME I find BOOST_ARG_DEPENDENT_TYPENAME BOOST_MSVC_TYPENAME BOOST_DEDUCED_TYPENAME BOOST_UBLAS_TYPENAME BOOST_SPIRIT_TYPENAME... etc. OK, I'm tired of typing these now. It really uglifies code to have to add the workaround every place you need it. Agreed. I didn't know about the other MACROs. I just found the one (or two?) occasions where BOOST_DEDUCED_TYPENAME was used. Generally I think it's better to have things as local as possible, but if the above workaround is needed often, it might make sense to keep the macro and if I understand you correctly, the new macro will replace all of the above macros, right? Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [config] BOOST_DEDUCED_TYPENAME
Daniel Frey [EMAIL PROTECTED] writes: Agreed. I didn't know about the other MACROs. I just found the one (or two?) occasions where BOOST_DEDUCED_TYPENAME was used. Generally I think it's better to have things as local as possible, but if the above workaround is needed often, it might make sense to keep the macro and if I understand you correctly, the new macro will replace all of the above macros, right? That would be the idea. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: is_convertible love
Shame on me! I did saw 13.3.3.1/6 before posting my answer:
[...] When the parameter has a class type and the argument expression has
the same type, the implicit conversion sequence is an identity conversion.
[...]
It seems that overloading takes place before initialization. Initialization
requires additional overloading to select the best viable constructor. In
case that the first overloading required user defined conversion then only
standard conversions are allowed in the second overloading (core issue 84).
My solution relays on the second (initialization) overloading which makes it
(and VC) wrong.
I'll be very surprise if someone will solve your challenge.
Sorry for wasting your time,
Rani
David Abrahams wrote:
Rani,
Here's what Steve Adamczyk (Mr. overload resolution) at EDG had to say
about it:
I tracked down why we do what we do. It comes down to 13.3.3.1.2/4:
4 A conversion of an expression of class type to the same class type
is given Exact Match rank, and a conversion of an expression of
class type to a base class of that type is given Conversion rank,
in spite of the fact that a copy constructor (i.e., a
user-defined conversion function) is called for those cases.
Now, the idea of using the auto_ptr kind of trick (copying by
way of an auxiliary class) was not thought of when this paragraph
was done, but the point was that for purposes of overload
resolution copying X to X is always an exact match even if
something is called to do the copy.
Now, we could do a core issue to find out what this paragraph means
for the auto_ptr kind of case. I have to say, though, that
it would be an expensive thing to have to check everywhere that a
copy that looks like an exact match is done, and there's nothing
that says that calling a conversion function and copy constructor
is less efficient than calling a copy constructor, so I'd be
inclined to say that it should just be clarified to say that
such a copy is considered an exact match regardless of the
actual mechanism used to perform the copy.
Steve
- Rani wrote this
Interesting challenge (at least for me).
In first glance it seems to be impossible which made it even more
interesting.
typedef char (yes)[1];
typedef char (no) [2];
//
// TODO: handle types that can't be members
// (e.g. void, abstract, functions)
//
templateclass T
struct has_regular_ctor
{
private:
struct ctor_tester
{
T t;
struct B {};
operator B() const;
ctor_tester(B);
private:
// VC warnings
ctor_tester operator=(ctor_tester const);
};
static yes check(ctor_tester, int);
templatetypename U
static no check(ctor_tester const, U);
static ctor_tester const get();
public:
static const bool value =
sizeof(check(get(), 0)) == sizeof(yes);
};
struct A1 { A1(A1); };
struct A2 { A2(A2 const); };
typedef char test[!has_regular_ctorA1::value];
typedef char test[!has_regular_ctorA1 const::value];
typedef char test[ has_regular_ctorA2::value];
typedef char test[ has_regular_ctorA2 const::value];
typedef char test[ has_regular_ctorint::value];
The above code compiled fine with VC7.1 beta but failed to compile
using EDG and GCC.
Here is an explanation for why I think that it's compliant:
The form of the ctor of ctor_tester is the same as its member t
(12.8/5). In case the ctor argument has const qualifier then both
check functions has an exact match (13.3.3.1.1/3), the first check
using Lvalue-transformation and the second using identity. The
ambiguity buster in this case is the non-template function.
In case that the ctor is not const then the first version is viable
using user defined conversion sequence (like auto_ptr: ctor_tester -
B) and the second is still identity.
Overloading is so complex that I have doubts and I'll be happy to ear
a second opinion.
Rani
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: bug in random_number_generator ?
Hey,
As far as I can understand you are asking for a ranomized integer value
in the range [0,n) (i.e. n exclusive). If randomizing bits is what you
want, then the correct call is rgen(2), not rgen(1) (which basically
mean asking for an integer between 0 and 0 which doesn't exist so the
failure is expected). This may look counterintuitive to you, but you can
easily implement your own version which does not subtract 1 from n if
wanted.
Function call f(N) N is positive. Returns a pseudo-random number of
type Integer. [2] The return value is less than N, and greater than or
equal to 0.
--Taken from the SGI STL webpage regarding the Random Number Generator
concept.
Therefore, zero should be a valid result from rgen(1) as it is within
the range [0,1). I accept there would be no valid result for rgen(0).
Furthermore, the SGI implementation of random_sample_n, which I admit is
an SGI extension, expects that rgen(1) will return 0.
Cheers,
Dave
random_number_generator rgen(...);
cout rgen(1) endl; // causes assertion failure
I encountered this problem when using random_number_generator in
conjuction with the random_sample_n algorithm.
I have attached a simple patch which catches the case when the parameter
is 1. If anyone can tell me whether this is a reasonable fix, I would be
grateful.
The patch fixes a case which is wrong in the first place, so my answer
would be no :)
snip
result_type operator()(argument_type n) {
! if(n == 1) {
! return 0;
! } else {
! return uniform_intbase_type(_rng, 0, n-1)();
! }
}
Not that it matters, but the 'else' here is useless. Try avoiding
unnecessary else clauses.
Regards,
--
Tarjei
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] CVS repository locked?
I see this, when doing update: cvs server: [07:46:57] waiting for beman_dawes's lock in /cvsroot/boost/boost/tools/build . cvs server: [08:02:58] waiting for beman_dawes's lock in /cvsroot/boost/boost/tools/build Beman, is there anything you can do about it? Like killing client or updating again? Or ony sourceforge admins are in position to fix this? - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] New release procedure?
At 11:35 AM 3/5/2003, David Abrahams wrote: The multiple merge thing is probably much less of an issue when working from trunk to branch, but it still could be useful to have the tag. I would call the tag merged_to_branch name. So this is something each developer would do when merging to the branch from MAIN if they want 'extra' information in CVS about where the merge took place? If this is correct, I'm generally opposed to this extra step as I don't see what it is going to buy you above and beyond what you can get in CVS log command. Am I missing something? If you make a big change on the trunk and need to merge to the branch, and then you do it again, you want cvs merge -jmerged_to_RC_whatever -jHEAD In order to make the merge work properly. If the release manager doesn't tag the head at the merge point, the first person to merge from trunk to branch messes up that arrangement. OK, I've added the tag merged_to_RC_1_30_0 to the CVS at the appropriate point in time. It took a couple of hours experimenting with the sandbox to figure out how to do this correctly. WinCVS (and presumably cvs itself) seems to report time as UTC, but expects input times to be local. The tagging itself took over an hour even though SourceForge CVS seemed to running very quickly this morning on other operations. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Formal Review for Boost I/O Library
On Wed, 26 Feb 2003 23:00:11 -0600, Ed Brey [EMAIL PROTECTED]
wrote:
The formal review for the updated Boost I/O Library begins today and runs through
March 7.
Just some quick comments:
The I/O library contains various components for use with the standard I/O library.
The components are as follows:
State-saving classes for various IOStream attributes.
These are already into boost, aren't they? Are you asking for a
further review? Or weren't they reviewed when they should have been?
Class templates to ease making streams off a new stream-buffer class.
Stream and stream-buffer class (templates) that use an internal array.
Additional I/O manipulator function (templates).
This part looks quite extemporaneous and incomplete. For instance, why
aren't there
template typename CharT, typename Traits
std::basic_ostreamCharT, Traits
htab (std::basic_ostreamCharT, Traits os) {
return os.put(os.widen('\t'));
}
template typename CharT, typename Traits
std::basic_ostreamCharT, Traits
bel (std::basic_ostreamCharT, Traits os) {
return os.put(os.widen('\a'));
}
... etc...
too?
As to the two manipulators provided:
- Though 'newl' and 'skipl' imitate the pattern of 'endl' I think it
would be better choosing more descriptive names, like new_line and
skip_until_newline. But, of course, these are religion issues :-)
- The implementation of skipl is erroneous as per lib issue 172; it
should be
template typename Ch, class Tr
std::basic_istreamCh, Tr
skip_until_new_line(std::basic_istreamCh, Tr is)
{
return is.ignore( std::numeric_limits std::streamsize :: max(),
Tr::to_int_type(is.widen( '\n' )) );
}
- The test program for iomanip.hpp could be improved, I think. Better
showing that skipl can skip any character before the newline, for
instance with something like:
// untested test program
//
char hello[] = hello;
std::stringstream ss;
ss hello AxxA newl There;
std::string s;
ss.seekg( 0 );
ss std::setw(sizeof hello) hello;
char c;
ss c;
BOOST_TEST(c == 'A');
ss skip_until_new_line s;
BOOST_TEST( s == There );
- in iomanip.hpp the function template declarations immediately before
the definitions just confuse the code IMO.
- as a general rule, I don't like having source file names too similar
to standard header-names (example: iomanip.hpp). BTW it tends to be
annoying to remember slight differences like iosfdw vs. io_fwd.hpp
and/or remembering whether the latter is iofwd or io_fwd.
The stream buffer classes are new and deserve primary attention in this review.
Yes. Let me start from the documentation, which is IMHO absolutely
insufficient, especially in the rationale section. Informally speaking
(up to Daryle to improve the wording from a technical perspective) I
think the real rationale goes more-or-less along these lines:
When deriving from the standard basic_istream, basic_ostream,
basic_iostream classes, *you* should provide a pointer to a suitable
stream buffer (this is not the case, for instance, when deriving from
ifstream and ofstream because those classes already contain their
stream buffer). There are several ways to do this:
a) construct a stream buffer independently and associate it with a
stream object later
b) gather the buffer from another stream; this leads to a buffer
shared among several stream objects. Example:
template class Ch, class Tr = std::char_traitsCh
class my_stream : public std::basic_ostream Ch, Tr
{
public:
my_stream(std::basic_ostreamCh, Tr os):
std::basic_ostreamCh, Tr(os.rdbuf())
{
}
};
my_streamchar m (std::cout);
m hi!\n;
Now m and std::cout share the same buffer. Sharing a stream buffer can
be useful in various situations where you want, for instance,
different format settings, or different locales, for the same stream:
in such scenarios instead of continuously switching the format
settings or the locale you use different streams which write to (or
read from) the same stream buffer
c) put a stream buffer into the derived stream; the stream buffer can
be a base sub-object or a data member. This is the typical approach
when a new buffer type is used, and _is what the following classes
help implementing_.
I've omitted, for laziness, an (obvious) example for case a).
Ok, now to the code. Sad to say, but this is the typical case where it
takes more time to understand what the existing solution is meant to
do than to write your own code from scratch. BTW, the fact that the
templates are identical except for the presence of 'istream',
'ostream' or 'iostream' in some places is highly suspicious. That
consideration apart, let us compare your code with what I would write
from scratch if I had to define my own stream:
struct buffer_wrapper {
std::stringbuf buffer;
};
template class Ch, class Tr = std::char_traitsCh
class my_stream :
virtual buffer_wrapper,
Re: [boost] coding style
(d) It makes it easier to work with a fixed-width terminal or terminal emulator. You may think this is an obsolete requirment, but I spend most of my working days using a VT-100 emulator connected to various servers running just Oracle, gdb, gcc, vi, and a shell. At 09:34 AM 3/6/2003, Paul Beardsley wrote: Hello, I have a question about coding style which maybe fits the list criteria of technical discussion about a library'. The Boost style guide recommends 80 column text without giving any justification for this. What is your opinion of this constraint? The three supporting arguments I hear are (a) It makes it possible to print code. Personally I never print code. I understand it might be useful given, say, 15 people in a room doing a code review but even then I think it would be better to bring in laptops and PCs and look at the electronic version. For one thing at least then everyone ends up with the same annotations. (b) It makes it possible to do side-by-side comparisons of two slightly differing pieces of code. Occasionally I need to do a comparison but I really try to avoid it - there is something wrong if the development process keeps throwing up the need for a laborious (error-prone) manual comparison of pieces of code. (c) Reading test over 80 columns makes your eyes tired, that's why typesetters traditionally converged on the 80 column solution. I think that reading highly-structured code is different to reading straight text, so I don't know if the lessons from straight text carry over. My arguments for longer-than-80-column lines would be the following. These arguments apply specifically to header files - (i) It's easier to parse a header file with one method per line. Longer lines make this more likely. (ii) It's preferable to have inline method definitions with the declaration, for short methods. Longer lines again make this more likely. (iii) The structure of the code throws up other cases where one method per line makes for readability e.g. overloaded methods benefit from being on consecutive lines so that the first part of the text corresponds directly and only the signatures differ. The most powerful argument in favor of 80-column text is just that 'everyone does it', or that you cannot anticipate that somebody-somewhere might have a device that needs 80-column text. But these seem more like arguments by inertia and surely readability is more important. So I wondered what the general opinion of boost developers is on this issue, Thanks, Paul Beardsley. Do you Yahoo!? http://rd.yahoo.com/finance/mailtagline/*http://taxes.yahoo.com/Yahoo! Tax Center - forms, calculators, tips, and more ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] coding style
Paul Beardsley [EMAIL PROTECTED] writes: I have a question about coding style which maybe fits the list criteria of technical discussion about a library'. You can find answers to your questions at http://groups.yahoo.com/group/boost/files/coding_guidelines.html -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BGL]edge connectivity code won't compile
Hi, Volodya Following arethe error messages: -- \boost-g\boost_1_29_0\boost\property_map.hpp(151) : error C2039: 'reference' : is not a member of 'boost::property_traits' with [ PA=boost::default_color_type * ] g:\boost-g\boost_1_29_0\boost\graph\properties.hpp(52) : see declaration of 'boost::property_traits' with [ PA=boost::default_color_type * ] g:\boost-g\boost_1_29_0\boost\concept_check.hpp(46) : see reference to class template instantiation 'boost::ReadablePropertyMapConcept' being compiled with [ PMap=boost::default_color_type *__w64 , Key=Vertex ] g:\boost-g\boost_1_29_0\boost\property_map.hpp(209) : see reference to function template instantiation 'void boost::function_requires(boost::type *)' being compiled with [ T=boost::ReadablePropertyMapConcept ] g:\boost-g\boost_1_29_0\boost\property_map.hpp(208) : while compiling class-template member function 'void boost::ReadWritePropertyMapConcept::constraints(void)' with [ PMap=boost::default_color_type *__w64 , Key=Vertex ] g:\boost-g\boost_1_29_0\boost\concept_check.hpp(46) : see reference to class template instantiation 'boost::ReadWritePropertyMapConcept' being compiled with [ PMap=boost::default_color_type *__w64 , Key=Vertex ] g:\boost-g\boost_1_29_0\boost\graph\breadth_first_search.hpp(76) : see reference to function template instantiation 'void boost::function_requires(boost::type *)' being compiled with [ T=boost::ReadWritePropertyMapConcept ] g:\boost-g\boost_1_29_0\boost\graph\breadth_first_search.hpp(116) : see reference to function template instantiation 'void boost::breadth_first_visit(const IncidenceGraph ,boost::graph_traits::vertex_descriptor,boost::queue_Tp,_Sequence ,boost::bfs_visitor,boost::default_color_type *__w64 )' being compiled with [ IncidenceGraph=boost::filtered_graph::type,boost::keep_all, G=boost::filtered_graph::type,boost::keep_all, _Tp=vertex_t, _Sequence=std::deque, Visitors=boost::edge_predecessor_recorder::directed_category,boost::adjacenc y_list_traits::vertex_descriptor ,boost::on_tree_edge ] g:\boost-g\boost_1_29_0\boost\graph\edmunds_karp_max_flow.hpp(118) : see reference to function template instantiation 'void boost::breadth_first_search(const VertexListGraph ,boost::graph_traits::vertex_descriptor,boost::queue_Tp,_Sequence ,boost::bfs_visitor,boost::default_color_type *__w64 )' being compiled with [ VertexListGraph=boost::filtered_graph::type,boost::keep_all, G=boost::filtered_graph::type,boost::keep_all, _Tp=vertex_t, _Sequence=std::deque, Visitors=boost::edge_predecessor_recorder::directed_category,boost::adjacenc y_list_traits::vertex_descriptor ,boost::on_tree_edge ] g:\boost-g\boost_1_29_0\boost\graph\edge_connectivity.hpp(159) : see reference to function template instantiation 'boost::property_traits::value_type boost::edmunds_karp_max_flow(Graph ,boost::graph_traits::vertex_descriptor,boost::graph_traits::vertex_descrip tor,boost::property_map::type,boost::property_map::type,boost::property_map: :type,boost::default_color_type *__w64 ,boost::detail::edge_desc_impl )' being compiled with [ PA=boost::property_map::type, Graph=FlowGraph, G=FlowGraph, Property=boost::edge_capacity_t, Directed=boost::adjacency_list_traits::directed_category, Vertex=boost::adjacency_list_traits::vertex_descriptor ] Thanks. I will look into CVS version, meanwhile. J-S - Original Message - From: Vladimir Prus [EMAIL PROTECTED] To: Boost mailing list [EMAIL PROTECTED] Sent: Thursday, March 06, 2003 2:08 AM Subject: Re: [boost] [BGL]edge connectivity code won't compile J-S Lin wrote: Hi, I ran into problems trying to compile the BGL example code, edge_connectivity.cpp. (There are two codes, this is the short one with underscore, the other is hyphen edge-connectivity.) I used VC7. I have been running other codes without any problem. Hi, Basically, I got two errors: 1)C1076--I have changed from /Gm to /Zm1000, and it went way. 2) C2039--it flagged error reference is not a member of property map and points to boost/property_map.hpp in boost-1-29-0. I have no idea how to fix this one. I think that in order for somebody to look into the problem, you should provide *exact* error messages. The property_map.hpp file is big, and guessing what line upsets VC7 is impossible. In first case, you did not even say where
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
--- David Abrahams [EMAIL PROTECTED] wrote:
There are any number of ways you could try reformulating this to make
the error go away. At worst you could try the __BORLANDC__ branch in
is_base_and_derived.hpp.
Another approach:
template typename B, typename D, typename T
static type_traits::yes_type bd_helper(D const volatile *, T);
template typename B, typename D
static type_traits::no_type bd_helper(B const volatile *, int);
That doesn't work because older EDG's don't support the bd_helperB,D syntax.
To be sure I just tried it again and it failed.
Using the __BORLANDC__ branch got me a little further. Some Boost.Python tests
compile and run.
Is the __BORLANDC__ branch different from (not as good as) the
is_base_and_derived implementation in 1.29.0?
There are many new errors when compiling the Boost.Python tests, but most of
them are identical:
mipspro-C++-action
/var/tmp/rwgk/bjam/libs/python/test/bin/embedding.test/mipspro/debug/embedding.o
cc-3192 CC: ERROR File =
/u1/rwgrosse/rc_1_30_0/boost/boost/mpl/fold_backward.hpp, Line = 47
The nontype boost::mpl::fold_backwardT1, T2, T3,
boost::mpl::arg1::rebind
is not a class template.
BOOST_MPL_AUX_LAMBDA_SUPPORT(3,fold_backward,(Sequence,State,BackwardOp))
^
I've preprocessed the source of test/embedding.cpp and stripped out all #line
directives. The error message then becomes:
cc-3192 CC: ERROR File = zzstrip.cpp, Line = 71667
The nontype boost::mpl::fold_backwardT1, T2, T3,
boost::mpl::arg1::rebind
is not a class template.
static const int arity = 3; typedef Sequence arg1; typedef State arg2;
typedef BackwardOp arg3; struct rebind; }; template typename T1,typename
T2,typename T3 struct fold_backwardT1,T2,T3 ::rebind { template typename
U1,typename U2,typename U3 struct apply : fold_backward U1,U2,U3 { };
^
With the ^ pointing to the beginning of ::rebind.
The full prepocessed, stripped file is here:
http://cci.lbl.gov/~rwgk/tmp/zzstrip.cpp
Are there any insights what the compiler is choking on here?
Thanks,
Ralf
__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] writes: Is the __BORLANDC__ branch different from (not as good as) the is_base_and_derived implementation in 1.29.0? cvs diff knows for sure. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] coding style
From: Paul Beardsley [EMAIL PROTECTED] in favor of 80-column text is just that So I wondered what the general opinion of boost developers is on this issue, I am in favor of 72 column lines myself. This allows me to have three comfortable columns of code on the screen at once. It also makes printing easy. It means that I don't have to scan my eyes over and over and over to the right to see what a line means. I don't have to keep scanning six inches from left to right, rather than up and down a half cm. Also editing long lines is more difficult. It is much easier (for me) to comment out lines and insert different lines of a multi-line statement. It is easier to see what is changed with shorter lines. Patches are clearer with short line lengths. I find other people's code with long linelengths is cause by either too much nesting or by putting too many concepts on one line... Joel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] New release procedure?
At 11:38 AM 3/6/2003, Beman Dawes wrote: At 11:35 AM 3/5/2003, David Abrahams wrote: The multiple merge thing is probably much less of an issue when working from trunk to branch, but it still could be useful to have the tag. I would call the tag merged_to_branch name. So this is something each developer would do when merging to the branch from MAIN if they want 'extra' information in CVS about where the merge took place? If this is correct, I'm generally opposed to this extra step as I don't see what it is going to buy you above and beyond what you can get in CVS log command. Am I missing something? If you make a big change on the trunk and need to merge to the branch, and then you do it again, you want cvs merge -jmerged_to_RC_whatever -jHEAD In order to make the merge work properly. If the release manager doesn't tag the head at the merge point, the first person to merge from trunk to branch messes up that arrangement. more/release_procedures.htm has been updated to reflect these discussions. The changes to more/release_procedures.htm were made on the main trunk, and then merged into RC_1_30_0, and the process repeated several times as the instructions were refined and corrected. In other words, the procedure was applied to its own documentation:-) At least in WinCVS, this was a good deal easier than the old way IMO. Please take a look at more/release_procedures.htm and suggest any corrections necessary. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
--- David Abrahams [EMAIL PROTECTED] wrote: Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] writes: Is the __BORLANDC__ branch different from (not as good as) the is_base_and_derived implementation in 1.29.0? cvs diff knows for sure. Sure, but this chasing tails game is impractical. If nobody else cares about MIPSpro compatibility we will just keep using 1.29.0. I'd like to suggest opening a 1.29 maintenance branch. I've accumulated a few minor patches that make Boost.Python 1.29.0 compatible with Python 2.3. If I could check these patches in they would be available to everybody. Ralf __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: CVS repository locked?
At 11:04 AM 3/6/2003, Vladimir Prus wrote: I see this, when doing update: cvs server: [07:46:57] waiting for beman_dawes's lock in /cvsroot/boost/boost/tools/build . cvs server: [08:02:58] waiting for beman_dawes's lock in /cvsroot/boost/boost/tools/build Beman, is there anything you can do about it? Like killing client or updating again? Or ony sourceforge admins are in position to fix this? If it really was a hung lock, only the sourceforge people can unlock it. But more likely you just happened to access during the more than an hour it took to apply the merged_to_RC_1_30_0 tag. There was a delay of more than ten minutes right at the end with no apparent activity. I don't know why it took so long, unless it had to do with tagging at a past date rather than the current state. Let me know if you continue to have problems, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Eric Ford's Unit package
This promises to meet a massive need,
but for me must wait until I get MSVC 7.1
which I understand includes partial specialisation.
I don't see why partial specialization should be required for this
application.
Actually, I'm not sure if what I'm doing counts. I've never really paid attention
to this.
It is important to allow appropriate arithmetic operations between
quantities with different dimensions. It is also be important to
allow for numeric type promotion. (Although, this is only crudely
implemented (as promote_numeric+typeA,B for now). I'm hoping
someone else will offer code for this. Fernando C?) It's important
to keep separate dimensioned quantities which are in different unit
systems (e.g., we don't want to add meter (length in SI) and second
(length in relativistic units).
So I use templates which take multiple parameters, and then specialize
them where some of the template parameters are fixed and other
template parameters are not fixed. Sorry if this is bad terminology.
Here's an example of the code...
Each Dimensioned type is a typedef for base_dimenNumT, SystemT, DimListT.
NumT is the numeric type used to store the number.
SystemT specifies what dimension system (e.g., standard, relativistic) is being used.
DimListT is a list of fractions which specifies the dimensions of the particular
variable in terms of the base dimensions.
When a user multiplies (divides) two dimensioned quantities, they generally get
back another dimensioned quantity. However, if they multiply (divide)
two quantities with the same (inverse) dimensions, then they can get back a pure
number.
using ebf::units::mks_double;
length l = 3 * meter, w = 2 * meter;
area a = l * w; // length * length must return an area
pure r = l / w; // length / length can return a pure number (pure's DimListT =
0,0,0,...)
double rr = l / w; // length / length can also return a non-dimensioned type
(double/double - double)
I acheive this flexibility with the following code in
base_dimennumeric_type,system_type,diml_type:
// helper classes to allow returning scalar when possible
templatetypename ArgNumericType, typename ArgDimList
struct div_return_type
{
private:
BOOST_CLASS_REQUIRE(ArgNumericType, ebf, NumericConcept);
BOOST_CLASS_REQUIRE(ArgDimList, ebf::dimensions, DimlistConcept);
typedef typename ebf::promote_numeric_typenumeric_type, ArgNumericType::type
return_numeric_type;
typedef typename div_dimldiml_type,ArgDimList::diml_type return_diml_type;
public:
typedef base_dimenreturn_numeric_type,system_type,return_diml_type type;
};
// Specialization to allow for returning non-dimensioned quantity.
templatetypename ArgNumericType
struct div_return_typeArgNumericType, diml_type
{
private:
BOOST_CLASS_REQUIRE(ArgNumericType, ebf, NumericConcept);
typedef typename ebf::promote_numeric_typenumeric_type, ArgNumericType::type
return_numeric_type;
public:
typedef return_numeric_type type;
};
// Mixed dimensions operations (within system)
templatetypename ArgNumericType, typename ArgDimList
const typename div_return_typeArgNumericType,ArgDimList::type
operator/(const base_dimenArgNumericType, system_type, ArgDimList rhs) const
{ return typename div_return_typeArgNumericType,ArgDimList::type
(pure()/rhs.pure()); };
I'm not sure if this specialization above counts as partial template
specialization or not. I'm sure some boosters must know.
I suppose the most relevant thing is for someone to try it with a
compiler that doesn't like them. Paul, did you actually try compiling
my code? If not, may you could give it a try? If so, can you let me
know exactly where your compiler wasn't happy?
Thanks,
Eford
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Eric Ford's Unit package
Hugo wrote: [snip] I have found in the past that there is a need to distinguish between dimension handling and unit handling. In the case of a physical calculation, I usually ensure that the code works with a self consistent set of units, and thus only need dimensionality, compile time, code. Units then become important only in the user interface, and I have a list of the units used in the physical calculation for each dimension. This is obviously only one way of using dimensions and units, but I think an important one. The usual exception to the above is for money where you are working with multiple currencies. One could actually regard the different currencies as realizing different dimensions. After all, a dollar bill is quite different from a British pound bill, although one can apply a certain process (exchange...) to convert between these dimensions. For some ideas about how one can implement the dimension/unit framework, look at the Java-based system Frink (http://futureboy.homeip.net/frinkdocs/) implemented by Alan Eliasen. /David ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Eric Ford's Unit package
I assumed you knew it did - I'll give it a go with MSVC 7.0. Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Eric Ford Sent: Thursday, March 06, 2003 7:15 PM To: [EMAIL PROTECTED] Subject: [boost] Re: Eric Ford's Unit package This promises to meet a massive need, but for me must wait until I get MSVC 7.1 which I understand includes partial specialisation. I don't see why partial specialization should be required for this application. I suppose the most relevant thing is for someone to try it with a compiler that doesn't like them. Paul, did you actually try compiling my code? If not, may you could give it a try? If so, can you let me know exactly where your compiler wasn't happy? Thanks, Eford ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] coding style
in favor of 80-column text is just that So I wondered what the general opinion of boost developers is on this issue, I am in favor of 72 column lines myself. This allows me to have three comfortable columns of code on the screen at once. This is namely the reason why I would prefer longer lines. On majority on modern monitors 80-column text fit to left 1/3 of monitor space, leaving 2/3 blank. From idiological prospective you won't find too many reasons to defend 80-column limitation. We tend to use more and more explicit namespace specifications, a lot of template parameters, effectively making even simple assignment to spread on multiple lines (and less readable) would you stick to 80-column. Unless you try to put several statements on the same line, I prefer to see it long not separated. On the other hand, I admit that there are still as lot of people using vi through terminal connection. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] solaris, once again
From: Marc Borgers [EMAIL PROTECTED] I am having problems with the shared_ptr on Forte 6.2: when I compile my code into an application, it all seems to work. When I am compiling a static library, I had to compile it with the -misalign option. Interesting. I haven't got as far as running anything yet but when (if!) I do, I'll let you know if I have the same problem. Mark ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] coding style
Rozental, Gennadiy [EMAIL PROTECTED] writes: in favor of 80-column text is just that So I wondered what the general opinion of boost developers is on this issue, I am in favor of 72 column lines myself. This allows me to have three comfortable columns of code on the screen at once. This is namely the reason why I would prefer longer lines. On majority on modern monitors 80-column text fit to left 1/3 of monitor space, leaving 2/3 blank. From idiological prospective you won't find too many reasons to defend 80-column limitation. We tend to use more and more explicit namespace specifications, a lot of template parameters, effectively making even simple assignment to spread on multiple lines (and less readable) would you stick to 80-column. Unless you try to put several statements on the same line, I prefer to see it long not separated. On the other hand, I admit that there are still as lot of people using vi through terminal connection. OK, this is getting OT. Let's get back to library design, please. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] coding style
I'd say it's primarily the 80-column terminal limit that is the reasoning for this. I personally only go to 79 columns so that when I work on a terminal and I type that 80th line the insertion pointer doesn't wrap. Aside from that, on my current monitor (1152 pixels wide), I can get 2 CodeWarrior source windows side-by-side at 80 columns, but not much more if I want to be able to see desktop icons on the side of it. And it's very useful to have those two, usually a source file and its accompanying header. So even if there were no such thing as a text-based terminal anymore, I'd still be in favor of limiting the number of columns to about what we're using. -- Brian ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Proposal: static_string library
At 05:58 PM 3/5/2003, Robert Klarer wrote: There's already been some discussion of this library under the thread Proposal: strings as template parameters, but static_string hasn't been the subject of its own thread, so I'm starting this one. I'd like to solicit opinions about this project. Is it worthwhile? The purpose of the static_string library is to offer an alternative to string literals and the standard type const std::string. A static_string uses no dynamically allocated memory, and is more efficient at execution time than either string literals or basic_strings. Yes, agreed. That would be useful. IIRC, the C++ committee's performance working groups has talked about such a string in the past. But... The syntax for declaring a static_string is unfortunate... boost::static_string's', 't', 'a', 't', 'i', 'c', '_' StrType1; Unfortunate? Is that one of those understatement jokes Canadians are known for? I'd say it is way worse that unfortunate - it is ugly and error prone. Lack of internationalization support is also a serious concern. There are questions that come to mind: * Can you come up with a small, workable language extension that eases those problems? * Can you come up with an alternate design that gives up a tiny bit of efficiency (one pointer indirection perhaps) but then allows reasonable construction and internationalization? Wondering-out-loud, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] coding style
From: Joel Young [EMAIL PROTECTED] I find other people's code with long linelengths is cause by either too much nesting or by putting too many concepts on one line... That doesn't have to be the case. There can easily be lines longer than 80 characters, which only contain one statement or expression, i.e. one concept, regardless of nesting. Regards, Terje ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] coding style
Terje Slettebø [EMAIL PROTECTED] writes: From: Joel Young [EMAIL PROTECTED] I find other people's code with long linelengths is cause by either too much nesting or by putting too many concepts on one line... That doesn't have to be the case. There can easily be lines longer than 80 characters, which only contain one statement or expression, i.e. one concept, regardless of nesting. Please take this conversation elsewhere! Thanks, Dave (as moderator) -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Proposal: static_string library
From: Beman Dawes [EMAIL PROTECTED] At 05:58 PM 3/5/2003, Robert Klarer wrote: The purpose of the static_string library is to offer an alternative to string literals and the standard type const std::string. A static_string uses no dynamically allocated memory, and is more efficient at execution time than either string literals or basic_strings. Yes, agreed. That would be useful. IIRC, the C++ committee's performance working groups has talked about such a string in the past. There are questions that come to mind: * Can you come up with a small, workable language extension that eases those problems? Josuttis/Vandevoorde mentions being able to pass string literals as template parameters as a possible future extension. That would be a clean way to handle it. Possibly could there also be a general solution regarding passing compound values. At the moment, values of class type can't be passed as template parameters. * Can you come up with an alternate design that gives up a tiny bit of efficiency (one pointer indirection perhaps) but then allows reasonable construction and internationalization? If run-time computation is ok, and that one only wants to avoid dynamical allocation, then one might do something like I used in another posting in this thread: templateclass CharType, int N class fixed_size_string; templateclass CharType, int N1, int N2 fixed_size_stringCharType, N1+N2 operator+(const fixed_size_stringCharType, N1 s1, const fixed_size_stringCharType, N2 s2); etc. Regards, Terje ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Eric Ford's Unit package with MSVC 7.0
Sadly, example1.cpp fails with MSVC 7.0 - sigh :-(
with language extension allowed:
-- Build started: Project: Units, Configuration: Debug Win32 --
Compiling...
example1.cpp
j:\Cpp\Units\fraction_ct.hpp(44) : fatal error C1001: INTERNAL COMPILER ERROR
(compiler file 'msc1.cpp', line 2844)
Please choose the Technical Support command on the Visual C++
Help menu, or open the Technical Support help file for more information
Build log was saved at file://j:\Cpp\Units\Debug\BuildLog.htm
Units - 1 error(s), 0 warning(s)
with disable language extensions
-- Build started: Project: Units, Configuration: Debug Win32 --
Compiling...
example1.cpp
j:\Cpp\Units\fraction_ct.hpp(42) : warning C4253:
'ebf::fraction_ct::FracConceptT::constraints' : forming a pointer-to-member
requires explicit use of the address-of operator ('') and a qualified name
j:\Cpp\Units\fraction_ct.hpp(51) : see reference to class template
instantiation 'ebf::fraction_ct::reduce_fracA' being compiled
j:\Cpp\Units\fraction_ct.hpp(43) : error C2970: 'boost::math::static_gcd' :
template argument 'Value1' : invalid use of non-integral-constant static
variable 'num' as non-type argument
I:\boost_1_29_0\boost\math\common_factor_ct.hpp(170) : see declaration
of 'boost::math::static_gcd'
j:\Cpp\Units\fraction_ct.hpp(43) : error C2970: 'boost::math::static_gcd' :
template argument 'Value2' : invalid use of non-integral-constant static
variable 'den' as non-type argument
I:\boost_1_29_0\boost\math\common_factor_ct.hpp(170) : see declaration
of 'boost::math::static_gcd'
j:\Cpp\Units\fraction_ct.hpp(44) : fatal error C1903: unable to recover from
previous error(s); stopping compilation
Build log was saved at file://j:\Cpp\Units\Debug\BuildLog.htm
Units - 3 error(s), 1 warning(s)
Info on the error is:
'class' : template argument 'parameter' : invalid use of non-integral-constant
static variable 'var' as non-type argument
You cannot use the name or address of a static variable as a template argument.
For example, the following code shows how this error would be generated:
// C2970.cpp
static int si; // C2970 cannot use static variable in templates
template int i class X {};
template int *pi class Y{};
Xsi anX;
Ysi aY;
int main()
{
}
Can you see a way around this?
Can anyone try with 7.1?
Paul
Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK
+44 1539 561830 Mobile +44 7714 33 02 04
Mobile mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Variant Library Review
Andrei Alexandrescu wrote: By the way, any chance to tweak the acknowledgments a bit. They mention GenericProgramming: Discriminated Unions Part 1, Part 2, Part 3. C/C++ Users Journal. 2002, but the text doesn't mention the earlier publication, which is http://oonumerics.org/tmpw01/alexandrescu.pdf. I think that's where various kinds of visitation in the context of C++ discriminated unions were first considered a core feature, together with a number of more obvious things (that made it or not), such as using typelists, computing alignment, and dispatching via pseudo-vtables. Can do. We had excluded this since you reference it in your later articles. But I suppose it makes sense to acknowledge the history. Also, the ack text doesn't say whether the work above influenced at all the library design or is just previous work developed unbeknownst to the authors - the GenericProgramming reference is specified in the bibliography as [Ale02] without being referred to at all. Sorry this is a typo that was carried over from an old version of the docs. Where the acknowledgments read: Andrei Alexandrescu's work in [Ale01] inspired the library's design. It should instead reference [Ale02]. The problem was that I mistyped the publication year for the GenericProgramming articles in an earlier version of the docs. So I will fix this. As well, I will update the docs to reflect the influence of the oonumerics paper on the design of the library. If the authors were aware of the previous work and used it as a source of inspiration, it's nice to give credit where it is due. It costs nothing and it is considerate. Just recently I failed to give due credit and boy it didn't feel good. As I said above, this was the result of a typo and certainly not intended to acknowledge your prior work. (Indeed, the sandbox CVS history shows this.) Sorry for any misunderstandings. Thanks, Eric ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Variant Library Review
Eric Friedman wrote: As I said above, this was the result of a typo and certainly not intended to acknowledge your prior work. (Indeed, the sandbox CVS history shows this.) Speaking of typos, what I *meant* to say... As I said above, this was the result of a typo and certainly not intended to avoid acknowledging your prior work. (Indeed, the sandbox CVS history shows this.) Thanks, Eric ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
Ralf W. Grosse-Kunstleve wrote:
This requires active participation by the developers. We've spent a
lot of time setting up the auto-builds to enable developers to see
immediately when their changes break portability. We've also made a
major effort cleaning up 1.29.0. That seemed like a good start to me,
but it didn't work out for lack of participation from the developer's
side. So now I am stuck with messages like the one posted before:
cc-3192 CC: ERROR File = zzstrip.cpp, Line = 71667
The nontype boost::mpl::fold_backwardT1, T2, T3,
boost::mpl::arg1::rebind
is not a class template.
static const int arity = 3; typedef Sequence arg1;
typedef State arg2;
typedef BackwardOp arg3; struct rebind; }; template
typename T1,typename
T2,typename T3 struct fold_backwardT1,T2,T3 ::rebind {
template typename
U1,typename U2,typename U3 struct apply : fold_backward
U1,U2,U3 { };
^
If one of the developers could at least comment on this I might give it
another try. Otherwise I estimate it would take me weeks to
reverse-engineer what is happening here.
Ralf, I will definitely look into it tonight and get back to you.
Aleksey
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Proposal: static_string library
Terje Slettebø wrote: If run-time computation is ok, and that one only wants to avoid dynamical allocation, then one might do something like I used in another posting in this thread: templateclass CharType, int N class fixed_size_string; templateclass CharType, int N1, int N2 fixed_size_stringCharType, N1+N2 operator+(const fixed_size_stringCharType, N1 s1, const fixed_size_stringCharType, N2 s2); An implementation of basic_string that uses the small string optimization already implements something very close to this. We don't need to specify an entirely new kind of string to benefit from this technique. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Proposal: static_string library
Beman Dawes wrote: Unfortunate? Is that one of those understatement jokes Canadians are known for? I'd say it is way worse that unfortunate - it is ugly and error prone. I didn't want to prejudice the group with judgemental language like ugly and error prone. :-) I certainly recognize that the syntax is terrible, but the syntax isn't the essence of this proposal. I'm really proposing a general direction toward a solution to a problem that, as you have mentioned, has already been discussed by the performance subgroup of the C++ committee. The details can be changed. One thing that I'm really interested in discussing is whether the problem that this library addresses is one that's worth solving. Is there sufficient interest in solving the problem (and others like it) that a change to the language is justified? * Can you come up with a small, workable language extension that eases those problems? Here's a list of possibilities, with some discussion. Please note that I'm not arguing that any of these ideas is especially desirable. They're just ideas to be explored. idea #1: string literals as template arguments The extensions subgroup of the committee has discussed this one briefly. Interestingly, this extension is not, by itself, sufficient for the implementation of a static_string. The reason for this is that the expression str[index] is not currently a compile-time constant expression. Since individual characters cannot be selected from a string literal at compile-time, it would be impossible to implement compile-time versions of most of the basic_string (and static_string) member functions. To be useful for creating a static_string library, then, this idea really involves more than one change to the core language. If these changes were in fact made to the language, would we still need a static_string library? I suppose that the answer to this question depends on the number and nature of those changes. idea #2: a magic operator This idea is simple, but it might not be of sufficiently general utility to justify its addition to the language. The magic operator would instruct the C++ compiler to rewrite a string literal by replacing it with a comma-separated list of character literals. Then the initialization syntax for a static_string would look like this: boost::static_stringmagic_string_unglue(my text) str; // becomes: boost::static_string'm', 'y', ' ', 't', 'e', 'x', 't' str; Please note that I chose to name the operator magic_string_unglue for the purpose of this example only. I'm not seriously suggesting that this is a great name for a C++ keyword. :-) idea #3: preprocessor tricks I don't believe that a preprocessor trick can help, actually, though I'd be happy to be proven wrong. The basic lexical unit that can be manipulated by the preprocessor is the token. The individual characters that compose a token aren't really available for manipulation. The preprocessor has a token-pasting macro, but no token-unpasting macro, for example. Lack of internationalization support is also a serious concern. I'm not sure whether this addresses that concern, but I had thought that I would wait until more of the issues surrounding static_string were resolved before I began to implement a static_wstring. Trying-not-to-appear-crazy, Robert Klarer ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Proposal: static_string library
From: Robert Klarer [EMAIL PROTECTED] Terje Slettebø wrote: If run-time computation is ok, and that one only wants to avoid dynamical allocation, then one might do something like I used in another posting in this thread: templateclass CharType, int N class fixed_size_string; templateclass CharType, int N1, int N2 fixed_size_stringCharType, N1+N2 operator+(const fixed_size_stringCharType, N1 s1, const fixed_size_stringCharType, N2 s2); An implementation of basic_string that uses the small string optimization already implements something very close to this. We don't need to specify an entirely new kind of string to benefit from this technique. True, for small strings. However, that particular technique doesn't work for larger strings. I just mentioned the above, since it appeared that much of the interest for static_string came from the lack of dynamical allocation, so I wanted to point out that you don't need compile-time computation for that. Naturally, a compile-time string would be much less expensive to copy around, though, since it's all encoded in the type, and there would be no run-time cost for many operations. Regards, Terje ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: CVS repository locked?
Beman Dawes wrote: At 11:04 AM 3/6/2003, Vladimir Prus wrote: I see this, when doing update: cvs server: [07:46:57] waiting for beman_dawes's lock in /cvsroot/boost/boost/tools/build . cvs server: [08:02:58] waiting for beman_dawes's lock in /cvsroot/boost/boost/tools/build Beman, is there anything you can do about it? Like killing client or updating again? Or ony sourceforge admins are in position to fix this? If it really was a hung lock, only the sourceforge people can unlock it. But more likely you just happened to access during the more than an hour it took to apply the merged_to_RC_1_30_0 tag. There was a delay of more than ten minutes right at the end with no apparent activity. I had this for more than 10 mins, but now everything's OK. I don't know why it took so long, unless it had to do with tagging at a past date rather than the current state. More than an hour? Well, tagging is O(N) is CVS, after all... - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BGL]edge connectivity code won't compile
Hi J-S, Hi, Volodya Following arethe error messages: -- \boost-g\boost_1_29_0\boost\property_map.hpp(151) : error C2039: 'reference' : is not a member of 'boost::property_traits' with [ PA=boost::default_color_type * ] g:\boost-g\boost_1_29_0\boost\graph\properties.hpp(52) : see declaration of 'boost::property_traits' with [ PA=boost::default_color_type * ] Could you please try adding typedef default_color_type reference; to the specialization of property_traits for default_color_type, which is in file boost/graph/properties.hpp (line 56 in CVS version) If this fixes the error, I'll make the fix in CVS. Basically, I got two errors: 1)C1076--I have changed from /Gm to /Zm1000, and it went way. Did you posted compiler output for this error, or I missed it? Thanks, Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] lexical_cast(Was: FYI)
From: Dave Gomboc [mailto:[EMAIL PROTECTED] Yeah, I was aware that work had been done on it, but as of a couple of days ago CVS had no change to lexical_cast.hpp, which is what prompted me to write my original query. Could whoever did the update please commit it to CVS? Kevlin Henney, the author of lexical_cast, is currently reviewing and brushing up some minor details in the proposal by Terje Slettebo (http://groups.yahoo.com/group/boost/files/lexical_cast_proposition/lexical_ cast_proposition.zip). It should only be a day or two before the CVS will contain the new version. I know that people have been waiting a _really_ long time for this to happen, and as has been stated before, the changes will be part of 1.30.0. To all of you who've been waiting, thanks for your patience! Bjorn Karlsson ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
