[boost] Re: Revised streambuf library
"Jonathan David Turkanis" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > You have read/write member functions of your source/sink/filter concepts > > virtual. If one went for efficiency she would stay away from virtual > > functions. With such a design you leave a user no choice. > > Source/sink/filter classes don't have to derive from the basic > implementations which use virtual functions. The adapters which call the > source/sink/filters know the fully-derived types of the source/sink/filters > and shouldn't have to use virtual function dispatch. There does seem to be a > need for one non-inlinable function at each junction, if non-trivial > filtering is taking place. I address this in the efiiciency section. Sorry, it was not obvious for me. > > There are too many adapters, IMHO. It obscures. Since each STL sequence > > support iterators why don't use it? Generally speaking, there should be > only > > two adapters (input and output) that take any STL sequence represented by > > begin/end iterators. > > The factory functions address this. You just call new_source or new_sink > with whatever object you want to make into a source/sink. This is less > verbose than using, e.g., streambuf iterators. Also, in the case of strings, > the factories return adapters which are better than generic container > adapters; with SFINAE you should be able to pass a string literal to > new_source. I agree. This is just a matter of taste. I would prefer to write more generic adapter classes and a bunch of factories. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: mpl/loki
"Aleksey Gurtovoy" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > IMO we should just stop using 'void_' for internal purposes and give it > up to users :). I think it would be also very nice to 'give up' the mpl::aux::type_wrapper class. It's quite a useful class and I wonder why it is not public. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Revised streambuf library
"Jonathan D. Turkanis" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > I have posted a new version of my library, which has been rewritten to > incorporate filtering as a basic construct. > (http://groups.yahoo.com/group/boost/files/streambuf_lib.zip) > > In addition to allowing the easy creation of streams and streambuf from > objects with socket-like interfaces, it provides a convenient interface for > defining i/o filters and for combining them in various ways with each other > and with types from the standard library (streams, streambufs, containers, > sequences, codecvts.) I don't get the idea of reinventing the stream classes. One can use their rdbuf() member function to change the buffer. Could you please elaborate on that? You have read/write member functions of your source/sink/filter concepts virtual. If one went for efficiency she would stay away from virtual functions. With such a design you leave a user no choice. There are too many adapters, IMHO. It obscures. Since each STL sequence support iterators why don't use it? Generally speaking, there should be only two adapters (input and output) that take any STL sequence represented by begin/end iterators. P.S. There is a very good article by Alexandre Duret-Lutz and Thierry Geraud " Improving Object-Oriented Generic Programming". I took some damn good ideas from there when I was implementing my buffer adapters. You can get it here: http://www.rsdn.ru/File/5711/duret_lutz.zip ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost::thread feature request: thread priority
"Alexander Terekhov" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> Maxim Egorushkin wrote:
> [...]
> > Seems like the issue is undefined behaviour when casting away volatile.
> > Do I get it right?
>
> Yes, UB is the issue ("one of the most obvious tips of the iceberg").
>
> Well, more on volatiles (low level stuff) can be found below. Uhmm,
> as for "higher level safety" (and also efficiency)... you might want
> to take a look at ADA's "protected types" (and the "proxy model"):
>
> http://groups.google.com/groups?threadm=3D7E18EB.BC80C2EB%40web.de
> http://groups.google.com/groups?threadm=3D7E24FC.E1AE86B0%40web.de
> (Subject: Re: POSIX Threads and Ada)
That was quite instructive. Thank you, Alexander, very much.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost::thread feature request: thread priority
"Alexander Terekhov" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > http://google.com/groups?selm=3f01e07b%40usenet01.boi.hp.com > (Subject: Re: Does anyone think 'volatile' is a platform-independent > way to make variable access thread safe?) > > Check out this entire thread. Follow the links. ;-) Thank you, Alexander, for the links. Seems like the issue is undefined behaviour when casting away volatile. Do I get it right? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost::thread feature request: thread priority
"Alexander Terekhov" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Maxim Egorushkin wrote: > > > > "Alexander Terekhov" <[EMAIL PROTECTED]> wrote in message > > news:[EMAIL PROTECTED] > > > > > > Maxim Egorushkin wrote: > > > > > > [... "ala Alexandrescu" volatiles ...] > > > > > > http://groups.google.com/groups?threadm=3EE84807.DD00F4D0%40web.de > > > http://groups.google.com/groups?threadm=3EE861E5.13B60F31%40web.de > > > (Subject: Re: volatile keyword usage philosophy (long!)) > > > > Sorry, I failed to figure out the point in that topics. > > That's okay. But I'd love to :). Is the Alexandrescu's idea of using volatile keyword for designating thread safe member functions somewhat "brain damaged"? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost::thread feature request: thread priority
"Alexander Terekhov" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Maxim Egorushkin wrote: > > [... "ala Alexandrescu" volatiles ...] > > http://groups.google.com/groups?threadm=3EE84807.DD00F4D0%40web.de > http://groups.google.com/groups?threadm=3EE861E5.13B60F31%40web.de > (Subject: Re: volatile keyword usage philosophy (long!)) Sorry, I failed to figure out the point in that topics. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Boost::thread feature request: thread priority
"William E. Kempf" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Now, what you're describing sounds more like this:
>
> class timer
> {
> public:
>timer(boost::function on_event, int ms, bool repeat=false);
> };
>
> Which do you really want?
Yes, this is what I needed.
>
> As for "the problem was that I could be sure that the scheduler thread
> would receive its time slice exactly every 250 ms", you simply can't do
> this, portably or not. Granularity issues of the underlying clock aside,
> I'm not aware of any scheduler that would give you this sort of control,
> and fiddling with the priorities will only give you the illusion that
> you've accomplished what you want.
Totally agreed. I didn't solve the problem, rather I tryed to alleviate it.
You can look at it in the attachments. Finally, I switched to using win32
::CreateWaitableTimer() and ::RegisterWaitForSingleObject() functions.
begin 666 delayed_command_queue.cpp
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M+R\O+R\O#0HO+R!D96QA>65D7V-O;6UA;F1?<75E=64N8W!P#0H-"B-I;F-L
M=61E(")S=&[EMAIL PROTECTED]:"(-"B-I;F-L=61E(")D96QA>65D7V-O;6UA;F1?<75E
M=64N:"(-"B-I;F-L=61E(")M=71E>%]PPT*#0II;FQI;F4@;6EL;&ES96-O;F1S
M('1O7VUI;&QIPT*"6)O;W-T.CIX=&EM92!X.PT*"71O7W1I;64H;2P@
M>"D[#0H)PT*"0ER971U<[EMAIL PROTECTED]'9714:6-K0V]U;G0H*2 M('-T87)T961?
M.PT*"7T-"@T*<')I=F%T93H-"@EC;VYS="!$5T]21"!S=&%R=&5D7SL-"GT[
M#0H-"B\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M+R\O+R\O+R\O+PT*#0IC;&%S65D7V-O;6UA;F1?<75E=65?:6UP
M;" Z('!U8FQI8R!R969?8V]U;G1E9%]I;7!L/&1E;&%Y961?8V]M;6%N9%]Q
M=65U93X-"GL-"@ET>7!E9&5F(&1E;&%Y961?8V]M;6%N9%]Q=65U95]I;7!L
M(&UE.PT*#0IP=6)L:6,Z#0H)9&5L87EE9%]C;VUM86YD7W%U975E7VEM<&PH
M*0T*"0DZ"7-T;W!?*&9A;'-E*0T*"0DL"7!L86YN961?;71?*'!L86YN961?
M+"!P;&%N;F5D7VUU=&5X7RD-"@D)+ ER96%D>5]M=%\H5]M=71E>%\I#0H)"2P)<&QA;FYE[EMAIL PROTECTED];&4-"@E[#0H)"7!L86YN
M961?;&]C:R!L*&-O;G-T7V-A%]T>7!E
M)CXH<&QA;FYE9%]M=71E>%\I*3L-"@D)8V]N%]T>7!E)CXH<&QA;FYE9%]M
M=71E>%\I*3L-"@D)8V]N5]U<%]A
M;&Q?:6UP;"@I.PT*"7T-"@T*"79O:[EMAIL PROTECTED];"@I('9O;&%T:6QE
M#0H)>PT*"0EP;&%N;F5D7VUT7RT^8VQE87(H*3L-"@D)[EMAIL PROTECTED]("8F(')E861Y7VUT
M7RT^96UP='DH*3L-"@E]#0H-"G!R:79A=&4Z#0H)=F]I9"!S8VAE9'5L95]I
M;7!L*&-O;G-T(&-O;6UA;F1?<"[EMAIL PROTECTED]"!S96-O;F1S(&1E;&%Y*0T*"7L-
M"@D)9&5L87D@/2!T;U]M:6QL:7-E8V]N9',H9&5L87DI.PT*"0EP;&%N;F5D
M7VQI5]U<%]A;&Q?:6UP;"@I#0H)>PT*
M"0EF;W(@*'!L86YN961?;&ES=#HZ:71EPT*"0DZ.E-E=%1HPT*"0D)%\I.PT*"0D)#0H)"0EI9B H<&QA;FYE
M9%\N96UP='DH*2D-"@D)"0EC;VYT:6YU93L-"@T*"0D)<&QA;FYE9%]E;&5M
M96YT)B!E*'!L86YN961?+F9R;VYT*"DI.PT*#0H)"0EI9B H," \("AE+F=E
M=#PP/[EMAIL PROTECTED]("T](',N96QA<'-E9"@I*2D-"@D)"0EC;VYT:6YU93L-"@T*"0D)
M>PT*"0D)"7)E861Y7VQO8VL@5\N<'5S:%]B86-K*&4N9V5T/#$^*"DI.PT*"0D)"6]N95]R96%D>5\N;F]T
M:[EMAIL PROTECTED]"0D)?0T*"0D)<&QA;FYE9%\N<&]P7V9R;VYT*"D[#0H)
M"7T-"@E]#0H-"@EV;VED('=O5]M=71E>%\I.PT*#0H)"0EI9B H&5C=71E*"D[
M#0H)"7T-"@E]#0H-"G!R:79A=&4Z#0H)=F]L871I;&[EMAIL PROTECTED];"!S=&]P7SL-
M"@T*"71Y<&[EMAIL PROTECTED]7!E9&5F(&)O;W-T.CIM=71E>#HZ"!P;&%N;F5D7VUU=&5X7SL-"@EV;VQA
M=&EL92!U=&EL.CIM=71E>%]P%]P65D
M7V-O;6UA;F1?<75E=65?<"!D96QA>65D7V-O;6UA;F1?<75E=65?8W1O<[EMAIL PROTECTED]
M#0I[#0H)65D7V-O;6UA;F1?<75E=65?:6UP;#L-
M"GT-"@T*+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
.+R\O+R\O+R\O+R\O#0H`
`
end
begin 666 delayed_command_queue.h
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M+R\O+R\O#0HO+R!D96QA>65D7V-O;6UA;F1?<75E=64N: T*#0HC<')A9VUA
M(&]N8V4-"@T*(VEN8VQU9&4@(G)E9E]C;W5N=&[EMAIL PROTECTED]"B\O+R\O+R\O
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+PT*
M#0IS=')[EMAIL PROTECTED];6%N9" Z(')E9E]C;W5N=&5D#0I[#0H)=FER='5A;"!V
M;VED(&5X96-U=&4H*2 ](# [#0I].PT*='EP961E9B!B;V]S=#HZ:6YT7!E
M9&5F(&EN="!S96-O;F1S.PT*#0IS=')[EMAIL PROTECTED]&5L87EE9%]C;VUM86YD7W%U
M975E(#H@[EMAIL PROTECTED];&4@/2 P
M.PT*"79I<[EMAIL PROTECTED]"!H=7)R>5]U<%]A;&PH*2!V;VQA=&EL92 ](# [
M#0H)=FER='5A;"!V;VED(&-A;F-E;%]A;&PH*2!V;VQA=&EL92 ](# [#0H)
M=FER='5A;"!B;V]L(&5M<'1Y*"[EMAIL PROTECTED];&[EMAIL PROTECTED]65D7V-O;6UA;F1?<75E=65?<#L-"@T*9&5L87EE9%]C
M;VUM86YD7W%U975E7W @9&5L87EE9%]C;VUM86YD7W%U975E7V-T;W(H*3L-
M"@T*+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
++R\O+R\O+R\O#0H`
`
end
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Boost::thread feature request: thread priority
"William E. Kempf" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> > Speaking about the timer I ment something like that:
> >
> > typedef int milliseconds;
> >
> > class stopwatch
> > {
> > public:
> > stopwatch()
> > : started_(::GetTickCount())
> > {}
> >
> > milliseconds elapsed() const
> > {
> > return ::GetTickCount() - started_;
> > }
> >
> > private:
> > const DWORD started_;
> > };
>
> Ahh... that's not a threading concept ;).
Let me disagree here :) A couple of days ago I was implementing a user mode
task scheduler. And I had the scheduler thread updating the tasks delays 4
times per second and putting ready for execution tasks in the execution
queue. I tryed to make it portable but the problem was that I could be sure
that the scheduler thread would receive its time slice exactly every 250 ms.
To solve the problem I decided to increase the scheduler thread priority and
to measure the time the thread spent sleeping till the next time slice. I
was using boost::thread library and my solution could be implemented by
means of the library and made my code unportable. That was the rationale of
my posting.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost::thread feature request: thread priority
"William E. Kempf" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Priorities are implemented, but still undergoing design changes, in the
> thread_dev branch. The timer, if I understand what you want, is trivial
> to implement portably with the current Boost.Threads interfaces, but I do
> plan on addressing this as well.
Speaking about the timer I ment something like that:
typedef int milliseconds;
class stopwatch
{
public:
stopwatch()
: started_(::GetTickCount())
{}
milliseconds elapsed() const
{
return ::GetTickCount() - started_;
}
private:
const DWORD started_;
};
>
> > I'm aware of the fact that it's very operating system specific. But I do
> > think that it could be done with elegance and ease in the spirit the
> > whole library adhere. The first thing to come in mind is to add a couple
> > of member functions to boost::thread like this:
> >
> > class thread
> >
> > {
> >
> > // ...
> >
> > void increase_priority();
> >
> > void decrease_priority();
>
> Not that useful, IMO. Usually you want to set a specific priority, and
> this interface would require several calls to do so. Further, these calls
> can fail, so should probably have bool return types.
Agree.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Boost::thread feature request: thread priority
Hello,
I've been missing a feature in the thread library: managing a thread
priority. And, BTW, the class encapsulating stopwatch functionality with a
millisecond precision would be very useful. It would help writing more
portable programs (as boost::thread is portable).
I'm aware of the fact that it's very operating system specific. But I do
think that it could be done with elegance and ease in the spirit the whole
library adhere. The first thing to come in mind is to add a couple of member
functions to boost::thread like this:
class thread
{
// ...
void increase_priority();
void decrease_priority();
// ...
};
I'd really love to have this abilities in the boost::thread.
Please, tell me, whether it's possible?
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: mpl::push_back<> broken?
"David Abrahams" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > In this version of MPL, vector only supports push_front/pop_front, so > that it's possible to write algorithms which work on both lists and > vectors. The next version will fix that by providing list (O(1) front > operations), vector (O(1) back operations), and deque (both). > > HTH, > -- > Dave Abrahams > Boost Consulting > www.boost-consulting.com Ok (sigh), thank you. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] mpl::push_back<> broken?
Hi,
I have some difficulty with mpl::push_back<>. It's the reason for compile
time errors on Intel C++ 7 and MS VC 7.1. I had to switch to using
mpl::insert<> instead.
The error on MS VC 7.1 is:
mpl_sort.cpp(60) : error C2039: 'type' : is not a member of
'boost::mpl::push_back'
Please see the attached file line 60 for details.
begin 666 mpl_sort.cpp
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M+R\O+R\O+R\O+PT*#0HC9&5F:6YE($E.251'54E$#0HC:6YC;'5D92 \9W5I
M9&1E9BYH/@T*(V1E9FEN92!554E$($=5240-"@T*(VEN8VQU9&4@/'1Y<&5I
M;F9O/@T*(VEN8VQU9&4@/&EO7!E
M+ T*(" @(" @("!07!E9&5F($]U=%-E
M<75E;F-E('1Y<&4[#0I].PT*#0IT96UP;&%T93QC;&%S7!E;F%M92!)=&5R.CIT>7!E(&ET96U?.PT*(" @
M('1Y<&[EMAIL PROTECTED]'EP96YA;64@;7!L.CIU<'!E7!E
M;F%M92!M<&PZ.FEN7!E;F%M92!M<&PZ.G!UPT*
M(" @('5S:6YG(&YA;65S<&%C92!S=&0[#0H-"B @("!R971UUP-"B @("!S=')U8W0@;65T85]U=6ED7 T*(" @
M('M<#0H@(" @(" @(&5N=6T@>R!P87)T7S,@/2!L('T[7 T*(" @(" @("!E
M;G5M('L@<&%R=%\R([EMAIL PROTECTED]'7!E9&5F(&UP;#HZ8F]O;%\\=F%L=64^('1Y<&4[#0H)?3L-
M"GT[#0H-"B\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M+R\O+R\O+R\O+R\O+R\O+R\-"@T*1$5&24Y%7U-4549&*$$L(#!X839B9F0V
M.&$L(#!X,V(U-"P@,'@T8S=A+" P>&$P+" P>#=E+" P>#,Y+" P>&,Q+" P
M>#DL(#!X8S#0R-#(L(#!X8F4L(#!X8C L(#!X8V0L(#!X-S,L
M(#!X8F,L(#!X86,L([EMAIL PROTECTED](#!X-CDI#0I$149)3D5?4U151D8H0RP@,'@X
M86%E-V9E9"P@,'@V,#=C+" P>#0T-#0L(#!X868L(#!X9C$L(#!X8V8L(#!X
M,S(L(#!X.3DL(#!X8S(L(#!X8C,L(#!X9C0I#0I$149)3D5?4U151D8H1"P@
M,'AC,3,V86%A,2P@,'AA,3DY+" P>#1F,[EMAIL PROTECTED]([EMAIL PROTECTED](#!X8S$L(#!X-F0L
M(#!X-C&8X8C0S-S-A+" P>[EMAIL PROTECTED]@,'@T,64R+" P>&)D+" P>#0R+" P>&5F
M+" P>#$P+" P>#DT+" P>#1A+" P>#)D+" P>[EMAIL PROTECTED]&24Y%7U-4549&
M*$8L(#!X9&1D,S Q9F(L(#!X8F%C-BP@,'@T,3AE+" P>&)F+" P>#-B+" P
M>#%C+" P>#DV+" P>#(L(#!X9#4L(#!X-68L(#!X-C##=D+" P>#(S+" P>[EMAIL PROTECTED]" P>#9E+" P>&5D*0T*1$5&24Y%7U-4
M549&[EMAIL PROTECTED](#!X939D,S,T9C#EE+" P>[EMAIL
PROTECTED]
M+" P>&-E+" P>&,Q+" P>&-B+" P>&(T+" P>&0U+" P>&,V*0T*1$5&24Y%
M7U-4549&*$DL(#!X83(X83=C,CDL(#!X9F1C,RP@,'@T,C W+" P>[EMAIL PROTECTED]" P
M>#,Y+" P>&0W+" P>&%A+" P>&9D+" P>##&4S*0T*1$5&
M24Y%7U-4549&*$HL(#!X.6$P-3(P-&(L(#!X-38S9"P@,'@T8SDU+" P>#ED
M+" P>&8Y+" P>#0L(#!X860L(#!X.&(L(#!X,F8L(#!X.6$L(#!X-S4I#0I$
M149)3D5?4U151D8H2RP@,'AF9C!F-#!F9"P@,'@U8S,S+" P>#0R86(L(#!X
M8C0L(#!X."P@,'AA9"P@,'@Y8RP@,'@W82P@,'@W9BP@,'AE,2P@,'AE-RD-
M"D1%1DE.15]35%5&1BA,+" P>#8W,V(R9C8V+" P>#8R-BP@,'@T-3=B+" P
M>#AF+" P>&%F+" P>&,V+" P>&9E+" P>#&,R+" P>&(Y+" P>#,U
M*0T*1$5&24Y%7U-4549&*$TL(#!X,F1B.#[EMAIL PROTECTED]" P>&-A+" P>#8W+" P>&$Q+" P>&1D+" P>&$S+" P>#8P+" P
M>&4Q*0T*1$5&24Y%7U-4549&*$XL(#!X.31B,&0V,68L(#!X-F%F92P@,'@T
M-&4Q+" P>&$W+" P>#-A+" P>#DL(#!X96,L(#!X-F$L(#!X-V(L(#!X9C$L
M(#!X-60I#0I$149)3D5?4U151D8H3RP@,'@R,&,S8C%C-2P@,'@T9&$T+" P
M>#1D83DL(#!X.&4L(#!X-3(L(#!X.#0L(#!X-&$L(#!X930L(#!X9F(L(#!X
M.#DL(#!X.3DI#0I$149)3D5?4U151D8H4"P@,'AF-3!F,&4P8BP@,'@[EMAIL PROTECTED]
M+" P>#1D-6$L(#!X.3(L(#!X-64L(#!X-C(L(#!X9C8L(#!X,[EMAIL PROTECTED](#!X83$L
M(#!X-SDL(#!X.30I#0I$149)3D5?4U151D8H42P@,'@S93-B834X,2P@,'AE
M.#&)E+" P>[EMAIL PROTECTED]&24Y%7U-4549&*%(L(#!X,[EMAIL PROTECTED](#!X
M9C8X+" P>#0W9C#1F9F0L(#!X.&$L(#!X8S$L(#!X-&(L(#!X8F8L(#!X,38L
M(#!X8CDL(#!X9F,L(#!X86$I#0I$149)3D5?4U151D8H5"P@,'@V-3EF-&$S
M,BP@,'AF-V5F+" P>#1F-#DL(#!X838L(#!X-38L(#!X,RP@,'AC8RP@,'@W
M8BP@,'@W,BP@,'AA,BP@,'AD82D-"D1%1DE.15]35%5&1BA5+" P>&9F83&,U868L(#!X-&(Y."P@,'@X8RP@,'@S-BP@,'@W9BP@,'@W,"P@
M,'@W9BP@,'@U-RP@,'AD,"P@,'@R*0T*1$5&24Y%7U-4549&*%8L(#!X,F4P
M-39A-V0L(#!X8F5E9BP@,'@T,#(U+" P>#DY+" P>#0V+" P>&0V+" P>#&4T+" P>#5B+" P>#)D+" P>&9D*0T*1$5&24Y%7U-4549&*%&%F+" P>#=C+" P>&%A+" P
M>#8L(#!X,S L(#!X9# L(#!X,[EMAIL PROTECTED](#!X93$I#0I$149)3D5?4U151D8H6"P@
M,'@[EMAIL PROTECTED](P-2P@,'AD-S$W+" P>#0V-S,L(#!X83 L(#!X,6$L(#!X-#$L
M(#!X-S$L(#!X-C&$P,#0Y964L(#!X8S0S,2P@,'@T9#$S+" P>#DU+" P>&,X+" P>&9C
M+" P>#0T+" P>[EMAIL PROTECTED]" P>#4T+" P>#$P+" P>#$U*0T*1$5&24Y%7U-4549&
M*%HL(#!X9F(Q.65F9# L(#!X-34Y,BP@,'@T-F5D+" P>&(R+" P>#(L(#!X
M-#$L(#!X-V(L(#!X-3PT*(" @(&]U='!U=%]I;G1E7!E
M.PT*"7T[#0I].PT*#0IT96UP;&%T93QC;&%SPT*(" @('5S:6YG(&YA;65S<&%C92!S
M=&0[#0H-"B @("!C;W5T#0H@(" @(" @(#P\(")5;F]D97)E9"!I;G1E
[boost] Re: Re: Re: Interest in library generatingstreambufsfromobjects
"Larry Evans" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I'll soon upload a commented an simplified version of marg_ostreambuf
> and maybe a templatized version to parameterize the addedState. I may
> rename it too to decorated_ostreambuf or something similar.
I think there is no need for marg_ostream at all. Why reinvent a bicycle if
one can use original std::basic_ostream<>. And it would be great if
marg_ostreambuf were parameterized by char and traits types like original
std::basic_streambuf<>.
Here is the code for decorator.
begin 666 main_cout.cpp
M(VEN8VQU9&4@(F)O;W-T+V-O;%]I;R]M87)G7V]S=')E86TN:'!P(@T*#0HO
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M+R\O+R\-"@T*=&5M<&QA=&4\8VQA7!E;F%M
M92!S=')E86U?='EP93HZ8VAA7!E(&-H87)?='EP93L-"@ET>7!E9&5F
M('1Y<&5N86UE('-T7!E.CIT7!E9&5F('-T9#HZ8F%S:6-?7!E.PT*#0IP=6)L:6,Z#0H):61E;G1?
M9&5C;W)A=&]R*'-T7!E)B!S+"!I;G0@:61E;G0@/2 R*0T*"0DZ
M"7-TPT*"0ES=')E86U?+G)D8G5F*"9M87)G
M:6Y?*3L-"@E]#0H-"@E^:61E;G1?9&5C;W)A=&]R*"D-"@E[#0H)"7-T6YC*"D[#0H)"6UAPT*"6-O;G-T(&-H87(J(&QI;F4@/2 B
M;&EN92([#0H):6YT(&YU;3TP.PT*"6-O=70\/&YU;2LK/#QE;F1L.PT*"6-O
M=70\/&QI;F4\/&5N9&P[#0H@(" @8V]U=#P\(F)E9VEN(&UAPT*"0D):61E;G1?9&5C;W)A=&]R/'-T9#HZ;W-T'@B*3L-"@D)"[EMAIL PROTECTED];G5M*RL\/&5N9&P[#0H)"0D)(&-O=70\
M/&QI;F4\/&5N9&P[#0H)"0D)("TM9&5C;W)A=&]R.PT*"0D)"2!C;W5T/#QN
M=6TK*SP\96YD;#L-"@D)"[EMAIL PROTECTED](B$A(2(\/&5N9&P[#0H)"0D)("TM
M9&5C;W)A=&]R.PT*"0D)"2!D96-O
[boost] Re: Re: Interest in library generating streambufs fromobjects
"Larry Evans" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > I had a brief look and it looks promising. However, I'm wondering > if some of the complexity can be avoided. I had a hard time figuring > out just how to get marg_ostreambuf in files/col_io/col_io.zip to work > with buffered input. After thinking some more, I thought about just > using overflow and sputc to "pipe" the output to the next streambuf. > This greatly simplified the code. Would something similar work with > your code. In particular, can you create an equivalent to marg_ostream > from files/col_io/col_io.zip by using your, I guess, stream buffer > redirectors? I'd like to see that. Maybe Reece Dunn would also since > he's "interested in indentation facilities." I've examined col_io. At a high point of view it is the decorator pattern - you extend basic_ostream<> interface with identation capabilities. The code I posted, particulary input/output_buffer classes, is the adapter pattern - it adds basic_streambuf<> interface to a sequence. So, this patterns have different purposes. If I get you right you want to see how one can add identation capabilites to a buffer using the adapters. Well, it could be done but it would be somewhat onerous. One would have to wrap an existing buffer with a developed sequence model class that will transform the input and put it in the wrapped buffer. And then wrap the sequence model with the output_buffer class. I think it is not worth an effort. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Interest in library generating streambufs
"Jonathan D. Turkanis" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Yes, this is very elegant. No codecvt's in sight -- just pure adaptors. Also > nice treatment of optional template parameters. It puts my design (and > certain my implementation) to shame. I should have thought more about the > general idea of composition before responding to posts. I stole the idea of Named Template Parameters from Boost Iterator Adapters white papers. :) ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Interest in library generating streambufs from objects
"Jonathan D. Turkanis" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Thanks for your interest. I have posted the library at
> http://groups.yahoo.com/group/boost/files/streambuf_lib/.
>
> The implementation needs to be streamlined, but it works, and the main
ideas
> are clear enough.
Hi,
I posted here a while ago streambuf adapters. There was no any answer. May
be you might find it intresting.
The main idea is simple: to present any linear sequence as
std::basic_streambuf<>.
Here are the file.
begin 666 sequence_buffer.hpp
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M+R\O+R\O#0HO+R!S97%U96YC95]B=69F97(N: T*#0HC<')A9VUA(&]N8V4-
M"@T*(VEN8VQU9&4@/&%L9V]R:71H;3X-"B-I;F-L=61E(#QI=&5R871O6%B;&4N:'!P
M/@T*(VEN8VQU9&4@/&)O;W-T+W1Y<&5?=')A:71S+FAP<#X-"B-I;F-L=61E
M(#QB;V]S="]M<&PO=F]I9"YH<' ^#0HC:6YC;'5D92 \8F]O6YO<'-I
M&%M<&QE2!P87)A;65T
M97)S#0H)"6-L87-S('-E<75E;F-E7VUO9&5L#0H)+R\@;W!T:6]N86P@<&%R
M86UE=&5R2!P
M87)A;65T97)S#0H)"6-L87-S('-E<75E;F-E7VUO9&5L#0H)+R\@;W!T:6]N
M86P@<&%R86UE=&5RWT[#0IS=')[EMAIL PROTECTED]>F5?=&%G('M].PT*#0IT96UP;&%T
M93QC;&%SPT*"71Y<&[EMAIL PROTECTED]&%G(&YA;64[#0H)='EP961E9B!4('1Y<&4[#0I]
M.PT*#0IS=')[EMAIL PROTECTED]&5F875L=%]P87)A;65T97)?=&%G('M].PT*#0IS=')U
[EMAIL PROTECTED]&5F875L=%]P87)A;65T97(-"@DZ"61E9FEN95]P87)A;65T97(\9&5F
M875L=%]P87)A;65T97)?=&%G+"!M<&PZ.G9O:61?/B![?3L-"@T*+R\O+R\O
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M#0H-"G1E;7!L871E/&-L87-S(%0^#0IC;&%S7!E
M9&5F(&EN<'5T7W-E<75E;F-E7V-O;F-E<'0@:6YP=70[#0H-"@ES:7IE7W0@
MF5?="!S:7IE*2 O+R!B>71E(&)U9F9E
MF4I.PT*"7T-"GT[#0H-"G1E;7!L
M871E/&-L87-S(&UO9&5L/@T*8VQA7!E9&5F(&]U='!U=%]S97%U96YC95]C;VYC
M97!T(&]U='!U=#L-"@T*"79O:[EMAIL PROTECTED])I=&4H8V]N<[EMAIL PROTECTED]"[EMAIL
PROTECTED]
M+"!S:7IE7W0@<[EMAIL PROTECTED]@8GET92!B=69F97);PT*<')I=F%T93H-"@ET>7!E9&5F('1Y<&5N86UE('-T9#HZ:71EF4I#0H)>PT*"0EI9B HF5O9BAC:&%R7W1Y<&4I*0T*"0D)=&AR;W<@F4@/2!S=&0Z.FUI
M;CQS:7IE7W0^*'-I>[EMAIL PROTECTED]:7IE;V8H8VAA[EMAIL PROTECTED] M(&)E
M9VEN7RD[#0H)"7-T9#HZ8V]P>2AB96=I;E\L(&)E9VEN7R K('-I>F4L('-T
M871I8U]C87-T/&-H87)?='EP92H^*&)U9F9E[EMAIL PROTECTED]:7IE;V8H8VAA7!E*3L-"@E]
M#0H-"G!R:79A=&4Z#0H):71EF5O9BAC:&%R7W1Y<&4I
M(#X@F5O9BAC:&%R7W1Y<&4I.PT*"0ES=&0Z.F-O<'DH7!E*CXH8G5F9F5R*2P-"@D)"7-T871I8U]C87-T/&-O
M;G-T(&-H87)?='EP92H^*&)U9F9E<[EMAIL PROTECTED]:7IE+"!B96=I;E\I.PT*"0EB
M96=I;[EMAIL PROTECTED]@7!E(&-H87)?='EP93L-"@T*<'5B;&[EMAIL PROTECTED]
M"7!UF4I#0H)>PT*"0EI9B HF5O9BAC:&%R7W1Y
M<&4I*0T*"0D)=&AR;W<@7!E*CXH8G5F9F5R*2P-"@D)"7-T871I8U]C87-T/&-O;G-T(&-H
M87)?='EP92H^*&)U9F9E<[EMAIL PROTECTED]:7IE("\@WT[#0H-"G1E;7!L871E/&-L87-S
M(%0^#0IS=')[EMAIL PROTECTED]WT[#0H-"G1E;7!L871E
M/'-I>F5?="!S:7IE/@T*PT*#0IT96UP;&%T93QC;&%SPT*<'5B;&[EMAIL PROTECTED]"71Y<&[EMAIL PROTECTED]'EP96YA;64@7!E.PT*"71Y<&[EMAIL PROTECTED]'EP96YA;64@7!E9&5F('-T9#HZ8F%S
M:6-?R!S7RYR9&)U9BAB7RD[('T-"@T*"79O:60@
MPEB7R ]('-?+G)D8G5F*'[EMAIL PROTECTED]
M#0H)=F]I9"!F;'5S:"@I('[EMAIL PROTECTED]7!E/B8I('M]#0H-"@ES
M=')E86TF('-?.PT*"6)U9F9E<[EMAIL PROTECTED]("\O(&YA;65S<&%C
M92!D971A:6P-"@T*+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M+R\O+R\O+R\O+R\O+R\O+R\O#0HO+R!I7!E9&5F
M('-T9#HZ8F%S:6-?:7-TPT*"71Y<&5D968@7!E9&5F(&1E=&%I;#HZ7!E9&5F('1Y<&5N86UE(&)APT*"71Y<&5D
M968@7!E9&5F
M(&1E=&%I;#HZPT*
M"0ER961I7!E9&5F('-T9#HZ8F%S:6-?;W-T7!E;F%M92!D971A:6PZ.F]P=&EO;F%L7W!A7!E#0H)"3X-"@DL"7!R:79A=&[EMAIL PROTECTED]&5T86EL.CIO<'1I;VYA;%]P87)A
M;65T97)S/&)U9F9E7!E9&5F('1Y<&5N86UE('!A
M7!E.PT*"71Y<&[EMAIL PROTECTED]'EP
M96YA;64@<&%R86UE=&5RPT*"0ER96QE87-E7V)U9F9E<[EMAIL PROTECTED]"7T-"@T*
M<')O=&5C=&[EMAIL PROTECTED]"7-E<75E;F-E7V-O;F-E<'0F(&[EMAIL PROTECTED]
M('L@PT*"0D)8VAA7!E*B!B
M=69F97(@/2!A;&QO8V%T95]B=69F97(H*3L-"@D)"7-E=&F4I.PT*
M"0E]#0H)?0T*#0H)=F]I9"!PPT*"0ER971U<[EMAIL PROTECTED]&AIPT*"0ET:&ES+3YA;&QO8V%T;W(Z.F1E86QL;V-A=&4H96)A
[EMAIL PROTECTED]>F4I.PT*"0ES971G*# L(# L(# I.PT*#0H)"71H
M:7,M/F%L;&]C871O7!E;F%M92!S97%U96YC
M95]M;V1E;#HZ:6YP=70L(% Q+"!0,[EMAIL PROTECTED],L(% T/@T*>PT*<')I=F%T93H-
M"@ET>7!E9&5F(&1E=&%I;#HZ8G5F9F5R7V)A7!E"0EC:&%R7W1Y<&4[#0H)
M='EP961E9B!T>7!E;F%M92!B87-E.CITF5?= D)"0D)"6)U9F9EF4[#0H-"@ET>7!E9&5F('1Y<&5N86UE
M('-E<75E;F-E7VUO9&5L.CII;G!U="!S97%U96YC95]C;VYC97!T.PT*"0T*
M#0IP=6)L:6,Z#0H):6YP=71?8G5F9F5R*'-E<75E;F-E7V-O;F-E<'0F('-E
M<75E;F-E*0T*"0DZ"6)AWT-"@T*<')I=F%T93H-
M"@EI;G1?='EP92!U;F1EF5?="!R96%D.PT*"0EI9B H*')E860@/2!G971?
M7!E.CIT;U]I;G1?='[EMAIL PROTECTED])A8VLH*2D[#0H)"7T-"@D)96QS90T*
M"0E[#0H)"0ER971U<[EMAIL PROTECTED]')A:71S7W1Y<&[EMAIL PROTECTED]"0E]#0H)?0T*
M?3L-"@T*+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M+R\O+R\O+R\O+R\O#0H-"G1E;7!L871E/ T*"0EC;&%S7!E9&5F
M('1Y<&5N86UE(&)A7!E"0ET7!E9&5F('1Y<&5N86UE('1R86ET7!E.CII;G1?='EP90EI;G1?='EP
M93L-"@ES=&%T:6,@8V]NF4@/2!B
M87-E.CIB=69F97)?F5O9BAC
M:&%R7W1Y<&4I*3L-"@D)"7-E=' H<&)A<
[boost] MS VC++ 7.x and BOOST_NO_MEMBER_TEMPLATE_FRIENDS
Doesn't Microsoft VC++ compilers starting from version 7 support member template friends? #if _MSC_VER <= 1310 # define BOOST_NO_MEMBER_TEMPLATE_FRIENDS #endif ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] boost::any feature request
-Original Message-
From: Vladimir Prus [mailto:[EMAIL PROTECTED]
Sent: Monday, March 24, 2003 10:25 AM
To: Boost mailing list
Subject: Re: [boost] boost::any feature request
[]
P.S. And, BTW, it would be great to see the complete code that you
propose (or
a diff to CVS HEAD).
Here are the sources I played with. It's far from perfect, but I think
the basic idea is clear.
The TailoredAny<> class has the prototype:
template
class TailoredAny;
So, it can be parametrized with the type identification strategy, not
the memory allocation strategy only.
And here are the Intel VTune results (see the sources for details):
CreationAssignment
struct 13383 27358
boost::any 3846331870
TailoredAny<> 9151310717
TailoredAny 3855110022
If we throw away the type identification strategy and leave it hardcoded
as in the original boost::any the result of the TailoredAny<> will be
better.
// TailoredAny.h
#pragma once
#include
#include
#include
struct RttiTypeInfoStrategy
{
typedef Loki::TypeInfo TypeInfo;
template
static TypeInfo Identify() { return typeid(T); }
template
static TypeInfo Identify(const T& t) { return typeid(t); }
};
template
class TailoredAny
{
public:
typedef TypeInfoStrategy_ TypeInfoStrategy;
typedef typename TypeInfoStrategy_::TypeInfo TypeInfo;
TailoredAny()
: content_(0)
{}
template
TailoredAny(const ValueType_& value)
: content_(new Holder_(value))
{}
TailoredAny(const TailoredAny& other)
: content_(other.content_ ? other.content_->Clone() : 0)
{}
~TailoredAny() { delete content_; }
template
TailoredAny& operator=(const ValueType_& value)
{
TailoredAny(value).Swap(*this);
return *this;
}
TailoredAny& operator=(const TailoredAny& other)
{
TailoredAny(other).Swap(*this);
return *this;
}
void Swap(TailoredAny& other)
{
std::swap(content_, other.content_);
}
bool Empty() const { return !content_; }
TypeInfo Type() const
{
return content_ ? content->Type() :
TypeInfoStrategy_::Identify();
}
private:
struct PlaceHolder_ : NewStrategy_
{
virtual TypeInfo Type() const = 0;
virtual PlaceHolder_* Clone() const = 0;
virtual ~PlaceHolder_() {}
};
template
struct Holder_ : PlaceHolder_
{
Holder_(const ValueType_& value)
: held_(value)
{}
TypeInfo Type() const
{
return TypeInfoStrategy_::Identify(held_);;
}
PlaceHolder_* Clone() const
{
return new Holder_(held_);
}
ValueType_ held_;
};
template
friend ValueType_* TailoredAnyCast(TailoredAny*);
PlaceHolder_* content_;
};
template
ValueType_* TailoredAnyCast(TailoredAny* operand)
{
typedef TailoredAny::TypeInfoStrategy TypeInfoStrategy;
return operand && operand->Type() == TypeInfoStrategy::Identify()
? &static_cast::Holder_*>(operand->content_)->held_
: 0;
}
template
const ValueType_* TailoredAnyCast(const TailoredAny* operand)
{
return TailoredAnyCast(const_cast*>(operand));
}
template
ValueType_ TailoredAnyCast(const TailoredAny& operand)
{
const ValueType_* result = TailoredAnyCast(&operand);
if(!result)
throw std::bad_cast();
return *result;
}
// play_with_any.cpp : Defines the entry point for the console application.
//
#include
#include
#include
#include
#include
#include
#include "TailoredAny.h"
typedef std::basic_string tstring;
// 'typical' properties structure
template
struct Properties;
template<>
struct Properties
{
bool bool1;
int int1;
int int2;
int int3;
int int4;
double double1;
tstring string1;
};
template
struct Properties
{
Variant_ bool1;
Var
[boost] boost::any feature request
Title: Сообщение
I think it would be great to make boost::any's
memory allocation strategy for value holder customizable. It would allow to use
not only global new operator, but any other special fast allocators like, for
example, Loki::SmallObject.
The changes are minor and would not break
existing code.
All it takes is to change class name
and:
struct use_default_allocator
{};
//class any
template
class any_ex
{
// ...
// class placeholder
class placeholder : public A // derive
operators new() and delete()
// ...
};
typedef any_ex<> any; // for not breaking
existing code
And change any_cast functions
appropriately.
I've measured performance using Intel VTune.
The any_ex was about twice as fast as any_ex<>
with MS VC++ 7 and Intel C++ 7.
There is sure a possibility to write a faster
allocator than Loki::SmallObject.
So, the hardcoded memory allocation strategy
makes more harm then good to boost::any. Changes would make boost::any
more extensible and reusable.
