Re: [boost] FW: New Iterator Adaptors
Robert Ramey <[EMAIL PROTECTED]> writes: >>Date: Tue, 29 Apr 2003 09:53:01 -0400 >>From: David Abrahams <[EMAIL PROTECTED]> > > By amazing coincidence I happen to need a special iterator_adaptor > for my project. I tried boost::interator_adaptor ^sic Which one? The one in the CVS or the one in the sandbox? > - and it was just too hard to "adapt". So It seems you're on to a > good thing here. Hard to understand why you say that, if it was too hard to use. > I used the Mult-Pass iterator in the spirit lib. > This changes an input iterator into a forward iterator. It is of > wide application and should be outside of spirt. sprit also has a > file_input iterator wish should really be a simplle application of > the multi-pass iterator to an input iterator. > > FYI my application needs something to transform escaped text > to unescaped text and back again. and another thing to transform > from mult-byte strings (locale dependent) to wstring and back. > And these things should be composable with each other and > other iterators such as input/output stream iterators. I would hope > the new system would be applicable to these use cases in a > natural way. Why don't you try it then? > When will the new version be available. It's in the boost sandbox: boost/iterator, libs/iterator > I've started making a couple of small templates derived from > std::iterator<...> to handle the job. but would prefer to use a > boost library if a suitable one is available. > > The docs suggest a different set of iterator catagories. Will this be > incompatiable with the current standard library? or a replacement for it? > or ? A backward-compatible replacement. Read the docs, they give the details. > The docs for the new system suggest that the new system will be much > easier to use and understand than the old one. A couple of examples > would be nice. Again, they're in the sandbox. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] FW: New Iterator Adaptors
>Date: Tue, 29 Apr 2003 09:53:01 -0400 >From: David Abrahams <[EMAIL PROTECTED]> By amazing coincidence I happen to need a special iterator_adaptor for my project. I tried boost::interator_adaptor - and it was just too hard to "adapt". So It seems you're on to a good thing here. I used the Mult-Pass iterator in the spirit lib. This changes an input iterator into a forward iterator. It is of wide application and should be outside of spirt. sprit also has a file_input iterator wish should really be a simplle application of the multi-pass iterator to an input iterator. FYI my application needs something to transform escaped text to unescaped text and back again. and another thing to transform from mult-byte strings (locale dependent) to wstring and back. And these things should be composable with each other and other iterators such as input/output stream iterators. I would hope the new system would be applicable to these use cases in a natural way. When will the new version be available. I've started making a couple of small templates derived from std::iterator<...> to handle the job. but would prefer to use a boost library if a suitable one is available. The docs suggest a different set of iterator catagories. Will this be incompatiable with the current standard library? or a replacement for it? or ? The docs for the new system suggest that the new system will be much easier to use and understand than the old one. A couple of examples would be nice. Good Work. Robert Ramey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Philip.Dunstan@nautronix.com.au: is_base_and_derivedbug?]
>From: "Philip Dunstan" <[EMAIL PROTECTED]>
> Hi there,
>
> Should this work?
No. Template type deduction uses an object's static (declared) type, so in
this program, T=A, since the static type of pa is A*. That its dynamic type
is B* isn't taken into consideration, as template instantiation is done at
compile-time.
Regards,
Terje
> I've tried it using g++ 3.2 (redhat and cygwin) and borland c++ builder
> 5.6.4 and it fails on the assert for all of them.
>
> #include
> #include
>
> class A {};
>
> class B : public A {};
>
> template
> bool isDerivedFromA(const T& t)
> {
> return boost::is_base_and_derived::value;
> }
>
> int main()
> {
> B b;
> A* pa = &b;
> assert(isDerivedFromA(*pa));
> return 0;
> }
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: New Iterator Adaptors
"Gustavo Guerra" <[EMAIL PROTECTED]> writes: > The diagrams are missing Fixed now, thanks. >> http://boost-consulting.com/writing/facade-and-adaptor.html >> http://boost-consulting.com/writing/new-iter-concepts.html -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [Philip.Dunstan@nautronix.com.au: is_base_and_derived bug?]
Hi there,
Should this work?
I've tried it using g++ 3.2 (redhat and cygwin) and borland c++ builder
5.6.4 and it fails on the assert for all of them.
#include
#include
class A {};
class B : public A {};
template
bool isDerivedFromA(const T& t)
{
return boost::is_base_and_derived::value;
}
int main()
{
B b;
A* pa = &b;
assert(isDerivedFromA(*pa));
return 0;
}
thanks,
Phil
--
Philip Dunstan
[EMAIL PROTECTED]
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Workarounded regression tools for MSVC 6
This patch allows to compile regression tools with MSVC 6.
Regards,
w
begin 666 regression.patch
[EMAIL PROTECTED]('1O;VQS+W)E9W)EPT*(" @(" @(" @(" @
M(')E5]S=')I;F<@.B!E;&5M96YT7V-O;G1E;G0H(&1B+" B
M;&EN:R(@*3L-"BL@(" @8V]N5]S=')I
M;F<@.B!E;&5M96YT7V-O;G1E;G0H(&1B+" BF4H,"[EMAIL PROTECTED]@(" @(&EF("@@;&EB+F5M<'1Y*"D@
M)[EMAIL PROTECTED]<&EL92YE;7!T>[EMAIL PROTECTED]("8F(&QI;FLN96UP='DH*2 F)B!R=6XN96UP
M='DH*2 I#0H@(" @(" @2!N86UE+"!T97-T(&YA
M;64L(&%N9"!T97-T('1Y<&[EMAIL PROTECTED]&%B;&[EMAIL PROTECTED]&%T80T*("
@("!S=')I;FF5?='EP92!R;W=?F4H*3L-"B @(" @
M=&%R9V5T("L]("(\='(^/'1D/CQA(&AR968]7"(B("L@;&EB7V1O8W-?<&%T
M:" K(")<(CXB(" K(&QI8E]N86UE(" K("(\+V$^/"]T9#XB.PT*+2 @("!T
M87)[EMAIL PROTECTED]@(CQT9#X\82!HF4H*2LQ("D[#0HK(" @('-TPT**R @(" @('-T7!E('!OPT**R @(" @(" @<&]S(#T@
M;&EN92YF:6YD7V9I'!R97-S(&]R(&EM<&[EMAIL PROTECTED]2!F;W(@86YY('!U&UL+FAP<"(-"B C:6YC;'5D92 B8F]O2]C<'!?8U]H96%D97)S+V-T:6UE/@T*
M*R-I;F-L=61E(#QB;V]S="]C;VUP871I8FEL:71Y+V-P<%]C7VAE861E7!E/B O+R!F;W(@=&]L;W=E<@T*( T*('5S:6YG('-T9#HZ5]X;6P[#0I 0" M,3(Y
M+#@@*S$S,"PX($! #0H@("!V;VED('!AF4H,"D[#0HK(" @('-E8V]N9%]D:7(N7!E6VE=(#T@&4@
M9F]R(&QA8VL@;V8@(B I("$]('-T[EMAIL PROTECTED]&]O
M;',O5]X;6PN8W!P#0H]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]#0I20U,@[EMAIL PROTECTED]5]X;6PN8W!P+'8-"G)E=')I
M979I;F<@&UL+F-P
M< T*+2TM('1O;VQS+W)E9W)E&UL+F-P< DQ
M."!$96,@,C P,B Q,CHR,#HU-2 M,# P, DQ+C(-"BLK*R!T;V]Lhttp://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Boost Library Guidelines
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of William E. Kempf | Sent: Tuesday, April 29, 2003 8:40 PM | To: [EMAIL PROTECTED] | Subject: RE: [boost] Boost Library Guidelines | > This sounds 'best practice'. If others agree, can it be added to the | > guidelines? | | It sounds good in theory, but I've never been comfortable living with it. | I know others do, but in my experience, especially with the MS compiler, | the highest warning level produces a LOT of meaningless diagnostics which | can be very difficult to eliminate... even with pragmas. As a "best | practice suggestion", it's a great idea... as a requirement, I'd have to | voice an opinion against. I absolutely agree, but I feel it would be useful encourage authors to try. Paul ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Boost Library Guidelines
Paul A. Bristow said: > | -Original Message- > | From: [EMAIL PROTECTED] > | [mailto:[EMAIL PROTECTED] Behalf Of Terje Slettebø | > Sent: Friday, April 25, 2003 5:33 PM > | To: Boost mailing list > | Subject: Re: [boost] Boost Library Guidelines > | > | > May I suggest that we add to "Aim for ISO Standard C++ ..." > | > "Try to code so that compiles with 'strict' compiler settings ... | > | I use the highest warning level (4) for MSVC and Intel C++, and strict > mode | for the latter, to not ignore any warnings/remarks by default. > > | In the cpp-files, not headers, I then selectively disable > remarks/warnings that are > | harmless (and there's a lot of them), until it compiles without > | remarks/warnings. I think one should not get used to ignore warnings > in the | output, or one could easily miss some which _does_ matter, > which is why I | disable the ones that don't. > | > | In many cases, on level 4, there's _no_ practical way to turn off a | > remark/warning, without using #pragma. Therefore, I think it may be > better | to use a #pragma (in the cpp-file), than telling the user to > ignore the | remarks/warnings. In header-only libraries, like much of > the Boost | libraries, this leaves it up to the user, anyway. > > This sounds 'best practice'. If others agree, can it be added to the > guidelines? It sounds good in theory, but I've never been comfortable living with it. I know others do, but in my experience, especially with the MS compiler, the highest warning level produces a LOT of meaningless diagnostics which can be very difficult to eliminate... even with pragmas. As a "best practice suggestion", it's a great idea... as a requirement, I'd have to voice an opinion against. -- William E. Kempf ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Problems compiling MPL sample in MSVC 6.5
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/mpl/example/inherit_linearly.cpp?rev=HEAD&content-type=text/plain This sample (which Gennadiy provided in a post from his a few days ago) does not compile in MSVC++ 6.5. The compiler says: error C2039: 'index' : is not a member of 'arg<-1>' If I remove all the 'index' stuff, the program compiles, but sizeof(t) is 1 --it should be at least sizeof(int)+sizeof(char const *)+sizeof(bool). Ideas? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] lexicographic
This looks neat and will sometimes be very useful in reducing mistakes. Tests OK
with MSVC 7.0.
Some more fully worked examples like using std::pair and case insensitive
strings are likely to be the most common applications, so these would help sell
its use.
(The tests are not ideal for this purpose, though illuminating examples).
For a submission, the tests could usefully use BOOST's own test suite and
perhaps for completeness add a few more like checking the free == and !=
operators. Tests like "assert(!l1)" and "if(l1)" implicitly use the bool
conversion which might be noted in a comment.
The enum result_type which might be documented as:
enum result_type { minus = -1, equivalent = 0, plus = +1};
"lexicographic" is a serious fingerfull to type :-(
Paul
PS Spelling nits:
comparision also a fingerfull compared to comparison ;-)
and cpomplex too.
Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK
+44 1539 561830 Mobile +44 7714 33 02 04
Mobile mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
| -Original Message-
| From: [EMAIL PROTECTED]
| [mailto:[EMAIL PROTECTED] Behalf Of Jan Langer
| Sent: Thursday, April 17, 2003 8:27 AM
| To: [EMAIL PROTECTED]
| Subject: [boost] lexicographic
|
|
| hi,
| three weeks ago i asked for interest in a utility class for comparing
| data lexicographically. i got several suggestions, and i tried to
| incorporate them. now i put the header, a documentation file and a test
| into the sandbox. the name is now boost/utility/lexicographic.hpp.
| jan
|
| --
| jan langer ... [EMAIL PROTECTED]
| "pi ist genau drei"
|
|
| ___
| Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
|
|
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: New Iterator Adaptors
The diagrams are missing Gustavo Guerra "David Abrahams" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Some relatively significant revisions to the new iterator adaptors and > iterator facade in the sandbox have happened recently. Among other > things, we managed to eliminate one template parameter from > iterator_adaptor (yay!). We also finalized our proposals for the C++ > standard technical report. That text should serve as pretty good > documentation until we have been able to generate the usual Boost > "user-level" documentation from this material. The docs are in > ReStructuredText (a plaintext markup format), but you can view HTML > formatted versions here: > > http://boost-consulting.com/writing/facade-and-adaptor.html > http://boost-consulting.com/writing/new-iter-concepts.html > > We plan to move the new adaptors into the main Boost CVS in the > relatively near future. This will be an interface-breaking change; > if that's going to cause a major problem for anyone, please let us > know. > > -- Dave, Jeremy, and Thomas > > -- > Dave Abrahams > Boost Consulting > www.boost-consulting.com > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] VC++ 7.1 __ctor error [was: iterator_adaptors and vc7.1]
At 06:10 AM 4/16/2003, Thomas Witt wrote: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA1 > >Thomas Witt wrote: >| >| Hi, >| >| When compiling code using iterator_adaptors with vc7.1 I often get >| errors like the following >| >| c\graphmanager_detail.cpp(76) : error C2061: syntax error : identifier >| '__ctor' >| >| H:\systems\boost_1_30_0\boost\iterator_adaptors.hpp(1409) : see >| reference to class template instantiation >| >'boost::filter_iterator_generator,Category,Distance>' > >| >| being compiled >| >| This seems like a bug in vc7.1. Does this ring a bell for anyone? > >Further investigation seems to indicate that this is not directly >related to iterator_adaptors. Seems like vc7.1 generates messages >containing __ctor whenever it is clueless. I've had a confirmation from Brandon Bray at Microsoft: >Just letting you know that we do have the bug you noticed with __ctor in >a C2039 error in our database. It hasn't been fixed yet, but it is >scheduled to be fixed within a few weeks from now. For reference, the >bug info is: > >ID:VSWhidbey 38416 >TITLE: BOOST: use of default argument in constructor of class derived > from class of same name in a different namespace, causes errors A bit of a pain, even though easy to workaround. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: New Iterator Adaptors [minor doc nitpick]
David Abrahams wrote: > but you can view HTML formatted versions here: > > http://boost-consulting.com/writing/facade-and-adaptor.html > http://boost-consulting.com/writing/new-iter-concepts.html OK, it's petty to pick on formatting! But for some class of symbol you have chosen to force a white background, while the rest of the document takes the default. On my system this is a long way removed from white, and can be quite distracting. Hope to have more meaningful feedback soon, as I have a few adapators I have been waiting to write... [wrapping collections in an external library] -- AlisdairM ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
