[boost] Re: Re: Re: is_class
On Wed, 05 Feb 2003 01:11:23 +0100, Paul Mensonides wrote: > Daniel Frey wrote: > >> Yes. My problem is that I still don't understand what Peter is trying >> to >> show and that makes me kind of nervous :) > > [deep breath] > > I think that he thought that you might have thought that the > cv-qualified specializations would match > pointers-to-cv-qualified-member-functions rather than just > cv-qualified-pointers-to-members. You may be right, but his questions were very... terse. If he can confirm this it would make me feel better :) Regards, Daniel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: io operations for stl containers?
This looks really neat - and potentially very useful. Sadly, array is one of the most interesting cases - so I'm sure I won't be the only one 'watching this space'. Thanks Paul PS composite_format is a bit long, but I can't suggest better. 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] > Looking at the error messages, and from what I've heard, it may be that it > has problems with template friends (which is what the operator<< is). If > that's the case, the workaround should be very easy - making it a > free-function template. > > I did that, now, and it works. :) > > At least the vector_pair_test(). The array2D_test() uses a little fancy > code, such as passing the type reference to array as a template parameter, > and it seems MSVC 7.0 has some problems with this. Anyway, that was just to > demonstrate usage with built-in types, as well, such as arrays. I'll look > into it. > > There wasn't really any need for it to be a friend function, as it didn't > access any private parts. It was just defined inside the class for > convenience. > > I've also tested it on Intel C++ 7.0 in strict mode and g++ 3.2, so the code > should be conformant, at least. > > Thanks for the report. I hadn't yet got around to do more portability > testing, but intend to do that, including writing more tests for it. I've > updated the version at Yahoo Groups with the above changes. > > > Regards, > > Terje > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Array support [wasSmartPtr(Loki)-auto_ptr/movec'torissue]
On Tuesday, February 4, 2003, at 10:56 PM, Paul Mensonides wrote: Howard Hinnant wrote: Custom deleter policy + implicit conversion policy - converting constructors - converting assignment operators == smart pointer that handles arrays. A custom deleter policy could prevent the use of converting ctors and assignment. Sounds promising. -Howard ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Array support [wasSmartPtr(Loki)-auto_ptr/movec'torissue]
Howard Hinnant wrote: > Custom deleter policy + implicit conversion policy - converting > constructors - converting assignment operators == smart pointer that > handles arrays. A custom deleter policy could prevent the use of converting ctors and assignment. Paul Mensonides ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Array support [was SmartPtr(Loki)-auto_ptr/movec'torissue]
Custom deleter policy + implicit conversion policy - converting constructors - converting assignment operators == smart pointer that handles arrays. -Howard ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Array support [was SmartPtr(Loki)-auto_ptr/movec'torissue]
Greg Colvin wrote: > At 07:25 PM 2/4/2003, Paul Mensonides wrote: >> ... >> >> If an implicit conversion to the pointed-to type is provided, there >> is no need to overload the subscript operator: >> >> ... >> >> The same applies to the standing problem of operator->*(). >> >> 2c. > > Yep. More reasons why I prefer that smart pointers have an > operator T*. But my view has always been a minority opinion, > in this as in so many other things. An implicit conversion could easily be an optional feature in a policy-based smart pointer. Custom deleter policy + implicit conversion policy == smart pointer that handles arrays. Paul Mensonides ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Array support [was SmartPtr (Loki)-auto_ptr/movec'torissue]
At 07:25 PM 2/4/2003, Paul Mensonides wrote: >... > >If an implicit conversion to the pointed-to type is provided, there is no need to >overload the subscript operator: > >... > >The same applies to the standing problem of operator->*(). > >2c. Yep. More reasons why I prefer that smart pointers have an operator T*. But my view has always been a minority opinion, in this as in so many other things. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Array support [was SmartPtr(Loki)-auto_ptr/movec'torissue]
Andrei Alexandrescu wrote:
>> I agree that vector (or vector-like substitutes) are preferred over
>> smart_ptr in most circumstances. But there are times when
>> ownership of the array needs to be transferred or shared. In those
>> instances, vector is not a good fit. smart_ptr > is a
>> possibility, but this is typically inferior both in performance, and
>> in client level syntax (e.g. (*p)[i] instead of p[i]).
>
> When designing an amenity, it is important to figure out how the
> alternatives work for its target audience. For the limited audience
> that (1) needs a smart pointer to an array and (2) is unhappy with
> vector's performance, I'd say it's ok to just advice using a SmartPtr
> configured
> with an array deleter and have them write get_impl(sp)[45] instead of
> sp[45]. The super-performance-critical code portions of an app are
> not that large and much uglier for different reasons anyway :o).
If an implicit conversion to the pointed-to type is provided, there is no need
to overload the subscript operator:
#include
struct sample {
inline operator const char*() const {
return "01234";
}
};
int main() {
sample var;
std::cout << var[0] << var[1] << &std::endl;
return 0;
}
The same applies to the standing problem of operator->*().
2c.
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Historical releases...
[2003-02-04] Beman Dawes wrote: >At 05:52 PM 2/4/2003, Rene Rivera wrote: > > >In a bout of cleaning, and wanting to learn about SourceForge file > >distribution... I put all the historical releases of Boost, and the >current > >also, in the SourceForge files distribution system. > >Thanks! Looks great! I was wondering who added the other releases and the >bjam files:-) > > > Also available now are > >bzip2 versions for those interested in smaller downloads. For details >see: > > > >http://sourceforge.net/project/showfiles.php?group_id=7586 > >I'll add bz2 files to future releases. Could you send me a copy of the >script or command you used? My knowledge of bzip2 is exactly zero, except >that I do see cygwin has supplied a version for my Windows box. > >Did you run the earlier ones with UNIX line endings? > >The .bz2 files are so much smaller than the .zip that I wouldn't be >surprised if we get asked to also supply the untranslated line ending files >in the .bz2 format. We'd need to come up with a distinctive naming >convention. The line endings on the bz2 files are exactly what they are in the gz files. The reason is that I took the gz files and recompressed them directly with bzip2. This is the command that I used: gunzip -c file.tar.gz | bzip2 > file.tar.bz2 > >With this the historical releases that usually are available on the > >boost.sourceforge.net/release, are no longer. Now only the latest release > > >is available there. > >I've also been trying out the SourceForge release system with good results. >It's really amazing how much easier it all became after they improved their >docs. > >Starting with the 1.30.0 release, the plan is to only make the SourceForge >file list the only download source. I've already updated more/download.html >in CVS. Ah, good, I was going to suggest we add a link to the SourceForge downloads :-) >Thanks again, You're welcome. -- grafik - Don't Assume Anything -- [EMAIL PROTECTED] - [EMAIL PROTECTED] -- 102708583@icq ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Boosters to speak at ACCU meeting in Silicon Valley area?
The following request came from Reg Charney, from the ACCU Silicon Valley chapter: >I was wondering if there are active Boost contributors in the Silicon >Valley area. I was hoping to invite one or two of them to come talk to >the ACCU here on Boost and what they are doing. Thanks. If you are interested, please contact him directly: charney at charneyday dot com. (I disguised his email address a bit; wasn't sure if he wanted it broadcast in harvestable form.) This might be an easy way to get some low-stress public speaking experience. Reg is a long-time member of the C++ committee, by the way. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Historical releases...
At 05:52 PM 2/4/2003, Rene Rivera wrote: >In a bout of cleaning, and wanting to learn about SourceForge file >distribution... I put all the historical releases of Boost, and the current >also, in the SourceForge files distribution system. Thanks! Looks great! I was wondering who added the other releases and the bjam files:-) > Also available now are >bzip2 versions for those interested in smaller downloads. For details see: > >http://sourceforge.net/project/showfiles.php?group_id=7586 I'll add bz2 files to future releases. Could you send me a copy of the script or command you used? My knowledge of bzip2 is exactly zero, except that I do see cygwin has supplied a version for my Windows box. Did you run the earlier ones with UNIX line endings? The .bz2 files are so much smaller than the .zip that I wouldn't be surprised if we get asked to also supply the untranslated line ending files in the .bz2 format. We'd need to come up with a distinctive naming convention. >With this the historical releases that usually are available on the >boost.sourceforge.net/release, are no longer. Now only the latest release >is available there. I've also been trying out the SourceForge release system with good results. It's really amazing how much easier it all became after they improved their docs. Starting with the 1.30.0 release, the plan is to only make the SourceForge file list the only download source. I've already updated more/download.html in CVS. >Now we are no longer overpassing the disk quota. And have space for those >lovely pictures of people that was suggested be moved :-) Yes, I'm planning to move those next week before the 1.30.0 branch for release. Thanks again, --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Results of Cray SV1 regression tests
At 05:06 PM 2/4/2003, Matthias Troyer wrote: >I have run the regression tests on a Cray SV1 system using the Cray C++ >3.6 compiler and posted the results on >http://www.comp-phys.org/boost/cs-sn9626.html Thanks, Matthias, those are really interesting. I'm always curious how C++ in general and Boost in particular does on systems other than the usual beige desktop boxes. Why don't you consider posting the results on SourceForge with the other results? It would be nice to use something that included "cray" rather than "sn9626" in the file names, and we ought to tweak the config to better identify the platform and compiler, but those are just nits. > >I have not looked at all the problems yet and will do so when I find >time. For now I have posted it just in case that someone (such as a >library author) is interested. > > One of the problems is that there is no int16_t type on the Cray SV1 >and other vector machines (with the exception of the newly announced X1 >on which int16_t exists but is very slow). Thus it might be good to add >a BOOST_NO_INT16_T macro in analogy to the BOOST_NO_INT64_T macro. > >Another problem is that the type long long exists but is not supported >by the standard library (e.g. the operator <<(std::ostream&, long long) >is not defined). Since long and long long are both 64 bit there is >actually no need to ever use long long. I'll have to check why long >long is used in some of the tests. > >There are a few other places where I guess that there is a compiler >problem, since I do believe that most of the boost code should be >standard conforming. Any comments by the experts are welcome. I took a look, and quite a few of the failures are tests that also have trouble on other compilers. Hopefully some of these will pass in the next week or two as we get ready for the release. There are probably have a few configuration issues to be worked out, but really it isn't a bad showing for a first try. config_info is reporting the compiler as using the EDG front-end, but not identifying the library. Whose copyrights are on the headers? As far as the filesystem library goes, the two run errors detected are really minor; the implementation seems to be reporting one error code differently from other POSIX systems, and it is allowing remove on a directory that is not empty. I can fix both of those problems if you can tell me some macro name that uniquely identifies Cray C++ (because the same problems aren't showing on other POSIX platforms.) Thanks for sharing your results! Most of us will never see a Cray, let alone test on one. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_class
Daniel Frey wrote:
[...]
>> I might be misunderstanding you, but the above does not match the
>> type "int (X::*)(long, double) const." E.g. if I have this template:
>
> I think you misunderstood me. I should have made it clearer what I was
> refering to when I wrote "matches the above specialization". By this I
> was refering to Peters question to find something that is taken by the
>
> template< class C, typename T >
> struct is_member_function_pointer< T C::* const >
> { enum { value = is_function< T >::value }; };
>
> specialization I provided. At least that is how I understood him.
[...]
> Yes. My problem is that I still don't understand what Peter is trying
> to
> show and that makes me kind of nervous :)
[deep breath]
I think that he thought that you might have thought that the cv-qualified
specializations would match pointers-to-cv-qualified-member-functions rather
than just cv-qualified-pointers-to-members.
[phew]
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: is_class
On Tue, 04 Feb 2003 23:10:39 +0100, Paul Mensonides wrote:
> Daniel Frey wrote:
>
>>> Yes, I worded that incorrectly. I should have said: are you thinking
>>> that the above will match
>>>
>>> int (X::*pf)(long, double) const;
>>
>> I'm not absolutely sure, but I think that this creates a non-const
>> pointer to a const member function. As far as I understand it, this is
>> equivalent to:
>>
>> typedef int ft( long, double ) const; ft X::* pf;
>
> Yes, the type of 'pf' is:
>
> int (X::*)(long, double) const;
>
>> To create something that matches to above specialization, you have to
>> do something like this:
>>
>> ft X::* const cpf;
>
> I might be misunderstanding you, but the above does not match the type
> "int (X::*)(long, double) const." E.g. if I have this template:
I think you misunderstood me. I should have made it clearer what I was
refering to when I wrote "matches the above specialization". By this I
was refering to Peters question to find something that is taken by the
template< class C, typename T >
struct is_member_function_pointer< T C::* const >
{ enum { value = is_function< T >::value }; };
specialization I provided. At least that is how I understood him.
> As I said, I may be misunderstanding you. If so, just consider it a
> clarification for everyone else. As is, the four specializations that
> you provided with catch any unqualified (first one) or qualified (other
> three) pointer-to-member. The nested call to 'is_function' should yield
> true if the pointed-to type a function type (cv-qualified or otherwise).
Yes. My problem is that I still don't understand what Peter is trying to
show and that makes me kind of nervous :)
Regards, Daniel
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Historical releases...
In a bout of cleaning, and wanting to learn about SourceForge file distribution... I put all the historical releases of Boost, and the current also, in the SourceForge files distribution system. Also available now are bzip2 versions for those interested in smaller downloads. For details see: http://sourceforge.net/project/showfiles.php?group_id=7586 With this the historical releases that usually are available on the boost.sourceforge.net/release, are no longer. Now only the latest release is available there. Now we are no longer overpassing the disk quota. And have space for those lovely pictures of people that was suggested be moved :-) Enjoy. -- grafik - Don't Assume Anything -- [EMAIL PROTECTED] - [EMAIL PROTECTED] -- 102708583@icq ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL Code bloat on GCC
On Tuesday, February 04, 2003 5:27 PM [GMT+1=CET], David A. Greene <[EMAIL PROTECTED]> wrote: > Jaap Suter wrote: > > > Try turning off debug symbols; GCC spends a long time and a lot of > > > disk generating them. > > > > > > Thanks, works excellent! In fact, my GCC object files and executables are > > the smallest now. > > Yep, I came to the same conclusion. Unfortunately, it does not help > much when you need to debug your program. :( Is any work being done > to fix gcc regarding the number and size of debug symbols being > generated? I don't know; submit a bug report with a reproducible test case: http://gcc.gnu.org/cgi-bin/gnatsweb.pl -- Dave Abrahams Boost Consulting http://www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL Code bloat on GCC
Jaap Suter wrote: Try turning off debug symbols; GCC spends a long time and a lot of disk generating them. Thanks, works excellent! In fact, my GCC object files and executables are the smallest now. Yep, I came to the same conclusion. Unfortunately, it does not help much when you need to debug your program. :( Is any work being done to fix gcc regarding the number and size of debug symbols being generated? Using MPL in anything but the most trivial ways causes big headaches with g++. -Dave -- "Some little people have music in them, but Fats, he was all music, and you know how big he was." -- James P. Johnson ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_class
Daniel Frey wrote:
>> Yes, I worded that incorrectly. I should have said: are you thinking
>> that the above will match
>>
>> int (X::*pf)(long, double) const;
>
> I'm not absolutely sure, but I think that this creates a non-const
> pointer to a const member function. As far as I understand it, this is
> equivalent to:
>
> typedef int ft( long, double ) const;
> ft X::* pf;
Yes, the type of 'pf' is:
int (X::*)(long, double) const;
> To create something that matches to above specialization, you have to
> do something like this:
>
> ft X::* const cpf;
I might be misunderstanding you, but the above does not match the type "int
(X::*)(long, double) const." E.g. if I have this template:
#include
template struct test {
enum { value = false };
};
template struct test {
enum { value = true };
};
struct X { };
typedef int (X::* Y)(long, double) const;
int main() {
std::cout
<< test::value // false
<< '\n'
<< test::value // true
<< &std::endl;
return 0;
}
In other words, "R C::* const" is a constant pointer-to-member, not a
pointer-to-const-member, and certainly not a pointer-to-const-member-function.
It *can* match a const-pointer-to-const-member-function, but then the
const-qualification of the member function would be hidden in the 'R' type.
> Anyway, what is the point of this? I specialize for a pointer and
> pointers can be cv-qualified, thus to be complete I have to provide
> specializations for all cv-versions, haven't I?
That is what I assumed that you meant when I saw those specializations. At this
point, I'm not sure, so I'm just clarifying that these two types are _not_
equivalent:
typedef void (X::* _1)() const;
typedef void F();
typedef F X::* const _2;
Type #1 is a pointer-to-const-qualified-member-function. Type #2 is a
const-pointer-to-unqualified-member-function.
As I said, I may be misunderstanding you. If so, just consider it a
clarification for everyone else. As is, the four specializations that you
provided with catch any unqualified (first one) or qualified (other three)
pointer-to-member. The nested call to 'is_function' should yield true if the
pointed-to type a function type (cv-qualified or otherwise).
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Results of Cray SV1 regression tests
Dear Boosters, I have run the regression tests on a Cray SV1 system using the Cray C++ 3.6 compiler and posted the results on http://www.comp-phys.org/boost/cs-sn9626.html I have not looked at all the problems yet and will do so when I find time. For now I have posted it just in case that someone (such as a library author) is interested. One of the problems is that there is no int16_t type on the Cray SV1 and other vector machines (with the exception of the newly announced X1 on which int16_t exists but is very slow). Thus it might be good to add a BOOST_NO_INT16_T macro in analogy to the BOOST_NO_INT64_T macro. Another problem is that the type long long exists but is not supported by the standard library (e.g. the operator <<(std::ostream&, long long) is not defined). Since long and long long are both 64 bit there is actually no need to ever use long long. I'll have to check why long long is used in some of the tests. There are a few other places where I guess that there is a compiler problem, since I do believe that most of the boost code should be standard conforming. Any comments by the experts are welcome. Matthias ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] integral_c on g++2.95.3
Joel de Guzman wrote: > I'm not sure if you are aware of this but g++ 2.95.3 cannot > handle the casts: [snip errors] > and I must revert to: > > #elif defined(__GNUC__) && (__GNUC__ < 3) > // g++ 2.95.3 cannot take the casts, > typedef integral_c next; > typedef integral_c prior; > #else > typedef integral_c(value + 1)> next; > typedef integral_c(value - 1)> prior; > #endif Fixed now in the CVS. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Array support [was SmartPtr (Loki)-auto_ptr/movec'torissue]
"Howard Hinnant" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > 1. Arrays of polymorphic objects don't work. > > Right. But to me that just means you don't want to have the member > template converting constructors/assignment in your array version of > the smart pointer (as shown in boost::shared_ptr/shared_array, and the > move_ptr example at > http://home.twcny.rr.com/hinnant/Utilities/move_ptr). > > > 2. If I wanna arrays of monomorphic objects I can use std::vector. > > True. > > > 3. If I wanna arrays of monomorphic objects and std::vector's > > performance > > is unsatisfactory to me, > > Naw, couldn't happen! ;-) > > > I can use the typed buffers > > (http://www.moderncppdesign.com/publications/cuj-08-2001.html, > > http://www.moderncppdesign.com/publications/cuj-10-2001.html, > > http://www.moderncppdesign.com/publications/cuj-12-2001.html) that are > > present in the up-and-coming YASLI. > > Up-and-coming? I was just getting used to "legendary"! :-) Be afraid. Be very afraid. :o) > > 4. So there's no reason I'd ever wanna have smart pointers to arrays. > > I agree that vector (or vector-like substitutes) are preferred over > smart_ptr in most circumstances. But there are times when > ownership of the array needs to be transferred or shared. In those > instances, vector is not a good fit. smart_ptr > is a > possibility, but this is typically inferior both in performance, and in > client level syntax (e.g. (*p)[i] instead of p[i]). When designing an amenity, it is important to figure out how the alternatives work for its target audience. For the limited audience that (1) needs a smart pointer to an array and (2) is unhappy with vector's performance, I'd say it's ok to just advice using a SmartPtr configured with an array deleter and have them write get_impl(sp)[45] instead of sp[45]. The super-performance-critical code portions of an app are not that large and much uglier for different reasons anyway :o). Andrei ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: io operations for stl containers?
>From: "Jason House" <[EMAIL PROTECTED]>
> Terje Slettebø wrote:
> > and given this:
> >
> > int main()
> > {
> > char board[3][3]=
> > {
> > {'O','X','O'},
> > {'X','X','O'},
> > {'O','O','X'}
> > };
> >
> > std::cout << io_format("\n|","|\n","|")
> > << io_format("---","---","---")
> > << board << '\n';
> > }
> >
> > we get:
> >
> > ---
> > |O|X|O|
> > ---
> > |X|X|O|
> > ---
> > |O|O|X|
> > ---
>
> Hey, that's pretty cool. I'm glad to see the ability to format items
> inside of a container as well.
I'm glad you like. :) Yes, it applies operator<< recursively, using
overloading, and any format settings for the given type, so for the outer
array, it matches the second format above, and for the inner it matches the
first one.
> It should handle maps and pairs
> reasonably well. I think that I have the same complaints about this as
> io_manip
>
> The saving of information to the stream means that you can affect all
> future output...
>
> For instance, if you have a type
> map >
>
> and custom_object's stream output uses io_format >, then
> you are going to run into trouble if it wants a different formatting.
Right. That's a consequence of this. As you say too, I don't know any
obvious alternatives, though.
Regards,
Terje
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: io operations for stl containers?
>From: "Paul A. Bristow" <[EMAIL PROTECTED]> > This looks most useful - potentionally :-( > > Alas the two files, test and composite_stream_operators.hpp > > http://groups.yahoo.com/group/boost/files/composite_stream_operators/). > > won't compile on MSVC 7.0. > > test_composite_format.cpp > test_composite_format.cpp(43) : error C2679: binary '<<' : no operator found > which takes a right-hand operand of type 'composite_format' (or there is no > acceptable conversion) > with > [ > T=char (&)[3] > ] > > and similarly for T=Map > > Is the cause/workaround obvious? Looking at the error messages, and from what I've heard, it may be that it has problems with template friends (which is what the operator<< is). If that's the case, the workaround should be very easy - making it a free-function template. I did that, now, and it works. :) At least the vector_pair_test(). The array2D_test() uses a little fancy code, such as passing the type reference to array as a template parameter, and it seems MSVC 7.0 has some problems with this. Anyway, that was just to demonstrate usage with built-in types, as well, such as arrays. I'll look into it. There wasn't really any need for it to be a friend function, as it didn't access any private parts. It was just defined inside the class for convenience. I've also tested it on Intel C++ 7.0 in strict mode and g++ 3.2, so the code should be conformant, at least. Thanks for the report. I hadn't yet got around to do more portability testing, but intend to do that, including writing more tests for it. I've updated the version at Yahoo Groups with the above changes. Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Smart pointers: One more implementation + question
"Pavel Vasiliev" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > >>I would like to offer for discussion one more implementation of reference > > counting smart pointer.< > > [snip] > > > Howgh! > > > Andrei > > :-) In general, I agree with you. 1024-th smart pointer is 1023-rd > wheel reinvented. But The Best Wheel is still to be found. > > Nevertheless, thanks for reply, even for the such one. Obviously you missed the delights of reading Karl May's Winnetou when you were a kid :o). > refc_ptr is not a science-intensive implementation like > Loki::SmartPtr<>. It rather oriented to practical needs. > > The following syntax is employed: > > refc_ptr spU = new shell_xx(args); > > where shell_xx is one of "reference counting shells for objects of > type T". With some "shells" refc_ptr is the same as > boost::shared_ptr/weak_ptr, with others - is similar to > boost::intrusive_ptr, or to shifted_ptr, etc. All with the only > class refc_ptr; all types of reference counting are almost > transparent for a client. Looks great. However, all these behaviors can be, and most were, trivially implemented as policies of SmartPtr, while benefitting of all the extra amenities, which all your pointers are lacking. Seems, however, that I need to refocus my efforts of convincing people that SmartPtr is the way to go and design within its framework - the kavorka of implementing one's own pet smart pointer is way too overwhelming :o). Andrei ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: io operations for stl containers?
Terje Slettebø wrote:
From: "Vladimir Prus" <[EMAIL PROTECTED]>
Terje Slettebø wrote:
[snip]
std::cout << io_format("\n|","|\n","|")
<< io_format("---","---","---")
<< board << '\n';
}
we get:
---
|O|X|O|
---
|X|X|O|
---
|O|O|X|
---
I've used marg_ostream to format output for containers; however,
it only used something that changed the margin. I had to
use an ostream<< for the particular composite to get it to work.
However, being able to adjust the margin seems useful for
formating most code. Looking at the code might give you
some more ideas about your io_format. Unfortunately, marg_ostream
requires wrapping the cout in a marg_ostream.
Anyhow, the code is in boost files in shared_cyclic_ptr/shared_cyclic_ptr.zip
in boost/col_io directory. Basically, marg_ostream++ increments the
margin and marg_ostream-- decrements the margin. You can also specify
what's in the margin. This was used to show the nesting in a fortran
program in a parallelizing compiler.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: io operations for stl containers?
Terje Slettebø wrote:
> and given this:
>
> int main()
> {
> char board[3][3]=
> {
> {'O','X','O'},
> {'X','X','O'},
> {'O','O','X'}
> };
>
> std::cout << io_format("\n|","|\n","|")
> << io_format("---","---","---")
> << board << '\n';
> }
>
> we get:
>
> ---
> |O|X|O|
> ---
> |X|X|O|
> ---
> |O|O|X|
> ---
Hey, that's pretty cool. I'm glad to see the ability to format items
inside of a container as well. It should handle maps and pairs
reasonably well. I think that I have the same complaints about this as
io_manip
The saving of information to the stream means that you can affect all
future output...
For instance, if you have a type
map >
and custom_object's stream output uses io_format >, then
you are going to run into trouble if it wants a different formatting.
I don't know the right way to solve that problem though.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: some more questions on MPL and Borland
Joel de Guzman wrote:
> Hi,
>
> Borland cannot handle this code:
>
> #include
> #include
>
> using namespace boost;
> using namespace boost::mpl;
>
> struct A {};
> struct B {};
>
> template
> struct C : if_, A, B>::type {};
>
> struct D { int i; };
> struct E {};
>
> struct F : C {};
> struct G : C {};
>
Look at my recent thread: "Current is_convertible borken for bcc5.5.1",
In my last message I posted a fix for bcc5.5.1.
--
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: io operations for stl containers?
This looks most useful - potentionally :-( Alas the two files, test and composite_stream_operators.hpp http://groups.yahoo.com/group/boost/files/composite_stream_operators/). won't compile on MSVC 7.0. test_composite_format.cpp test_composite_format.cpp(43) : error C2679: binary '<<' : no operator found which takes a right-hand operand of type 'composite_format' (or there is no acceptable conversion) with [ T=char (&)[3] ] and similarly for T=Map Is the cause/workaround obvious? Thanks Paul Full messages: test_composite_format.cpp test_composite_format.cpp(29) : error C2679: binary '<<' : no operator found which takes a right-hand operand of type 'composite_format' (or there is no acceptable conversion) with [ T=Map ] j:\Cpp\composite_format\composite_stream_operators.hpp(42) : warning C4933: 'std::basic_ostream &operator <<(std::basic_ostream &,const basic_composite_format &)' and 'std::basic_ostream &operator <<(std::basic_ostream &,const basic_composite_format &)' only differ by top-level CV-qualifiers in their arguments. This usage is deprecated and may be an error in the future with [ CharType=char, T=char (&)[3] ] j:\Cpp\composite_format\composite_stream_operators.hpp(42) : see declaration of 'operator`<<'' j:\Cpp\composite_format\composite_stream_operators.hpp(42) : see declaration of 'operator`<<'' j:\Cpp\composite_format\composite_stream_operators.hpp(83) : see reference to class template instantiation 'basic_composite_format' being compiled with [ CharType=char, T=char (&)[3] ] test_composite_format.cpp(42) : see reference to class template instantiation 'composite_format' being compiled with [ T=char (&)[3] ] test_composite_format.cpp(43) : error C2679: binary '<<' : no operator found which takes a right-hand operand of type 'composite_format' (or there is no acceptable conversion) with [ T=char (&)[3] ] j:\Cpp\composite_format\composite_stream_operators.hpp(42) : warning C4933: 'std::basic_ostream &operator <<(std::basic_ostream &,const basic_composite_format &)' and 'std::basic_ostream &operator <<(std::basic_ostream &,const basic_composite_format &)' only differ by top-level CV-qualifiers in their arguments. This usage is deprecated and may be an error in the future with [ CharType=char, T=char (&)[3][3] ] j:\Cpp\composite_format\composite_stream_operators.hpp(42) : see declaration of 'operator`<<'' j:\Cpp\composite_format\composite_stream_operators.hpp(42) : see declaration of 'operator`<<'' j:\Cpp\composite_format\composite_stream_operators.hpp(83) : see reference to class template instantiation 'basic_composite_format' being compiled with [ CharType=char, T=char (&)[3][3] ] test_composite_format.cpp(43) : see reference to class template instantiation 'composite_format' being compiled with [ T=char (&)[3][3] ] Build log was saved at "file://j:\Cpp\composite_format\Debug\BuildLog.htm" composite_format - 2 error(s), 2 warning(s) and for simpler tests like a pair, vector ... test_composite_format.cpp(25) : error C2679: binary '<<' : no operator found which takes a right-hand operand of type 'composite_format' (or there is no acceptable conversion) with [ T=std::pair ] test_composite_format.cpp(36) : error C2679: binary '<<' : no operator found which takes a right-hand operand of type 'composite_format' (or there is no acceptable conversion) with [ T=std::vector> ] test_composite_format.cpp(37) : error C2679: binary '<<' : no operator found which takes a right-hand operand of type 'composite_format' (or there is no acceptable conversion) with [ T=std::vector> ] > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Terje Slettebø > Sent: Tuesday, February 04, 2003 1:46 PM > To: Boost mailing list > Subject: Re: [boost] Re: io operations for stl containers? > > > >From: "Vladimir Prus" <[EMAIL PROTECTED]> > > > Terje Slettebø wrote: > > > > > Incidentally, I've just made a version that does exactly this. :) I've > > > attached it, including a test, with this posting. > > > > I've take a look and I like it -- quite lean and does the work. > > Thanks. :) > > > I've some concerns, though: > > > > 1. Are "default" breaces/separators possible? I'd rather not use > > io_format every time I had to output a vector. > > Good point. As it is now, it just defaults to empty strings for the > separators. Any idea how to specify such a default? If it's specified in the > header, it may be hard to select one that
Re: [boost] Previously GPL'd Code
On Thu, Jan 30, 2003 at 03:10:10PM -0500, David Abrahams wrote: > If it was ever accepted by GNU, I think the authors had to sign it > over to the FSF. Did they? Does that matter? I don't know the > answers. It does but I believe the usual agreement used by the FSF gives the original authors the option of getting a license from the FSF at any time to redistribute the code under whatever terms they see fit. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: integral_c on g++2.95.3
Dave Abrahams wrote: > On Tuesday, February 04, 2003 8:05 AM [GMT+1=CET], > Joel de Guzman <[EMAIL PROTECTED]> wrote: > >> Yup, this works: >> >> #elif defined(__GNUC__) && (__GNUC__ < 3) >> // g++ 2.95.3 cannot take static_cast the casts, >> typedef integral_c next; >> typedef integral_c prior; > > Hey, does that one work for Borland, too? Maybe we could get rid of the > conditionals? The conditionals for using 'N' instead of 'value' are still needed. The c-style cast works, though. -- Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Current is_convertible borken for bcc5.5.1
John Maddock wrote:
>> I was just about to build the filesystem library for the first time
>> on my Win98+BCC 5.5.1 environment, but I got lots of errors from
>> "type_traits/is_convertible.hpp"
>> Since the regression_test shows that this library passed bcc5.6.1
> yesterday,
>> I thought that is_convertible might have changed today. Indeed,
>> version
> 1.10
>> (the previous) works fine. (that is, I was able to build the FS
>> library)
>>
>> I attach here the compiler output using the -Q compiler option (which
> shows
>> extended error information).
>
> It's a builder 5.5.1 bug: is_convertible does not work correctly with
> that compiler (and never has), when one To parameter has a user
> defined constructor.
>
But the problem is that is_convertible<> is currently being used
by, at least, the filesystem library in a way that doesn't work any
more with bcc5.5.1; while it did. The recent changes allowed it to
keep working with bcc5.6 which is why the regression tests didn't
show the problem, but it broke bcc5.5.1.
The following fix, for bcc5.5.1, reverts the is_convertible
definition to the way it was on version1.10.
#if BOOST_WORKAROUND(_BORLANDC_, < 0x560 )
BOOST_TT_AUX_BOOL_TRAIT_DEF2(is_convertible,From,To,(::boost::detail::is_con
vertible_impl::value))
#else
template
struct is_convertible_forwarder
{
typedef typename add_reference::type ref_type;
BOOST_STATIC_CONSTANT(bool, value =
(::boost::type_traits::ice_and<
::boost::detail::is_convertible_impl::value,
::boost::type_traits::ice_not<
::boost::is_array::value
>::value
>::value)
);
};
BOOST_TT_AUX_BOOL_TRAIT_DEF2(is_convertible,From,To,::boost::detail::is_conv
ertible_forwarder::value))
#endif
--
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] integral_c on g++2.95.3
On Tuesday, February 04, 2003 8:05 AM [GMT+1=CET], Joel de Guzman <[EMAIL PROTECTED]> wrote: > Yup, this works: > > #elif defined(__GNUC__) && (__GNUC__ < 3) > // g++ 2.95.3 cannot take static_cast the casts, > typedef integral_c next; > typedef integral_c prior; Hey, does that one work for Borland, too? Maybe we could get rid of the conditionals? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Smart pointers: One more implementation + question
>>I would like to offer for discussion one more implementation of reference > counting smart pointer.< > [snip] > Howgh! > Andrei :-) In general, I agree with you. 1024-th smart pointer is 1023-rd wheel reinvented. But The Best Wheel is still to be found. Nevertheless, thanks for reply, even for the such one. --- refc_ptr is not a science-intensive implementation like Loki::SmartPtr<>. It rather oriented to practical needs. The following syntax is employed: refc_ptr spU = new shell_xx(args); where shell_xx is one of "reference counting shells for objects of type T". With some "shells" refc_ptr is the same as boost::shared_ptr/weak_ptr, with others - is similar to boost::intrusive_ptr, or to shifted_ptr, etc. All with the only class refc_ptr; all types of reference counting are almost transparent for a client. Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Array support [was SmartPtr (Loki) - auto_ptr/move c'tor issue]
At 03:35 AM 2/4/2003, Andrei Alexandrescu wrote: >"Beman Dawes" <[EMAIL PROTECTED]> wrote in message >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... >> * Should a PBSP supply policies that are prone to be used unsafely? >> >> I'd say "no" is an acceptable answer, at least for something like the T* >> conversion in widely used libraries like the Standard Library and Boost. >> >> * Should a PBSP allow user supplied policies to modify interface, perhaps >> in ways that may be unsafe or even just unfortunate? >> >> That's tougher. At some point I lose interest in a PBSP if it prevents me >> from doing the things I want to do, even if I only want to do them in the >> privacy of my own code. > >The original SmartPtr design leaves the onus of choosing the right policy >combination to the application designer. To me, that's a design I find >reasonable and in keep with the spirit of C++. Safer designs are possible >that reject policy combinations that "don't go together" at the price of >being more complicated or less efficient or less flexible. Yes, understood. One of the advantages of a generative approach is the improved ability to reject invalid policy combinations. In the generative experiments I tried a couple of years ago, there wasn't a problem with added complexity or less efficiency, but the result was definitely less flexible. A GenVoca or curiously recurring template pattern hierarchy might be able to solve all those problems, but they were at the boundary of my skill level, so I never tried them. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [OT] Bad Quoting and Outlook Express
On Tuesday, February 04, 2003 9:53 AM [GMT+1=CET], Lars Gullik Bjønnes <[EMAIL PROTECTED]> wrote: > "Joel de Guzman" <[EMAIL PROTECTED]> writes: > > > > I'm pretty sure I'm going to be switching back to Outlook Express from > > > emacs/GNUs because of this (and the many joys of OE). I'm using it > > > right now, and it "just works!" I think I was slightly premature about that. It improves things vastly, but there is still some formatting that you can't clean up as easily in OE as you can in GNUs. > I must admit that I do not understand why anyone would switch away > from Gnus. > > What do you find cumbersome about it? > (Gnus is probably probably nicer to use on Unix than on Win...) I'm going to take this off-list with Lars, since it's OT. Send me private email if you're interested. --- Dave Abrahams Boost Consulting http://www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: About the static_log2 discussions
On Tue, 4 Feb 2003 02:20:14 -0500, Daryle Walker <[EMAIL PROTECTED]> wrote: >I haven't been following Boost that much lately. Spent the past few >days catching up. > >Some people have been discussing changes to the algorithm used by >static_log2 lately. Yes. Thanks for intervening. To be more precise, the issue is not about the algorithm per se, but about the combination algorithm used + its (compile-time) C++ implementation. > Actually, I've forgotten why I used the >implementation I did. I sometimes tend to be verbose in my code; >hopefully compilers can optimize some of it out. Also, when you see an >algorithm looking more complex than you think it should, be mindful >that the code may be bigger to workaround some gotchas that the simpler >alternative doesn't consider. Yes, I asked also to see if this was the reason. >The newer code I've seen on the list uses the same ideas as the current >code, but there are enough differences that I have questions about. > >1. The current static_log2_helper_t uses three template arguments, the >new code only uses two. I guess there's some merging of the Place and >Index uses; can you explain further. Er... I would like to. Unfortunately I haven't understood how the current implementation works. >2. The base case of the new code uses fully specialized >static_log2_impl<1,0>, while the current code uses a partially >specialized static_log2_helper_t (which requires >workarounds for some compilers). One of the posts implied that the "1" >in the first template argument is guaranteed in the usual >circumstances. Can you explain further, including how to ensure that >the usual circumstances occur. Yes. I have attached the full code here. Basically the reason why, when n=0, you always end up with x=1 relies on how you choose the initial value of n and what preconditions holds at each recursion. The proof is easy but maybe it's better going with an informal explanation. Let w be the width (number of value bits) of an unsigned long: then choose_initial_n chooses the maximum power of two, say 'ni', such as: 2**p = ni < w For instance, with 32 bit unsigned longs, it chooses 16. This number is the initial shift count if the value x of which you want to compute the logarithm is >= 65536. Of course if x>=65536 this means that its binary representation has at least one bit set in a position >=16. Basically, the algorithm "constructs" the logarithm as sum of powers of two, i.e. it acts as if you built the binary representation of the logarithm itself. Suppose e.g that x = 192 = 128 + 64; in this case the logarithm, 7, is constructed as 1+2+4. More precisely, you start with n = 16, but continue without shifting x until you reach (by repeatedly dividing n by two) n = 4. Note that the initial n _is_ a power of two, so it is still a power of two at each recursion, except the last one where it is zero. Now you have x>>4 >0, thus L>=4 and thus L = 4 + some other non negative integer Note that you shift x by a certain amount n only if you are sure that that amount doesn't causes your left-most bit 1 to "go out" on the right; this means that you never end up with x = 0. In other words: x>=1 at each recursion. Now, could you end up with a number x different from both 1 and 0? No, because whatever number x != 0 you have at each recursion - it can't be >= 2**(value of n in the previous recursion step), otherwise it would have been shifted at that step. [well, except for the very first one, in which this precondition is enforced by choose_initial_n] This means that when you reach n = 0 (which happens necessarily) your x is greater than zero and smaller than 2**(1) = 2, i.e it is 1! :-) To track down the behavior in the example above: log2(192) = 4 + log2(192/16) = 4 + log2(12) // note that 12 < 2**4 4 + 2 + log2(12/4) = 6 + log2(3) // "" 3 < 2**2 4 + 2 + 1 + log2(3/2) = 7 + log2(1) >3. One reason for the timing differences could be that the current code >has an extra masking step that the new code doesn't have. Is the >masking I'm doing really needed? I'm sorry to not be helpful for this question, because I haven't dug that much into the current implementation. Before doing any further investigation, I asked here why it was chosen, but then Vesa Karvonen proposed the algorithm above and I gave up looking at the old one. BTW, note that the new code works even if unsigned long has padding bits, without using std::numeric_limits. This is particularly important for me because I wanted to propose a clean up for the std::numeric_limits implementation we have for broken compilers (boost/detail/limits.hpp). The idea to do the clean up is that members such as digits and digits10 can be computed; for instance: digits = 1 + static_log2 :: value> :: value; Actually the above leads to another change I wanted to propose for the Integer library: the current integer_traits<> a
Re: [boost] Re: io operations for stl containers?
>From: "Vladimir Prus" <[EMAIL PROTECTED]> > Terje Slettebø wrote: > > > There are also some other issues: The current version assumes basic_string > > for the delimiters. I've found it hard to let it take an arbitrary string > > type, as the format-object (which the manipulator, basic_composite_format, > > doubles as) stores a format parameterised on type to output and character > > type. The latter is so that if multiple streams with different character > > types are used, they should not use the same format-object.. > > Is assuming basic_string really a problem? No, not really. I was just thinking of generality. However, as it is, it needs the character type, anyway. > > By the way, just for fun. Adding the following output operator for arrays, > > to the header I gave in the previous posting: > > > --- > > |O|X|O| > > --- > > |X|X|O| > > --- > > |O|O|X| > > --- > > > > "Shall we play a game?" :) > > Sure thing :-) I guess you maybe got the "War Games" reference? :) > > I've uploaded the new version here > > (http://groups.yahoo.com/group/boost/files/composite_stream_operators/). > > There are two more points: > 1. Could you put this to the sandbox, too. Yahoogroups is less convenient. Sure. :) > 2. I think that we better have separate headers for stl containers, like > suggested in my original email (, etc). That's > because I'd like to output maps, but would not like to include when > I need to output a vector. Heh, just before I got this posting, I had added the following comment in the header: /// // The following are just a few examples of output operators, for some of the // containers and types in the standard library. These could well be separated // in other files. That would also reduce the number of includes. /// :) Will do. I'll get back to your other comments, I just need to look more into how it might be done. Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [OT] Bad Quoting and Outlook Express
"Joel de Guzman" <[EMAIL PROTECTED]> writes: | > I'm pretty sure I'm going to be switching back to Outlook Express from | > emacs/GNUs because of this (and the many joys of OE). I'm using it | > right now, and it "just works!" I must admit that I do not understand why anyone would switch away from Gnus. What do you find cumbersome about it? (Gnus is probably probably nicer to use on Unix than on Win...) -- Lgb ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: io operations for stl containers?
Beman Dawes wrote: At 03:22 AM 2/4/2003, Vladimir Prus wrote: >Terje Slettebø wrote: >... Have you looked at Jen Maurer's persistence library? It was an elegant design and quite good at handling the issues you are discussing, IIRC. It is still in CVS under the branch "persistence-initial". Beman, that's not presicely what I needed. Using persistence to output a single vector is still very verbose, compared with operator<<. shift_writer w(cout); save(v, w); I've always been sorry Jens lost interest in carrying it forward to formal review. Me too. - Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [filesystem] compile warnings
At 04:47 AM 2/4/2003, Vladimir Prus wrote: > >Beman, I've just got the following: > >gcc.compile >../../../libs/filesystem/build/bin/gcc-3.2/release/link-static/operations_po >six_windows.o >../../../libs/filesystem/src/operations_posix_windows.cpp: In member >function >`boost::filesystem::directory_iterator::directory_iterator(const >boost::filesystem::path&)': >../../../libs/filesystem/src/operations_posix_windows.cpp:210: warning: >`const >char*name' might be used uninitialized in this function >../../../libs/filesystem/src/operations_posix_windows.cpp: In member >function >`boost::filesystem::directory_iterator::directory_iterator(const >boost::filesystem::path&)': >../../../libs/filesystem/src/operations_posix_windows.cpp:210: warning: >`const >char*name' might be used uninitialized in this function >../../../libs/filesystem/src/operations_posix_windows.cpp: In function >`void >boost::filesystem::copy_file(const boost::filesystem::path&, const >boost::filesystem::path&)': >../../../libs/filesystem/src/operations_posix_windows.cpp:383: warning: >`int >outfile' might be used uninitialized in this function > >This shows up during release builds only. I've looked at warnings, and >in first case gcc is just not smart enough -- but would be nice to >eliminate the warning. In the other case the warning is correct, AFAICT. The second case is actually incorrect too. The indent was wrong on the throw, so it wasn't obvious that an exception is thrown in the only case where outfile isn;t initialized. I've added otherwise unneeded initialization in both cases to quiet the compiler warnings. Thanks, --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_class
Peter Dimov wrote: > > From: "Daniel Frey" <[EMAIL PROTECTED]> > > Peter Dimov wrote: > > > > > > Are you sure that "T C::* const" is a type? > > > > Isn't it? It's a constant pointer to a member of class C. T may be the > > type of a member variable or (although GCC don't detect it) a function > > type. At least this is my current understanding. Do you have a reason to > > ask about it? I think so, but I can't see it... > > Yes, I worded that incorrectly. I should have said: are you thinking that > the above will match > > int (X::*pf)(long, double) const; I'm not absolutely sure, but I think that this creates a non-const pointer to a const member function. As far as I understand it, this is equivalent to: typedef int ft( long, double ) const; ft X::* pf; To create something that matches to above specialization, you have to do something like this: ft X::* const cpf; Anyway, what is the point of this? I specialize for a pointer and pointers can be cv-qualified, thus to be complete I have to provide specializations for all cv-versions, haven't I? 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
[boost] Re: io operations for stl containers?
Terje Slettebø wrote:
I've some concerns, though:
1. Are "default" breaces/separators possible? I'd rather not use
io_format every time I had to output a vector.
Good point. As it is now, it just defaults to empty strings for the
separators. Any idea how to specify such a default? If it's specified in the
header, it may be hard to select one that is sensible for all people.
I've no problems with hardcoding. But if you want, you might user static
members of the same class which provides pword() index via another static
method. And there should be default default.
2. Is that good idea to set brace style on vector and vector
separately? It would increase pword() array, and not sure if this will
benefit us much. Are nested containers the primary motivation?
Another good point. I guess there isn't any point in separate formats for
different element types, no.
The way it works now is that it instantiates an
basic_composite_format (name changed from
basic_io_format), containing a static function with a static xalloc() index,
for each type to be output. Thus, it's parameterised on a type, not a
partially specified type.
Yes, I've see that too.
I'll look into this, as well. Partial specialisation, inheriting from a
less-parameterised base comes to mind.
Hmm... I bet you'd need template template parameters for that.
template class container>
class basic_composite_format {
};
Alas, this is not very allocator-friendly :-(
There are also some other issues: The current version assumes basic_string
for the delimiters. I've found it hard to let it take an arbitrary string
type, as the format-object (which the manipulator, basic_composite_format,
doubles as) stores a format parameterised on type to output and character
type. The latter is so that if multiple streams with different character
types are used, they should not use the same format-object..
Is assuming basic_string really a problem?
By the way, just for fun. Adding the following output operator for arrays,
to the header I gave in the previous posting:
int main()
{
char board[3][3]=
{
{'O','X','O'},
{'X','X','O'},
{'O','O','X'}
};
std::cout << io_format("\n|","|\n","|")
<< io_format("---","---","---")
<< board << '\n';
}
we get:
---
|O|X|O|
---
|X|X|O|
---
|O|O|X|
---
"Shall we play a game?" :)
Sure thing :-)
The names and interface is just chosen tentatively, and I'm open to
suggestions for better names. I changed the "*io_format" names to
"*composite_format", as it reflects better what it does, and reduces the
chance for name collision. I didn't want to call it container_format, or
something like that, as it's not restricted to containers, but may output
any composite object, given suitably defined output operators (such as
std::vector, std::pair, arrays, etc.)
I like the names.
Thanks for the feedback.
You're welcome. After all, it's me who's bored to use custom code ;-)
I've uploaded the new version here
(http://groups.yahoo.com/group/boost/files/composite_stream_operators/).
There are two more points:
1. Could you put this to the sandbox, too. Yahoogroups is less convenient.
2. I think that we better have separate headers for stl containers, like
suggested in my original email (, etc). That's
because I'd like to output maps, but would not like to include when
I need to output a vector.
What do you think?
- Volodya
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] mpl::is_sequence< incomplete_type >?
Hi there
I tried to use mpl::is_sequence<> on an incomplete type and ran into errors
suggesting that the argument must not be incomplete (I'm using MSVC 7.0). I
assume this cannot be fixed, right?
Thanks,
Andreas
P.S. I'm compiling code similar to the following:
template< class InnerInitial >
struct build_inner_initial_list : public mpl::apply_if<
mpl::is_sequence< InnerInitial >,
mpl::identity< InnerInitial >,
mpl::identity< mpl::list< InnerInitial > > > {};
class X;
int main()
{
typedef build_inner_initial_list< X >::type whatever;
}
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: some more questions on MPL and Borland
Vladimir Prus wrote: >> I just updated from CVS before posting this to be sure. >> >> Borland 5.5.1, >> bcc32 -O1 -w-inl -w-aus -q -P > > Yes, this fails for me too, *after update*. I meant to say that ~ > week's > old CVS was ok. Guess you'll have to do binary search in time to > find out who and when broke this. Yaiks! I hope it gets fixed soon. Spirit has been committed to the boost CVS now and I just switched to MPL so Spirit relies on MPL now. Thanks, Volodya! Joel de Guzman [EMAIL PROTECTED] http://www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: io operations for stl containers?
>From: "Vladimir Prus" <[EMAIL PROTECTED]>
> Terje Slettebø wrote:
>
> > Incidentally, I've just made a version that does exactly this. :) I've
> > attached it, including a test, with this posting.
>
> I've take a look and I like it -- quite lean and does the work.
Thanks. :)
> I've some concerns, though:
>
> 1. Are "default" breaces/separators possible? I'd rather not use
> io_format every time I had to output a vector.
Good point. As it is now, it just defaults to empty strings for the
separators. Any idea how to specify such a default? If it's specified in the
header, it may be hard to select one that is sensible for all people.
> 2. Is that good idea to set brace style on vector and vector
> separately? It would increase pword() array, and not sure if this will
> benefit us much. Are nested containers the primary motivation?
Another good point. I guess there isn't any point in separate formats for
different element types, no.
The way it works now is that it instantiates an
basic_composite_format (name changed from
basic_io_format), containing a static function with a static xalloc() index,
for each type to be output. Thus, it's parameterised on a type, not a
partially specified type.
I'll look into this, as well. Partial specialisation, inheriting from a
less-parameterised base comes to mind.
There are also some other issues: The current version assumes basic_string
for the delimiters. I've found it hard to let it take an arbitrary string
type, as the format-object (which the manipulator, basic_composite_format,
doubles as) stores a format parameterised on type to output and character
type. The latter is so that if multiple streams with different character
types are used, they should not use the same format-object..
This means that one must know the character type of the delimiter strings,
in order to parameterise the format object correctly. That's why
basic_string is used, as you then get access to the character type.
By the way, just for fun. Adding the following output operator for arrays,
to the header I gave in the previous posting:
///
// operator<<(stream,T[N])
///
template
std::basic_ostream &operator<<
(std::basic_ostream &stream,T (&array)[N])
{
typedef basic_io_format format_type;
const format_type &format=format_type::format(stream);
stream << format.start << array[0];
for(std::size_t i=1;i!=N;++i)
stream << format.delimiter << array[i];
stream << format.end;
return stream;
}
and given this:
int main()
{
char board[3][3]=
{
{'O','X','O'},
{'X','X','O'},
{'O','O','X'}
};
std::cout << io_format("\n|","|\n","|")
<< io_format("---","---","---")
<< board << '\n';
}
we get:
---
|O|X|O|
---
|X|X|O|
---
|O|O|X|
---
"Shall we play a game?" :)
By the way, in the first posting, I figured you knew about stream iterators,
so I was a little puzzled, but then it turned out I had just misunderstood
what you meant. Reading it more carefully later, I saw that you did mention
stream operators.
The names and interface is just chosen tentatively, and I'm open to
suggestions for better names. I changed the "*io_format" names to
"*composite_format", as it reflects better what it does, and reduces the
chance for name collision. I didn't want to call it container_format, or
something like that, as it's not restricted to containers, but may output
any composite object, given suitably defined output operators (such as
std::vector, std::pair, arrays, etc.)
Thanks for the feedback.
I've uploaded the new version here
(http://groups.yahoo.com/group/boost/files/composite_stream_operators/).
Regards,
Terje
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_class
From: "Daniel Frey" <[EMAIL PROTECTED]> > Peter Dimov wrote: > > > > Are you sure that "T C::* const" is a type? > > Isn't it? It's a constant pointer to a member of class C. T may be the > type of a member variable or (although GCC don't detect it) a function > type. At least this is my current understanding. Do you have a reason to > ask about it? I think so, but I can't see it... Yes, I worded that incorrectly. I should have said: are you thinking that the above will match int (X::*pf)(long, double) const; ? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: some more questions on MPL and Borland
Joel de Guzman wrote:
- Original Message -
From: "Vladimir Prus" <[EMAIL PROTECTED]>
Joel de Guzman wrote:
Hi,
Borland cannot handle this code:
#include
#include
using namespace boost;
using namespace boost::mpl;
struct A {};
struct B {};
template
struct C : if_, A, B>::type {};
Just tried. Works pretty fine. My CVS tree might be a week old, or so.
Also, maybe 'if_c<::boost::is_empty::value, A, B>' will work. Did
the same with 'is_same' recently.
I just updated from CVS before posting this to be sure.
Borland 5.5.1,
bcc32 -O1 -w-inl -w-aus -q -P
Yes, this fails for me too, *after update*. I meant to say that ~ week's
old CVS was ok. Guess you'll have to do binary search in time to
find out who and when broke this.
- Volodya
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_class
Peter Dimov wrote: > > Are you sure that "T C::* const" is a type? Isn't it? It's a constant pointer to a member of class C. T may be the type of a member variable or (although GCC don't detect it) a function type. At least this is my current understanding. Do you have a reason to ask about it? I think so, but I can't see it... 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] io operations for stl containers?
At 03:22 AM 2/4/2003, Vladimir Prus wrote: >Terje Slettebø wrote: >... Have you looked at Jen Maurer's persistence library? It was an elegant design and quite good at handling the issues you are discussing, IIRC. It is still in CVS under the branch "persistence-initial". I've always been sorry Jens lost interest in carrying it forward to formal review. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Bad Quoting and Outlook Express
Dave Abrahams wrote: > Hey all you Outlook Express users - if you're tired of sending mangled > emails, like this: > > >> "Dominik Jain" wrote in message >> news:aip4cd$15eofi$[EMAIL PROTECTED]... >>> This is a simple sample text, and as you will see, Outlook Express >>> is going to wrap this line. I've always hated that! And one night I >>> said to myself, "It can't go on like this". And so I wrote >>> OE-QuoteFix... > > > > check out this free utility: > http://home.in.tum.de/~jain/software/oe-quotefix/ > > I'm pretty sure I'm going to be switching back to Outlook Express from > emacs/GNUs because of this (and the many joys of OE). I'm using it > right now, and it "just works!" > > improving-quality-of-life-for-all-boosters-ly y'rs, > Dave > > P.S. I'm tempted to suggest that we should link to this on our website > and/or in our welcome email. FINALLY! I am using it now. What a joy :-) Yes, please make the link visible somewhere. It will do a lot of good. Joel de Guzman [EMAIL PROTECTED] http://www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: some more questions on MPL and Borland
- Original Message -
From: "Vladimir Prus" <[EMAIL PROTECTED]>
> Joel de Guzman wrote:
> > Hi,
> >
> > Borland cannot handle this code:
> >
> > #include
> > #include
> >
> > using namespace boost;
> > using namespace boost::mpl;
> >
> > struct A {};
> > struct B {};
> >
> > template
> > struct C : if_, A, B>::type {};
> >
> > struct D { int i; };
> > struct E {};
> >
> > struct F : C {};
> > struct G : C {};
>
> Just tried. Works pretty fine. My CVS tree might be a week old, or so.
> Also, maybe 'if_c<::boost::is_empty::value, A, B>' will work. Did
> the same with 'is_same' recently.
template
struct C : if_c< ::boost::is_empty::value, A, B>::type {};
Nope, does not work.
Joel de Guzman
[EMAIL PROTECTED]
http://www.boost-consulting.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: some more questions on MPL and Borland
- Original Message -
From: "Vladimir Prus" <[EMAIL PROTECTED]>
> Joel de Guzman wrote:
> > Hi,
> >
> > Borland cannot handle this code:
> >
> > #include
> > #include
> >
> > using namespace boost;
> > using namespace boost::mpl;
> >
> > struct A {};
> > struct B {};
> >
> > template
> > struct C : if_, A, B>::type {};
> >
> > struct D { int i; };
> > struct E {};
> >
> > struct F : C {};
> > struct G : C {};
>
> Just tried. Works pretty fine. My CVS tree might be a week old, or so.
> Also, maybe 'if_c<::boost::is_empty::value, A, B>' will work. Did
> the same with 'is_same' recently.
I just updated from CVS before posting this to be sure.
Borland 5.5.1,
bcc32 -O1 -w-inl -w-aus -q -P
Regards,
Joel de Guzman
[EMAIL PROTECTED]
http://www.boost-consulting.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] integral_c on g++2.95.3
- Original Message - From: "Gabriel Dos Reis" <[EMAIL PROTECTED]> > "Dave Abrahams" <[EMAIL PROTECTED]> writes: > > | On Tuesday, February 04, 2003 4:05 AM [GMT+1=CET], > | Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: > | > | > "Joel de Guzman" <[EMAIL PROTECTED]> writes: > | > > | > > Hi, > | > > > | > > I'm not sure if you are aware of this but g++ 2.95.3 cannot > | > > handle the casts: > | > > > | > > g++ 2.95.3 [no STLport] > | > > C:/dev/boost/boost/mpl/integral_c.hpp:67: sorry, not implemented: > | > > `static_cast_expr' not supported by dump_expr > | > > | > This means that the part of GCC-2.95.x compiler responsible for > | > pretty-printing "static_cast_expr" was not taught to do its homework. > | > | In that case it would seem likely that it could be fixed by reverting to > | C-style cast, no? > > Yes, I believe so. Yup, this works: #elif defined(__GNUC__) && (__GNUC__ < 3) // g++ 2.95.3 cannot take static_cast the casts, typedef integral_c next; typedef integral_c prior; Joel de Guzman [EMAIL PROTECTED] http://www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Bad Quoting and Outlook Express
Hey all you Outlook Express users - if you're tired of sending mangled emails, like this: > "Dominik Jain" wrote in message > news:aip4cd$15eofi$[EMAIL PROTECTED]... > > This is a simple sample text, and as you will see, Outlook Express is > going > > to wrap this line. I've always hated that! And one night I said to myself, > > "It can't go on like this". And so I wrote OE-QuoteFix... check out this free utility: http://home.in.tum.de/~jain/software/oe-quotefix/ I'm pretty sure I'm going to be switching back to Outlook Express from emacs/GNUs because of this (and the many joys of OE). I'm using it right now, and it "just works!" improving-quality-of-life-for-all-boosters-ly y'rs, Dave P.S. I'm tempted to suggest that we should link to this on our website and/or in our welcome email. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Current is_convertible borken for bcc5.5.1
> I was just about to build the filesystem library for the first time on my > Win98+BCC 5.5.1 environment, but I got lots of errors from > "type_traits/is_convertible.hpp" > Since the regression_test shows that this library passed bcc5.6.1 yesterday, > I thought that is_convertible might have changed today. Indeed, version 1.10 > (the previous) works fine. (that is, I was able to build the FS library) > > I attach here the compiler output using the -Q compiler option (which shows > extended error information). It's a builder 5.5.1 bug: is_convertible does not work correctly with that compiler (and never has), when one To parameter has a user defined constructor. John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Array support [was SmartPtr(Loki)-auto_ptr/movec'torissue]
From: "Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> > > I did not use boost::shared_array to implement the shared_plain type because > one of our requirements is that one reference count can be used to manage > multiple types. This is required in the context of in-place fast Fourier > transforms. I.e. an array that starts out as shared_plain > > ends up as shared after the Fourier transformation or vice versa. Of > course, constructing an array with type T and destructing it while thinking of > it as containing element types U could potentially lead to disasters. To > provide a certain degree of protection type casts are therefore only allowed > for element types with trivial destructors. This is managed through type traits > that can be specialized by the user. On most platforms, if you reinterpret_cast a shared_array< complex > to shared_array< double >, it will still destroy itself properly. (magic!) ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] integral_c on g++2.95.3
"Dave Abrahams" <[EMAIL PROTECTED]> writes: | On Tuesday, February 04, 2003 4:05 AM [GMT+1=CET], | Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: | | > "Joel de Guzman" <[EMAIL PROTECTED]> writes: | > | > > Hi, | > > | > > I'm not sure if you are aware of this but g++ 2.95.3 cannot | > > handle the casts: | > > | > > g++ 2.95.3 [no STLport] | > > C:/dev/boost/boost/mpl/integral_c.hpp:67: sorry, not implemented: | > > `static_cast_expr' not supported by dump_expr | > | > This means that the part of GCC-2.95.x compiler responsible for | > pretty-printing "static_cast_expr" was not taught to do its homework. | | In that case it would seem likely that it could be fixed by reverting to | C-style cast, no? Yes, I believe so. -- Gaby ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: some more questions on MPL and Borland
Joel de Guzman wrote:
Hi,
Borland cannot handle this code:
#include
#include
using namespace boost;
using namespace boost::mpl;
struct A {};
struct B {};
template
struct C : if_, A, B>::type {};
struct D { int i; };
struct E {};
struct F : C {};
struct G : C {};
Just tried. Works pretty fine. My CVS tree might be a week old, or so.
Also, maybe 'if_c<::boost::is_empty::value, A, B>' will work. Did
the same with 'is_same' recently.
HTH,
Volodya
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_class
From: "Daniel Frey" <[EMAIL PROTECTED]>
> On Tue, 04 Feb 2003 00:23:26 +0100, Paul Mensonides wrote:
>
> > - Original Message -
> > From: "Daniel Frey" <[EMAIL PROTECTED]>
> >
> >> template< class C, typename T > struct is_member_function_pointer< T
> >> C::* >
> > { enum { value = is_function< T >::value }; };
> >> template< class C, typename T > struct is_member_function_pointer< T
> >> C::*
> > const > { enum { value = is_function< T >::value }; };
> >> template< class C, typename T > struct is_member_function_pointer< T
> >> C::*
> > volatile > { enum { value = is_function< T >::value }; };
> >> template< class C, typename T > struct is_member_function_pointer< T
> >> C::*
> > const volatile > { enum { value = is_function< T >::value }; };
> >
> > Whoa, sorry Daniel, I missed this part, which is almost exactly the same
> > as my post.
>
> And which is exactly the kind of type-deduction that the GCC fails to do
> - which is why I needed to create the slightly more complex version to
tame
> both compilers at the same time :)
Are you sure that "T C::* const" is a type?
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] integral_c on g++2.95.3
On Tuesday, February 04, 2003 4:05 AM [GMT+1=CET], Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: > "Joel de Guzman" <[EMAIL PROTECTED]> writes: > > > Hi, > > > > I'm not sure if you are aware of this but g++ 2.95.3 cannot > > handle the casts: > > > > g++ 2.95.3 [no STLport] > > C:/dev/boost/boost/mpl/integral_c.hpp:67: sorry, not implemented: > > `static_cast_expr' not supported by dump_expr > > This means that the part of GCC-2.95.x compiler responsible for > pretty-printing "static_cast_expr" was not taught to do its homework. In that case it would seem likely that it could be fixed by reverting to C-style cast, no? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] some more questions on MPL and Borland
Hi,
Borland cannot handle this code:
#include
#include
using namespace boost;
using namespace boost::mpl;
struct A {};
struct B {};
template
struct C : if_, A, B>::type {};
struct D { int i; };
struct E {};
struct F : C {};
struct G : C {};
Is there a known workaround? Can this be fixed?
I keep on bumping into this problem and its variants.
Or is there a better MPL idiom?
TIA,
Joel de Guzman
[EMAIL PROTECTED]
http://www.boost-consulting.com
Borland 5.5.1 [no STLport]
C:\dev\mpl_if.cpp:
Error E2396 C:\dev\boost\boost/type_traits/is_convertible.hpp 190: Template argument
must be a
constant expression
Error E2299 C:\dev\boost\boost/type_traits/is_convertible.hpp 190: Cannot generate
template
specialization from 'type_traits::ice_and'
Error E2293 C:\dev\boost\boost/type_traits/is_convertible.hpp 190: ) expected
Error E2230 C:\dev\boost\boost/type_traits/is_convertible.hpp 190: In-line data member
initialization requires an integral constant expression
Error E2230 C:\dev\boost\boost/mpl/bool_c.hpp 27: In-line data member initialization
requires an
integral constant expression
Error E2029 C:\dev\boost\boost/type_traits/is_convertible.hpp 195: 'bool_c<&value>'
must be a
previously defined class or struct
Error E2451 C:\dev\boost\boost/type_traits/is_empty.hpp 109: Undefined symbol 'value'
Error E2401 C:\dev\boost\boost/type_traits/is_empty.hpp 109: Invalid template argument
list
Error E2299 C:\dev\boost\boost/type_traits/is_empty.hpp 109: Cannot generate template
specialization
from 'type_traits::ice_or'
Error E2293 C:\dev\boost\boost/type_traits/is_empty.hpp 109: ) expected
Error E2230 C:\dev\boost\boost/type_traits/is_empty.hpp 109: In-line data member
initialization
requires an integral constant expression
Error E2029 C:\dev\boost\boost/type_traits/is_empty.hpp 193: 'bool_c<&value>' must be
a previously
defined class or struct
Error E2029 C:\dev\boost\boost/mpl/aux_/value_wknd.hpp 30: 'is_empty' must be a
previously
defined class or struct
Error E2407 C:\dev\boost\boost/mpl/if.hpp 62: Dependent type qualifier
'aux::value_wknd
>' has no member symbol named 'value'
Error E2407 C:\dev\boost\boost/mpl/if.hpp 62: Dependent type qualifier
'aux::value_wknd
>' has no member symbol named 'value'
Error E2407 C:\dev\boost\boost/mpl/if.hpp 65: Dependent type qualifier
'aux::value_wknd
>' has no member symbol named 'value'
Error E2407 C:\dev\boost\boost/mpl/if.hpp 65: Dependent type qualifier
'aux::value_wknd
>' has no member symbol named 'value'
Error E2402 C:\dev\mpl_if.cpp 11: Illegal base class type: formal type 'typename
if_,A,B>::type' resolves to 'typename if_c<,A,B>::type'
Error E2029 C:\dev\mpl_if.cpp 16: 'C' must be a previously defined class or struct
Error E2396 C:\dev\boost\boost/type_traits/is_convertible.hpp 190: Template argument
must be a
constant expression
Error E2299 C:\dev\boost\boost/type_traits/is_convertible.hpp 190: Cannot generate
template
specialization from 'type_traits::ice_and'
Error E2293 C:\dev\boost\boost/type_traits/is_convertible.hpp 190: ) expected
Error E2230 C:\dev\boost\boost/type_traits/is_convertible.hpp 190: In-line data member
initialization requires an integral constant expression
Error E2029 C:\dev\boost\boost/type_traits/is_convertible.hpp 195: 'bool_c<&value>'
must be a
previously defined class or struct
Error E2451 C:\dev\boost\boost/type_traits/is_empty.hpp 109: Undefined symbol 'value'
Error E2228 C:\dev\boost\boost/type_traits/is_empty.hpp 109: Too many error or warning
messages
*** 26 errors in Compile ***
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] io operations for stl containers?
>From: "Vladimir Prus" <[EMAIL PROTECTED]>
> Terje Slettebø wrote:
> >>From: "Vladimir Prus" <[EMAIL PROTECTED]>
> >
> >>after having to output std::vector to stream again and again using
custom
> >>solution, I started to wonder why we don't have a solution in boost.
> >>Does it makes sense to include operators<< for vectors, sets, etc?
>
> >>and so on. There are basically two approaches:
> >>
> >>1. Operators use fixed format: bracked list with commas between values
for
> >>vector, for example.
> >>2. Manipulators are provided to set brackets and separators.
> >>
> >>I had implemented the second approach some time ago, but it turned out
> >> that was overkill. So, 1) looks better now.
> >
> > If this is done as a library, then I think it's best not to have
hard-coded
> > brackets and separators. One might use an xalloc() value for each type
to
> > output. For example something like:
>
> You see, that's what I have implemented back in 2001. You could change
> braces/separator for each stl container, and it used xalloc()/pword().
> There's one problem though: I don't remember the syntax of brace
> changing, just because I used it a couple of times long ago and then
> stopped. Probably, the scope should be more clearly defined:
>
> Edward Diener wrote:
> > Al Stevens who writes the C++ column for "Doctor Dobbs Journal" put out
a
> > persistent template library for C++ containers some time back. It is
> > probably on the DDJ web site, although I haven't looked there recently.
You
> > might want to check that out and see what he did. I will readily admit
I
> > have not had the need to persist container data in my daily programming
but
> > I can understand others having that need.
>
> Rozental, Gennadiy wrote:
> > I do not see a way how you could implement solution with better
> > flexibility/conciseness ratio than copy+ostream_iterator one.
>
> I'm not much interested in persistence (after all, I hope that Robert's
> library will take care of that). Likewise, I never needed arbitrary
> delimiters, etc. But while developing an algorithm for finding k shortest
> paths in a graph, I need to output each path, and have no easy standard
way.
> One might call this output operators are mostly debugging help, but why
not
> have standard debugging help?
>
> > std::cout << boost::io_format(",", "[", "]") <<
> > boost::io_format("","","\n") << list << '\n';
> >
> > This might print:
> >
> > [1, a]
> > [2, b]
> > [3, c]
>
> This example should one case where manipulators are desirable:
>
> vector< vector > v;
> cout << v ;
>
> Here, each nested vector better go on a separate line. I suggest:
>
> cout << multiline << v;
>
> where "multiline" manipulator causes each element of the next output
container
> to go on separate line.
The above io_format<>'s are intended to be manipulators. You could get this
manipulator with:
io_format >("\n","","") multiline;
You could also make it so that this manipulator set the format for any
container, but in cases where you have arbitrary deep nesting of containers
(like in Peter Dimov's posting), it may be better to set the format on a
per-type basis.
Incidentally, I've just made a version that does exactly this. :) I've
attached it, including a test, with this posting.
It's used like this:
int main()
{
typedef std::pair Map;
typedef std::vector MapList;
MapList list;
list.push_back(std::make_pair(1,'A'));
list.push_back(std::make_pair(2,'B'));
list.push_back(std::make_pair(3,'C'));
std::cout << io_format("[","]",",") << io_format("","","\n")
<< list << '\n';
}
Output:
[1,A]
[2,B]
[3,C]
It's a little rough, as it doesn't do proper stream error handling, or
ownership management for the pword object, but it works. Feedback is
welcome.
Regards,
Terje
Test.cpp
Description: Binary data
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: io operations for stl containers?
Terje Slettebø wrote:
This example should one case where manipulators are desirable:
vector< vector > v;
cout << v ;
Here, each nested vector better go on a separate line. I suggest:
cout << multiline << v;
where "multiline" manipulator causes each element of the next output
container
to go on separate line.
The above io_format<>'s are intended to be manipulators. You could get this
manipulator with:
io_format >("\n","","") multiline;
You could also make it so that this manipulator set the format for any
container, but in cases where you have arbitrary deep nesting of containers
(like in Peter Dimov's posting), it may be better to set the format on a
per-type basis.
I think that when more that double nesting is involed you have problems
anyway.
Incidentally, I've just made a version that does exactly this. :) I've
attached it, including a test, with this posting.
I've take a look and I like it -- quite lean and does the work. I've some
concerns, though:
1. Are "default" breaces/separators possible? I'd rather not use
io_format every time I had to output a vector.
2. Is that good idea to set brace style on vector and vector
separately? It would increase pword() array, and not sure if this will
benefit us much. Are nested containers the primary motivation?
- Volodya
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Regressions on Linux (Was: [boost] integral_c on g++2.95.3)
Vladimir Prus <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > "Joel de Guzman" <[EMAIL PROTECTED]> writes:
| > | Hi,
| > | | I'm not sure if you are aware of this but g++ 2.95.3 cannot
| > | handle the casts:
| > | | g++ 2.95.3 [no STLport]
| > | C:/dev/boost/boost/mpl/integral_c.hpp:67: sorry, not implemented:
|`static_cast_expr' not supported
| > | by dump_expr
| > This means that the part of GCC-2.95.x compiler responsible for
| > pretty-printing "static_cast_expr" was not taught to do its homework.
|
| First of all, this looks like a major problem: looking at
| regressiong tests result for linux, I see that filesystem tests fail for
| that reason, and some other too -- 53% of tests fail.
|
| Further, I can't understand the following part of regression logs:
|
| operations_test / gcc
| [snip]
| /opt/gcc2/bin//g++ -c -Wall -ftemplate-depth-100 -g -O0
| -fno-inline -I"../libs/filesystem/test" -I
| "/home/boost/boost-regress/boost" -o
|
|"../libs/filesystem/test/bin/operations_test.test/gcc/debug/runtime-link-dynamic/operations_test.o"
| "/home/boost/boost-regress/boost/libs/filesystem/test/operations_test.cpp"
|
| operations_test / gcc2953
| [snip]
|
| Compiler output:
| [snip]
| /opt/gcc2/bin//g++ -c -Wall -ftemplate-depth-100 -g -O0
| -fno-inline -I"../libs/filesystem/test" -I
| "/home/boost/boost-regress/boost" -o
|
|"../libs/filesystem/test/bin/operations_test.test/gcc2953/debug/runtime-link-dynamic/operations_test.o"
| "/home/boost/boost-regress/boost/libs/filesystem/test/operations_test.cpp"
I must admit I'm neither familiar with Boost's regression testsuite,
so I would need your help to see what you don't understand.
| Is the same compiler invoked in both cases? This is very likely, because I've
| just build filesystem library with gcc3.2/Boost.Build2 without problems.
|
| BTW, Gabriel, why you say about "pretty-printing"? I though no
| RTL is pretty printed in default gcc settings...
No.
I'm not sure this is the right to discuss GCC initernals. But since
you asked: GCC mainly uses two data structures
1) "tree" for anything that has to do with front-ends; i.e. source
programs are parsed and represented as trees.
2) "RTL" for middle-end and back-ends. Trees are translated from
trees.
The routine dump_expr mentioned in the "sorry message" only deals with
trees ("static_cast_expr" is an instance of tree). What is happening
is that, somehow, that routine has been called to dump a static_cast
expression.
-- Gaby
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] integral_c on g++2.95.3
"Joel de Guzman" <[EMAIL PROTECTED]> writes: | Hi, | | I'm not sure if you are aware of this but g++ 2.95.3 cannot | handle the casts: | | g++ 2.95.3 [no STLport] | C:/dev/boost/boost/mpl/integral_c.hpp:67: sorry, not implemented: `static_cast_expr' |not supported | by dump_expr This means that the part of GCC-2.95.x compiler responsible for pretty-printing "static_cast_expr" was not taught to do its homework. -- Gaby ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Deadline for the Standard LibraryTechnicalReport
Alisdair Meredith writes: > Beman Dawes wrote: > > > See http://www.boost.org/more/cpp_committee_meetings.html. While the > > general public isn't invited to committee meetings, Boost "technical > > experts" are welcome. > > So how would I qualify myself as a "Boost technical expert"? IIRC, you are interested in attending because you live near Oxford. If this is the case, if you speak to Lois Goldthwaite ([EMAIL PROTECTED]) you can join the UK Standards panel, and attend as a UK rep. Anthony -- Anthony Williams Senior Software Engineer, Beran Instruments Ltd. Remove NOSPAM when replying, for timely response. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [filesystem] compile warnings
Beman, I've just got the following: gcc.compile ../../../libs/filesystem/build/bin/gcc-3.2/release/link-static/operations_posix_windows.o ../../../libs/filesystem/src/operations_posix_windows.cpp: In member function `boost::filesystem::directory_iterator::directory_iterator(const boost::filesystem::path&)': ../../../libs/filesystem/src/operations_posix_windows.cpp:210: warning: `const char*name' might be used uninitialized in this function ../../../libs/filesystem/src/operations_posix_windows.cpp: In member function `boost::filesystem::directory_iterator::directory_iterator(const boost::filesystem::path&)': ../../../libs/filesystem/src/operations_posix_windows.cpp:210: warning: `const char*name' might be used uninitialized in this function ../../../libs/filesystem/src/operations_posix_windows.cpp: In function `void boost::filesystem::copy_file(const boost::filesystem::path&, const boost::filesystem::path&)': ../../../libs/filesystem/src/operations_posix_windows.cpp:383: warning: `int outfile' might be used uninitialized in this function This shows up during release builds only. I've looked at warnings, and in first case gcc is just not smart enough -- but would be nice to eliminate the warning. In the other case the warning is correct, AFAICT. - Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Preliminary submission: command line & config filelibrary
[bringing to list again]
Hi David,
David A. Greene wrote:
Vladimir Prus wrote:
-fcopyPropagation={--maxTransforms=32 --keepStats}
Hmm... that's pretty interesting example. While I'm not sure how
Gennadiy's
code can handle such things, I have some ideas w.r.t my library.
Good! Glad I could inspire some thought. I went over this a couple of
years ago on a long Boost CLA thread and got absolutely nowhere. It
seems like many people are opposed to such nesting. I've found it to
be extremely useful.
You might find it interesting that the first version of my library was
created for use in research assembler optimizer, which had several modules
with private parameters. So I understand you desire. I've used nested
options names, line "copyPropagation.maxTransforms" (and I guess I suggested
that), but your approach is much less verbose.
1. You'd need some way to extract those composite options from the
command line. I assume that matching braces suffice. Then, you'd write
an additional
parser (just a function), which can extract "copyPropagation" and
"{--maxTransforms=32 --keepStats}" from the above option. That
function will
be passed to the command line parser.
Ok, I'm not completely clear about what you mean here. I was thinking
about doing things in a Spirit-like fashion with nested grammars. The
nested options in fact look exactly like "top level" options. They
just get parsed/processed internally by the copy propagation filters.
Yea, the copy propagation module provides a function to parse its options,
which function may well do a second pass of parsing.
Someone had the idea of building a CLA option tree. I think that's not
a bad idea because validation may become more powerful. For example,
one could check that conflicting options are not specified.
I am not sure that is "option tree" -- don't remember ever hearding this idea.
Is it meant that after parsing you have a tree of option values: modules at
the top level, module options at the second, and so on?
2. Since you say that only CopyPropagation module should care about
content of
braces, I think that module can simply register option
"copyPropagation"
and a custom function ("validator"), which will be responsible for
interpreting the content of value. For example, it can split the
content
on whitespaces and parse it like a command line of it's own.
That's essentially what our software does now. It's just that our
parser is an ugly piece of hand-written code and I want to clean it
up. :)
Okay, then it looks like perfectly possible!
The only problem with this scheme is that now additional parser can
operate on
one token only. However, this restriction is not fundamental and can
be lifted easily.
In our system we get one token with a big string value but we just
recursively invoke the CLA parser to break up the string into
multiple tokens.
My command line parser operates on argv elements without concatenating them
(for example, to allow option values/arguments with spaces in them). So
currently there's no way to extract the string between "{", "}". But as
I said, this is easily fixable. Then, the string between braces can be
tokenized and parser, just as you say.
How does the above suggestion look?
I think it's pretty close to what our system has now, only better
formalized. I'm kind of intrigued by the idea of a two-pass system
where the parser simply builds an option tree and a validator
checks it and/or invokes actions based on the values. These
validators could be nested such that the top-level validator
invokes sub-validators (for copy propagation in this example).
I think we might try to do some reality check. If you send me
description of options for a couple of modules, I might try to
come with a working solution. (Of course, you command line
parsing code would be interesting to look at, if possible).
This assumes that all nested options have a common format which
may not be desirable. Of course we could also use the Spirit
idea of nested grammars to overcome this difficulty.
There's no assumption of common format, in fact. If you have command line
-fcopyPropagation={ . }
then it's required to clearly delimit the option's value. In this case, the
braces are just fine. After that, the validator deals with concent of braces.
It can use the same parser recursively, or it can construct a Spirit parser
and use it, or just split the content on commas.
- Volodya
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Regressions on Linux (Was: [boost] integral_c on g++2.95.3)
Gabriel Dos Reis wrote: "Joel de Guzman" <[EMAIL PROTECTED]> writes: | Hi, | | I'm not sure if you are aware of this but g++ 2.95.3 cannot | handle the casts: | | g++ 2.95.3 [no STLport] | C:/dev/boost/boost/mpl/integral_c.hpp:67: sorry, not implemented: `static_cast_expr' not supported | by dump_expr This means that the part of GCC-2.95.x compiler responsible for pretty-printing "static_cast_expr" was not taught to do its homework. First of all, this looks like a major problem: looking at regressiong tests result for linux, I see that filesystem tests fail for that reason, and some other too -- 53% of tests fail. Further, I can't understand the following part of regression logs: operations_test / gcc [snip] /opt/gcc2/bin//g++ -c -Wall -ftemplate-depth-100 -g -O0 -fno-inline -I"../libs/filesystem/test" -I "/home/boost/boost-regress/boost" -o "../libs/filesystem/test/bin/operations_test.test/gcc/debug/runtime-link-dynamic/operations_test.o" "/home/boost/boost-regress/boost/libs/filesystem/test/operations_test.cpp" operations_test / gcc2953 [snip] Compiler output: [snip] /opt/gcc2/bin//g++ -c -Wall -ftemplate-depth-100 -g -O0 -fno-inline -I"../libs/filesystem/test" -I "/home/boost/boost-regress/boost" -o "../libs/filesystem/test/bin/operations_test.test/gcc2953/debug/runtime-link-dynamic/operations_test.o" "/home/boost/boost-regress/boost/libs/filesystem/test/operations_test.cpp" Is the same compiler invoked in both cases? This is very likely, because I've just build filesystem library with gcc3.2/Boost.Build2 without problems. BTW, Gabriel, why you say about "pretty-printing"? I though no RTL is pretty printed in default gcc settings... - Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] io operations for stl containers?
Terje Slettebø wrote:
From: "Vladimir Prus" <[EMAIL PROTECTED]>
after having to output std::vector to stream again and again using custom
solution, I started to wonder why we don't have a solution in boost.
Does it makes sense to include operators<< for vectors, sets, etc?
[...]
and so on. There are basically two approaches:
1. Operators use fixed format: bracked list with commas between values for
vector, for example.
2. Manipulators are provided to set brackets and separators.
I had implemented the second approach some time ago, but it turned out
that was overkill. So, 1) looks better now.
>
If this is done as a library, then I think it's best not to have hard-coded
brackets and separators. One might use an xalloc() value for each type to
output. For example something like:
You see, that's what I have implemented back in 2001. You could change
braces/separator for each stl container, and it used xalloc()/pword().
There's one problem though: I don't remember the syntax of brace
changing, just because I used it a couple of times long ago and then
stopped. Probably, the scope should be more clearly defined:
Edward Diener wrote:
> Al Stevens who writes the C++ column for "Doctor Dobbs Journal" put out a
> persistent template library for C++ containers some time back. It is
> probably on the DDJ web site, although I haven't looked there recently. You
> might want to check that out and see what he did. I will readily admit I
> have not had the need to persist container data in my daily programming but
> I can understand others having that need.
Rozental, Gennadiy wrote:
> I do not see a way how you could implement solution with better
> flexibility/conciseness ratio than copy+ostream_iterator one.
I'm not much interested in persistence (after all, I hope that Robert's
library will take care of that). Likewise, I never needed arbitrary
delimiters, etc. But while developing an algorithm for finding k shortest
paths in a graph, I need to output each path, and have no easy standard way.
One might call this output operators are mostly debugging help, but why not
have standard debugging help?
std::cout << boost::io_format(",", "[", "]") <<
boost::io_format("","","\n") << list << '\n';
This might print:
[1, a]
[2, b]
[3, c]
This example should one case where manipulators are desirable:
vector< vector > v;
cout << v ;
Here, each nested vector better go on a separate line. I suggest:
cout << multiline << v;
where "multiline" manipulator causes each element of the next output container
to go on separate line.
- Volodya
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Array support [was SmartPtr (Loki) - auto_ptr/move c'tor issue]
"Beman Dawes" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > * Should a PBSP supply policies that are prone to be used unsafely? > > I'd say "no" is an acceptable answer, at least for something like the T* > conversion in widely used libraries like the Standard Library and Boost. > > * Should a PBSP allow user supplied policies to modify interface, perhaps > in ways that may be unsafe or even just unfortunate? > > That's tougher. At some point I lose interest in a PBSP if it prevents me > from doing the things I want to do, even if I only want to do them in the > privacy of my own code. The original SmartPtr design leaves the onus of choosing the right policy combination to the application designer. To me, that's a design I find reasonable and in keep with the spirit of C++. Safer designs are possible that reject policy combinations that "don't go together" at the price of being more complicated or less efficient or less flexible. Andrei ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] integral_c on g++2.95.3
Hi, I'm not sure if you are aware of this but g++ 2.95.3 cannot handle the casts: g++ 2.95.3 [no STLport] C:/dev/boost/boost/mpl/integral_c.hpp:67: sorry, not implemented: `static_cast_expr' not supported by dump_expr C:/dev/boost/boost/mpl/integral_c.hpp:67: sorry, not implemented: `static_cast_expr' not supported by dump_expr C:/dev/boost/boost/mpl/integral_c.hpp:68: sorry, not implemented: `static_cast_expr' not supported by dump_expr C:/dev/boost/boost/mpl/integral_c.hpp:68: sorry, not implemented: `static_cast_expr' not supported by dump_expr and I must revert to: #elif defined(__GNUC__) && (__GNUC__ < 3) // g++ 2.95.3 cannot take the casts, typedef integral_c next; typedef integral_c prior; #else typedef integral_c(value + 1)> next; typedef integral_c(value - 1)> prior; #endif Regards, Joel de Guzman [EMAIL PROTECTED] http://www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Test Tool Proposal (test_tools.hpp)
Rozental, Gennadiy wrote: I've a similiar problem with BOOST_CHECK family, but I think the solution can be different: provide a means to convert failed test into assertion failure. This way I can conveniently debug. Currently, I have to replace BOOST_CHECK with assert manually, to find where the failure happened. Gennadiy, what do you think? - Volodya I do not understand exactly how switching to assert would help you locate the failure point. If you going to run it under debugger you as well could just set a break point on failed assertion. If you going to analize the core using debugger, why not run it under debugger in a first place. If you expect to get a location from the assert output - it will be not better than test tools one. The situation is that I have a consice description of test cases (a vector of C structures) and a function which iterates over that vector, doing BOOST_CHECK in some places. If I place a breakpoint on the failed BOOST_CHECK, then that breakpoint will trigger many times before the actual error happens. - Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
