[compressed_pair] Broken compilers workaround suggestion

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[compressed_pair] Broken compilers workaround suggestion

Robert Kawulak-2
Hi,

Recently I've discovered that Digital Mars compiler (version
8.42n) has problems when compiling boost::compressed_pair. The
problem is in the member functions first() and second() in cases
when compressed_pair is derived from either first or second type.
To fix the problem, *this must be explicitly converted to the
return type, so the functions would look like this:

  second_reference second() { return
static_cast<second_reference>(*this); }

instead of the way they're implemented now:

  second_reference second() { return *this; }

If the problem wasn't mentioned before, then I'd suggest to fix
it. The solution is quite easy to introduce and AFAICT has no
negative side effects. Does anybody object to this?

The changes have to be done in the following lines: 158, 159,
203, 204, 244, 245, 247, 248, 280, 281 of
boost/detail/compressed_pair.hpp file. Also, the comment in line
256 is out-of-date after changes made by John Maddock in 25 Jan
2004:

   //      Note does not actually store an instance of T2 at all
-
   //      but reuses T1 base class for both first() and
second().

This could be removed as well.

Best regards,
Robert



----------------------------------------------------------------------
Kliknij po wiecej! >>> http://link.interia.pl/f18ed

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [compressed_pair] Broken compilers workaround suggestion

David Abrahams
"Robert Kawulak" <[hidden email]> writes:

> Hi,
>
> Recently I've discovered that Digital Mars compiler (version
> 8.42n) has problems when compiling boost::compressed_pair. The
> problem is in the member functions first() and second() in cases
> when compressed_pair is derived from either first or second type.
> To fix the problem, *this must be explicitly converted to the
> return type, so the functions would look like this:
>
>   second_reference second() { return
> static_cast<second_reference>(*this); }

Should be boost::implicit_cast<second_reference>(*this);

> instead of the way they're implemented now:
>
>   second_reference second() { return *this; }
>
> If the problem wasn't mentioned before, then I'd suggest to fix
> it. The solution is quite easy to introduce and AFAICT has no
> negative side effects. Does anybody object to this?

I don't object, but the obfuscation of the code is a negative side
effect.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [compressed_pair] Broken compilers workaround suggestion

Robert Kawulak
Hi,

> From: David Abrahams

> >   second_reference second() { return
> > static_cast<second_reference>(*this); }
>
> Should be boost::implicit_cast<second_reference>(*this);

Hmmm... I've tried to replace static_cast with implicit_cast, but
then the compilation error with DM comes back :-/

> > If the problem wasn't mentioned before, then I'd suggest to
fix
> > it. The solution is quite easy to introduce and AFAICT has no
> > negative side effects. Does anybody object to this?
>
> I don't object, but the obfuscation of the code is a negative
side
> effect.

100% right :-) By saying 'negative side effects' I meant no new
compilation or usage problems introduced by this fix. Of course
the cleaner code the better, but OTOH adding a few casts into the
implementation seems rather a low price to pay for better
portability.

What is the procedure for adding fixes like this? Is the author
of the file responsible for this, or should I provide the fixed
version?

Best regards,
Robert


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

[conversion] implicit_cast undocumented

Kim Barrett
In reply to this post by David Abrahams
In a different thread

At 5:55 PM -0500 1/23/06, David Abrahams wrote:
>  >   second_reference second() { return
>>  static_cast<second_reference>(*this); }
>
>Should be boost::implicit_cast<second_reference>(*this);

I didn't remember running across implicit_cast, so went looking for its
documentation. I found various uses and tests (in the conversion library),
but found no documentation for implicit_cast in the boost_1_33_1 release.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [conversion] implicit_cast undocumented

David Abrahams
Kim Barrett <[hidden email]> writes:

> In a different thread
>
> At 5:55 PM -0500 1/23/06, David Abrahams wrote:
>>  >   second_reference second() { return
>>>  static_cast<second_reference>(*this); }
>>
>>Should be boost::implicit_cast<second_reference>(*this);
>
> I didn't remember running across implicit_cast, so went looking for its
> documentation. I found various uses and tests (in the conversion library),
> but found no documentation for implicit_cast in the boost_1_33_1 release.

Right.  But so what?

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [compressed_pair] Broken compilers workaround suggestion

John Maddock
In reply to this post by Robert Kawulak-2
> If the problem wasn't mentioned before, then I'd suggest to fix
> it. The solution is quite easy to introduce and AFAICT has no
> negative side effects. Does anybody object to this?

OK will apply.

> Also, the comment in line
> 256 is out-of-date after changes made by John Maddock in 25 Jan
> 2004:

Well spotted, I'll update that with the rationale for the change.

Thanks, John.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [conversion] implicit_cast undocumented

Michael Goldshteyn
In reply to this post by David Abrahams
"David Abrahams" <[hidden email]> wrote in message
news:[hidden email]...

> Kim Barrett <[hidden email]> writes:
>
>> I didn't remember running across implicit_cast, so went looking for its
>> documentation. I found various uses and tests (in the conversion
>> library),
>> but found no documentation for implicit_cast in the boost_1_33_1 release.
>
> Right.  But so what?
>
> --
> Dave Abrahams

Well, a one or two line comment in its header file (implicit_cast.hpp), at
the very least, describing what it does wouldn't be too much to ask, in my
opinion. Since, historically, you've been the champion of fighting against
terse documentation and ambiguous/overly technical, yet meaning nothing to
the average Joe documentation, I think you would agree with the first
statement.

Just my gratuitous 2 cents,

Michael Goldshteyn



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [conversion] implicit_cast undocumented

Andy Little

"Michael Goldshteyn" <[hidden email]> wrote

> Well, a one or two line comment in its header file (implicit_cast.hpp), at the
> very least, describing what it does wouldn't be too much to ask, in my
> opinion.

Seriously Its best to leave implicit_cast alone. The reason its not documented
is because if it was bad things would happen. Its like those what were they -
japanese pictures ? where the artist deliberately made one mistake. Without that
everything in the boost distro would be perfect and thats asking for trouble.
Thats why its seriously
best to leave it alone.

If any one wants to know what it does, I have knocked this slice of code
together to explain that it actually does nothing at all..

#include <boost/implicit_cast.hpp>

template <typename T>
struct value_typeA{
    T val;
    template <typename T1>
    explicit value_typeA( T1 const & t) : val((t)){}
};

template <typename T>
struct value_typeB{
    T val;
    template <typename T1>
    explicit value_typeB( T1 const & t) : val(boost::implicit_cast<T>(t)){}
};

int main()
{
    value_typeA<double> vA0(1);
    value_typeA<value_typeA<double> >vA1(vA0);
    value_typeA<value_typeA<double> >vA2(1);

    value_typeB<double> vB0(1);
    value_typeB<value_typeB<double> >vB1(vB0);
    value_typeB<value_typeB<double> >vB2(1);
}

regards
Andy Little






_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [conversion] implicit_cast undocumented

Andy Little
I'm joking of course. I think it really needs someone who knows a bit about the
details for this two phase conversion thingy to write a bit of documentation and
put it in say  <libs/conversion/cast.htm>  For myself I know what it does, but
dont know how to describe it, else i'd write it.

regards
Andy Little




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [conversion] implicit_cast undocumented

David Abrahams
In reply to this post by Michael Goldshteyn
"Michael Goldshteyn" <[hidden email]> writes:

> "David Abrahams" <[hidden email]> wrote in message
> news:[hidden email]...
>> Kim Barrett <[hidden email]> writes:
>>
>>> I didn't remember running across implicit_cast, so went looking for its
>>> documentation. I found various uses and tests (in the conversion
>>> library),
>>> but found no documentation for implicit_cast in the boost_1_33_1 release.
>>
>> Right.  But so what?
>>
>> --
>> Dave Abrahams
>
> Well, a one or two line comment in its header file (implicit_cast.hpp), at
> the very least, describing what it does wouldn't be too much to ask, in my
> opinion. Since, historically, you've been the champion of fighting against
> terse documentation and ambiguous/overly technical, yet meaning nothing to
> the average Joe documentation, I think you would agree with the first
> statement.

Oh, I agree.  It's just not an "official" part of any Boost library
yet.  Since I am an author of the cast library I could slip it in
there without too much formality, but I haven't had time to write docs
or tests.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [conversion] implicit_cast undocumented

David Abrahams
In reply to this post by Andy Little
"Andy Little" <[hidden email]> writes:

> I'm joking of course. I think it really needs someone who knows a
> bit about the details for this two phase conversion thingy to write
> a bit of documentation and put it in say <libs/conversion/cast.htm>

2-phase conversion?

> For myself I know what it does, but dont know how to describe it,
> else i'd write it.

It's simple: it's a cast you use when the source type is implicitly
convertible to the target type, to force the implicit conversion.
It's less liberal than static_cast, which will convert in the opposite
direction.

Where's the mystery?

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [conversion] implicit_cast undocumented

Andy Little

"David Abrahams"  wrote

> It's simple: it's a cast you use when the source type is implicitly
> convertible to the target type, to force the implicit conversion.
> It's less liberal than static_cast, which will convert in the opposite
> direction.

Hows the attached? Its <libs/conversion/index.html> with the above info on
implicit_cast
added.


regards
Andy Little


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

index.html (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [conversion] implicit_cast undocumented

Andy Little

"Andy Little" <[hidden email]> wrote in message
news:dr8qlg$ken$[hidden email]...

>
> "David Abrahams"  wrote
>
>> It's simple: it's a cast you use when the source type is implicitly
>> convertible to the target type, to force the implicit conversion.
>> It's less liberal than static_cast, which will convert in the opposite
>> direction.
>
> Hows the attached? Its <libs/conversion/index.html> with the above info on
> implicit_cast
> added.

I can see the attachments  mangled. Here's the text.

regards
Andy Little


<html>

<head>
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Boost Conversion Library</title>
</head>

<body bgcolor="#FFFFFF" text="#000000">

<h1><img border="0" src="../../boost.png" align="center" width="277"
height="86">Boost
Conversion Library</h1>

<p>The Conversion Library improves program safety and clarity by performing
otherwise messy conversions.&nbsp; It includes cast-style function templates
designed to complement the C++
Standard's built-in casts.</p>
<p>To reduce coupling, particularly to standard library IOStreams, the Boost
Conversion Library is
supplied by several headers:</p>
<ul>

<li>The <a href="cast.htm">boost/cast</a> header provides
<b>polymorphic_cast&lt;&gt;</b>
  and <b>polymorphic_downcast&lt;&gt;</b> to perform safe casting between
  polymorphic types.<br>

</li>

<li>The <a href="lexical_cast.htm">boost/lexical_cast</a> header provides
<b>lexical_cast&lt;&gt;</b>
    general literal text conversions, such as an <code>int</code> represented as
    a <code>string</code>, or vice-versa.</li>

<li>The <a href="../../boost/implicit_cast.hpp">boost/implicit_cast</a> header
provides <b>implicit_cast&lt;&gt;</b> which is used when the source type is
implicitly convertible to the target type, to force the implicit conversion.
It's less liberal than static_cast, which will convert in the opposite
direction..<br>

</ul>
<hr>
<p>Revised <!--webbot bot="Timestamp" S-Type="EDITED"
S-Format="%d %B, %Y" startspan -->Jan 25, 2006<!--webbot bot="Timestamp" endspan
i-checksum="30348" -->
</p>

</body>

</html>



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [conversion] implicit_cast undocumented

David Abrahams
"Andy Little" <[hidden email]> writes:

> "Andy Little" <[hidden email]> wrote in message
> news:dr8qlg$ken$[hidden email]...
>>
>> "David Abrahams"  wrote
>>
>>> It's simple: it's a cast you use when the source type is implicitly
>>> convertible to the target type, to force the implicit conversion.
>>> It's less liberal than static_cast, which will convert in the opposite
>>> direction.
>>
>> Hows the attached? Its <libs/conversion/index.html> with the above info on
>> implicit_cast
>> added.
>
> I can see the attachments  mangled. Here's the text.

In future send your attachment as a patch and it will come through OK.

So, thanks, but it's not really sufficient.  Linking to the header is
really unacceptable, IMO.  It should link to an HTML file with a
specification of the signature of implicit cast, its requirements,
effects, etc., and preferably, an example.  

P.S. I can see that I already wrote a test for implicit_cast, so
     consider yourself lucky that I'm not asking you for one of those
     ;-)

P.P.S. I'm actually very grateful that you've done anything; I'm just
       trying to scam you into finishing the job and doing it right
       ;-)

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [conversion] implicit_cast undocumented

Andy Little

"David Abrahams"  wrote

> In future send your attachment as a patch and it will come through OK.

I am have attached 3 items including the patch  (because My last attach test
went OK, but
unfortunately I have to keep changing settings for something else. I hope I got
it right now.( Think its got to be UUencode FWIW) If not I'll try again).

implicit_cast.qbk  and Jamfile to go in new directory
<libs/conversion/implicit_cast/>
patch is for <libs/conversion/index.html>

The jamfile BTW is just based on the Boost.Typeof  doc jamfile by Peder Holt. I
dont know too much about it, but it seems to work ok.

> So, thanks, but it's not really sufficient.  Linking to the header is
> really unacceptable, IMO.  It should link to an HTML file with a
> specification of the signature of implicit cast, its requirements,
> effects, etc., and preferably, an example.

There is a reasonable skeleton there I hope. Obviously you are better placed to
rewrite the text...

> P.S. I can see that I already wrote a test for implicit_cast, so
>     consider yourself lucky that I'm not asking you for one of those
>     ;-)

I'll be interested as I need some expected to fail tests, and I presume there
should be some there.

> P.P.S. I'm actually very grateful that you've done anything; I'm just
>       trying to scam you into finishing the job and doing it right
>       ;-)

Its ten past 2 in the morning here in the U.K, but I'm not saying that to make
feel guilty in any way  ;-)

hmm... hope the attachments dont get mangled... If they do I'll send them
embedded in the message.

regards
Andy Little





begin 666 libs_conversion_index_html.patch
M26YD97@Z(&)O;W-T+VQI8G,O8V]N=F5R<VEO;B]I;F1E>"YH=&UL#0H]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]#0I20U,@9FEL93H@+V-V<W)O;W0O8F]O<W0O
M8F]O<W0O;&EB<R]C;VYV97)S:6]N+VEN9&5X+FAT;6PL=@T*<F5T<FEE=FEN
M9R!R979I<VEO;B Q+C0-"F1I9F8@+74@+7 @+7(Q+C0@:6YD97@N:'1M; T*
M+2TM(&)O;W-T+VQI8G,O8V]N=F5R<VEO;B]I;F1E>"YH=&UL"3(T($IU;B R
M,# U(#$T.C(T.C R("TP,# P"3$N- T**RLK(&)O;W-T+VQI8G,O8V]N=F5R
M<VEO;B]I;F1E>"YH=&UL"3(W($IA;B R,# V(# Q.C0Y.C R("TP,# P#0I
M0" M,C L,3<@*S(P+#(S($! (%-T86YD87)D)W,@8G5I;'0M:6X@8V%S=',N
M/"]P/@T*($-O;G9E<G-I;VX@3&EB<F%R>2!I<PT*('-U<'!L:65D(&)Y('-E
M=F5R86P@:&5A9&5R<SH\+W ^#0H@/'5L/@T*+2 @/&QI/E1H92 \82!H<F5F
M/2)C87-T+FAT;2(^8F]O<W0O8V%S=#PO83X@:&5A9&5R('!R;W9I9&5S(#QB
M/G!O;'EM;W)P:&EC7V-A<W0F;'0[)F=T.SPO8CX-"BT@(" @86YD(#QB/G!O
M;'EM;W)P:&EC7V1O=VYC87-T)FQT.R9G=#L\+V(^('1O('!E<F9O<FT@<V%F
M92!C87-T:6YG(&)E='=E96X-"BL@( T**SQL:3Y4:&4@/&$@:')E9CTB8V%S
M="YH=&TB/F)O;W-T+V-A<W0\+V$^(&AE861E<B!P<F]V:61E<R \8CYP;VQY
M;6]R<&AI8U]C87-T)FQT.R9G=#L\+V(^#0HK("!A;F0@/&(^<&]L>6UO<G!H
M:6-?9&]W;F-A<W0F;'0[)F=T.SPO8CX@=&\@<&5R9F]R;2!S869E(&-A<W1I
M;F<@8F5T=V5E;@T*(" @<&]L>6UO<G!H:6,@='EP97,N/&)R/@T*+2 @/"]L
M:3X-"BT@(#QL:3Y4:&4@/&$@:')E9CTB;&5X:6-A;%]C87-T+FAT;2(^8F]O
M<W0O;&5X:6-A;%]C87-T/"]A/B!H96%D97(@<')O=FED97,@/&(^;&5X:6-A
M;%]C87-T)FQT.R9G=#L\+V(^#0HK(" -"BL\+VQI/@T**R @#0HK/&QI/E1H
M92 \82!H<F5F/2)L97AI8V%L7V-A<W0N:'1M(CYB;V]S="]L97AI8V%L7V-A
M<W0\+V$^(&AE861E<B!P<F]V:61E<R \8CYL97AI8V%L7V-A<W0F;'0[)F=T
M.SPO8CX-"B @(" @9V5N97)A;"!L:71E<F%L('1E>'0@8V]N=F5R<VEO;G,L
M('-U8V@@87,@86X@/&-O9&4^:6YT/"]C;V1E/B!R97!R97-E;G1E9"!A<PT*
M(" @("!A(#QC;V1E/G-T<FEN9SPO8V]D93XL(&]R('9I8V4M=F5R<V$N/"]L
M:3X-"BL-"BL\;&D^5&AE(#QA(&AR968](FEM<&QI8VET7V-A<W0O:'1M;"]I
M;F1E>"YH=&UL(CYB;V]S="]I;7!L:6-I=%]C87-T/"]A/B!H96%D97(@<')O
M=FED97,@/&(^:6UP;&EC:71?8V%S="9L=#LF9W0[/"]B/B!W:&EC:"!I<R!U
M<V5D('=H96X@=&AE('-O=7)C92!T>7!E(&ES(&EM<&QI8VET;'D@8V]N=F5R
M=&EB;&4@=&\@=&AE('1A<F=E="!T>7!E+"!T;R!F;W)C92!T:&4@:6UP;&EC
M:70@8V]N=F5R<VEO;BX@270G<R!L97-S(&QI8F5R86P@=&AA;B!S=&%T:6-?
M8V%S="P@=VAI8V@@=VEL;"!C;VYV97)T(&EN('1H92!O<'!O<VET92!D:7)E
M8W1I;VXN+CQB<CX-"BL@#0H@/"]U;#X-"B \:'(^#0H@/' ^4F5V:7-E9" \
M(2TM=V5B8F]T(&)O=#TB5&EM97-T86UP(B!3+51Y<&4](D5$251%1"(-"BU3
M+49O<FUA=#TB)60@)4(L("59(B!S=&%R='-P86X@+2T^2G5N92 R,RP@,C P
M-3PA+2UW96)B;W0@8F]T/2)4:6UE<W1A;7 B(&5N9'-P86X@:2UC:&5C:W-U
M;3TB,S S-#@B("TM/@T**U,M1F]R;6%T/2(E9" E0BP@)5DB('-T87)T<W!A
M;B M+3Y*86X@,C4L(#(P,#8\(2TM=V5B8F]T(&)O=#TB5&EM97-T86UP(B!E
M;F1S<&%N(&DM8VAE8VMS=6T](C,P,S0X(B M+3X-"B \+W ^#0H@#0H@/"]B
&;V1Y/@T*
`
end

begin 666 implicit_cast.qbk
M6W!A<G0@:6UP;&EC:71?8V%S= T*(" @(%MV97)S:6]N(#%=#0H@(" @6V-O
M<'ER:6=H=" R,# U+3(P,#8@70T*(" @(%MI9"!I;7!L:6-I=%]C87-T70T*
M(" @(%MC871E9V]R>2!I;7!L:6-I=%]C87-T70T*(" @(%MA=71H;W)S("!;
M06)R86AA;7,L1&%V:61=70T*(" @("!;;&EC96YS90T*(" @(" @("!$:7-T
M<FEB=71E9"!U;F1E<B!T:&4@0F]O<W0@4V]F='=A<F4@3&EC96YS92P@5F5R
M<VEO;B Q+C N#0H@(" @(" @("A3964@86-C;VUP86YY:6YG(&9I;&4@3$E#
M14Y315\Q7S N='AT(&]R(&-O<'D@870-"B @(" @(" @/'5L:6YK('5R;#TB
M:'1T<#HO+W=W=RYB;V]S="YO<F<O3$E#14Y315\Q7S N='AT(CX-"B @(" @
M(" @(" @(&AT=' Z+R]W=W<N8F]O<W0N;W)G+TQ)0T5.4T5?,5\P+G1X= T*
M(" @(" @(" \+W5L:6YK/BD-"B @("!=#0I=#0H-"EMS96-T:6]N.FEN9&5X
M($)O;W-T+DEM<&QI8VET7V-A<W1=#0H-"BH@6VQI;FL@<WEN;W!S:7,@4WEN
M;W!S:7-=#0HJ(%ML:6YK('-U;6UA<GD@4W5M;6%R>5T-"BH@6VQI;FL@97AA
M;7!L92!%>&%M<&QE70T*#0I;(W-Y;F]P<VES70T*#0I;:#,@4WEN;W!S:7-=
M#0H)#0IH96%D97(@6T N+B\N+B\N+B\N+B]B;V]S="]I;7!L:6-I=%]C87-T
M+FAP<" B8F]O<W0O:6UP;&EC:71?8V%S="YH<' B70T*#0H)=&5M<&QA=&4@
M/'1Y<&5N86UE(%0^(%0@:6UP;&EC:71?8V%S="@@5#$@>"D[#0H-"B @(%)E
M<75I<F5S.B!4,2!I<R!I;7!L:6-I=&QY(&-O;G9E<G1I8FQE('1O(%0N#0H@
M("!2971U<FYS.B!!;B!O8FIE8W0@;V8@='EP92!4('=H;W-E('9A;'5E(&ES
M('1H92!R97-U;'0@;V8@:6UP;&EC:70@8V]N=F5R<VEO;B!O9B!X(&9R;VT@
M='EP92!4,2!T;R!4+@T*#0I;(W-U;6UA<GE=#0H-"EMH,R!I;7!L:6-I=%]C
M87-T70T*:6UP;&EC:71?8V%S="!I<R!U<V5D('=H96X@=&AE('-O=7)C92!T
M>7!E(&ES(&EM<&QI8VET;'D-"F-O;G9E<G1I8FQE('1O('1H92!T87)G970@
M='EP92P@=&\@9F]R8V4@=&AE(&EM<&QI8VET(&-O;G9E<G-I;VXN#0I)="=S
M(&QE<W,@;&EB97)A;"!T:&%N('-T871I8U]C87-T+"!W:&EC:"!W:6QL(&-O
M;G9E<G0@:6X@=&AE(&]P<&]S:71E(&1I<F5C=&EO;BX@#0H-"ELC97AA;7!L
M95T-"@T*6V@S($5X86UP;&5=#0I!<R!A;B!E>&%M<&QE(&%P<&QI8V%T:6]N
M(&QE=',@=&%K92!I;FET:6%L:7-A=&EO;B!O9B!A('5S97(@9&5F:6YE9"!T
M>7!E("A51%0I('=H97)E($ET<R!U<W5A;"!T;R!R97%U:7)E(&5X<&QI8VET
M(&EN:71I86QI<V%T:6]N("AO<B!V86QU92!I;FET:6%L:7-A=&EO;BD@8GD@
M;6%K:6YG('1H92!C;VYS=')U8W1O<B!E>'!L:6-I="!T;R!P<F5V96YT(&EM
M<&QI8VET(&EN:71I86QI<V%T:6]N+B!);B!U9'1!('1H92!E>'!L:6-I="!C
M;VYS=')U8W1O<B!M96%N<R!T:&%T('5D=$$@8V%N(&)E(&EN:71I86QI<V5D
M('=I=&@@='EP97,@5"P@8G5T(&]N;'D@=7-I;F<@=&AE(&5X<&QI8VET(&]R
M('9A;'5E(&EN:71I86QI<V%T:6]N('-Y;G1A>"X-"B @#0H@(" @(VEN8VQU
M9&4@/&)O;W-T+VEM<&QI8VET7V-A<W0N:'!P/@T*#0H@(" @=&5M<&QA=&4@
M/'1Y<&5N86UE(%0^#0H@(" @<W1R=6-T('5D=$%[#0H@(" @(" @('1Y<&5D
M968@5"!V86QU95]T>7!E.PT*(" @(" @("!4('9A;#L-"B @(" @(" @=&5M
M<&QA=&4@/'1Y<&5N86UE(%0Q/@T*(" @(" @("!E>'!L:6-I="!U9'1!*"!4
M,2!C;VYS=" F('0I(#H@=F%L*'0I>WT-"B @("!].PT*#0I4:&4@<')O8FQE
M;2!I<R!T:&%T('5D=$$@8V%N(&)E('9A;'5E(&EN:71I86QI<V5D(&)Y(&%N
M('5N97AP96-T961L>2!W:61E(')A;F=E(&]F('1Y<&5S(&%S('-H;W=N(&EN
M('1H92!F:7)S="!E>&%M<&QE(&)E;&]W+B!4:&4@:6YI=&EA;&ES871I;VX@
M;V8@82!U9'1!/&1O=6)L93X@;V)J96-T(&ES('-A9F4@8F5C875S92!I="!C
M86X@;VYL>2!B92!V86QU92!I;FET:6%L:7-E9"!B>2!I;F)U:6QT('1Y<&5S
M+B!4:&4@;F5S=&5D('5D=$$\=61T03QD;W5B;&4^(#X@86QL;W=S(&EN:71I
M86QI<V%T:6]N(&)Y(&ET<R!V86QU95]T>7!E+"!A('5D=$$\9&]U8FQE/BP@
M87,@<VAO=VX@:6X@=&AE(&EN:71I86QI<V%T:6]N(&]F('9!,2P@8G5T(&ET
M(&%L<V\@86QL;W=S(&EN:71I86QI<V%T:6]N(&)Y(&%N(&EN="!A<R!S:&]W
M;B!I;B!V03(N(%1H:7,@;6%Y(&)E+"!B=70@:7,@<')O8F%B;'D@;F]T+"!W
M:&%T('1H92!A=71H;W(@;V8@=61T02!I;G1E;F1E9"X-"@T*(" @('5D=$$\
M9&]U8FQE/B!V03 H,2D[#0H@(" @=61T03QU9'1!/&1O=6)L93X@/G9!,2AV
M03 I.PT*(" @('5D=$$\=61T03QD;W5B;&4^(#YV03(H,2D[#0H-"E1H:7,@
M<')O8FQE;2!C86X@8F4@<')E=F5N=&5D(&)Y(&%D9&EN9R!@8F]O<W0Z.FEM
M<&QI8VET7V-A<W1@(&EN('1H92!I;FET:6%L:7-E<B!F;W(@=F%L(&%S('-H
M;W=N(&EN('5D=$(N#0H-"G1E;7!L871E(#QT>7!E;F%M92!4/@T*<W1R=6-T
M('5D=$)[#0H@(" @='EP961E9B!4('9A;'5E7W1Y<&4[#0H@(" @5"!V86P[
M#0H@(" @=&5M<&QA=&4@/'1Y<&5N86UE(%0Q/@T*(" @(&5X<&QI8VET('5D
M=$(H(%0Q(&-O;G-T("8@="D@.B!V86PH8F]O<W0Z.FEM<&QI8VET7V-A<W0\
M5#XH="DI>WT-"GT[#0H-"D%T=&5M<'1I;F<@=&\@:6YI=&EA;&ES92!A('5D
M=$(@8GD@82!T>7!E(&YO="!I;7!L:6-I=&QY(&-O;G9E<G1I8FQE('1O(&ET
M<R!V86QU95]T>7!E('=I;&P@8F4@<')E=F5N=&5D+B!4:&4@871T96UP=&5D
M(&EN:71I86QI<V%T:6]N(&]F('9",B!B>2!A;B!I;G0@=VEL;"!N;W<@8V%U
M<V4@82!C;VUP:6QE('1I;64@97)R;W(N#0H-"B @("!U9'1"/&1O=6)L93X@
M=D(P*#$I.PT*(" @('5D=$(\=61T0CQD;W5B;&4^(#YV0C$H=D(P*3L-"B @
M("!U9'1"/'5D=$(\9&]U8FQE/B ^=D(R*#$I.R O+R!%<G)O<B$-"@T*#0I;
*96YD<V5C=%T-"@``
`
end

begin 666 Jamfile.v2
M(V)A<VEC86QL>2!C;W!I960@9G)O;2!4>7!E;V8@2F%M9FEL92XN#0H-"B,@
M0V]P>7)I9VAT(%!E9&5R($AO;'0@,C P-2X@57-E+"!M;V1I9FEC871I;VXL
M(&%N9"!D:7-T<FEB=71I;VX@87)E#0HC('-U8FIE8W0@=&\@=&AE($)O;W-T
M(%-O9G1W87)E($QI8V5N<V4L(%9E<G-I;VX@,2XP+B H4V5E(&%C8V]M<&%N
M>6EN9PT*(R!F:6QE($Q)0T5.4T5?,5\P+G1X="!O<B!C;W!Y(&%T(&AT=' Z
M+R]W=W<N8F]O<W0N;W)G+TQ)0T5.4T5?,5\P+G1X="D-"@T*=7-I;F<@<75I
M8VMB;V]K(#L-"@T*>&UL(&EM<&QI8VET7V-A<W0@.B!I;7!L:6-I=%]C87-T
M+G%B:R [#0IB;V]S=&)O;VL@<W1A;F1A;&]N90T*(" @(#H-"B @(" @(" @
M:6UP;&EC:71?8V%S= T*(" @(#H-"B @(" @(" @/'AS;#IP87)A;3YN878N
M;&%Y;W5T/6YO;F4-"B @(" @(" @/'AS;#IP87)A;3YN879I9RYG<F%P:&EC
M<STP#0H@(" @.PT*#0II;G-T86QL(&AT;6P@.B N+B\N+B\N+B]D;V,O:'1M
M;"]B;V]S=&)O;VLN8W-S(#L-"FEN<W1A;&P@+BXO(#H@+BXO+BXO+BXO8F]O
,<W0N<&YG(#L-"@T*
`
end


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [conversion] implicit_cast undocumented

Andy Little
Hi David,

    Was the documentaion I provided for implicit_cast helpful?

BTW would there be any point in an is_implicitly_convertible<A,B>  type_trait?


regards
Andy Little





_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [conversion] implicit_cast undocumented

John Maddock
> BTW would there be any point in an is_implicitly_convertible<A,B>
> type_trait?

That's what is_convertible does now: tests for implicit convertibility.
There's no way you can test for other kinds of valid (but explicit)
conversions I believe.

John.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [conversion] implicit_cast undocumented

Andy Little

"John Maddock" <[hidden email]> wrote in message
news:00b601c6258d$bb5f76d0$a9051c52@fuji...
>> BTW would there be any point in an is_implicitly_convertible<A,B>
>> type_trait?
>
> That's what is_convertible does now: tests for implicit convertibility.
> There's no way you can test for other kinds of valid (but explicit)
> conversions I believe.

Oops sorry for being too lazy to try that out before posting.  Perhaps it would
be useful to put that in the documentation for implicit_cast e.g

implicit_cast<t>(S)  will succeed wherever is_convertible<S,T>::value ==true and
will cause a compile time error wherever implicit_cast<t>(S)  will succeed
wherever is_convertible<S,T>::value ==false. Maybe could even do the reverse too
if implicit_cast was documented.

BTW Its a real pain that the parameter order for is_convertible isnt the other
way round IMO. Its confusing and error prone because casts go the other way. Is
there a reason for it?

Getting back to the original topic (or trying to anyway ).. So is the
documentation I provided for implicit_cast useful?

regards
Andy Little







_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [conversion] implicit_cast undocumented

David Abrahams
"Andy Little" <[hidden email]> writes:

> "John Maddock" <[hidden email]> wrote in message
> news:00b601c6258d$bb5f76d0$a9051c52@fuji...
>>> BTW would there be any point in an is_implicitly_convertible<A,B>
>>> type_trait?
>>
>> That's what is_convertible does now: tests for implicit convertibility.
>> There's no way you can test for other kinds of valid (but explicit)
>> conversions I believe.
>
> Oops sorry for being too lazy to try that out before posting.  Perhaps it would
> be useful to put that in the documentation for implicit_cast e.g
>
> implicit_cast<t>(S)  will succeed wherever
> is_convertible<S,T>::value ==true

I think that would be a lie for some reasonable definitions of
"succeed":


        struct foo
        {
           operator int() { throw "fooled ya"; }
        };

> and
> will cause a compile time error wherever implicit_cast<t>(S)  will succeed
                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
eh?
> wherever is_convertible<S,T>::value ==false. Maybe could even do the reverse too
> if implicit_cast was documented.
>
> BTW Its a real pain that the parameter order for is_convertible isnt the other
> way round IMO. Its confusing and error prone because casts go the other way. Is
> there a reason for it?

"from, to" is the usual convention except for old-style things like
strcpy.

> Getting back to the original topic (or trying to anyway ).. So is the
> documentation I provided for implicit_cast useful?

Haven't had time to dig into them, but they seemed pretty good on the
surface.  I'll try to find time to check them in.

Thanks,

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [conversion] implicit_cast undocumented

Andy Little

"David Abrahams" wrote
Andy Little wrote
>> implicit_cast<t>(S)  will succeed wherever
>> is_convertible<S,T>::value ==true
>
> I think that would be a lie for some reasonable definitions of
> "succeed":

OK how about

implicit_cast<t>(S) will usually 1 succeed if
boost::is_convertible<S,T>::value
is true, but will always cause a compile_time error if
boost::is_convertible<S,T>::value is false.

------------
[note1]

The following is one situation where implicit_cast wont succeed

        struct foo
        {
           operator int() { throw "fooled ya"; }
        };

FWIW enclosed updated version of <libs/implicit_cast/implicit_cast.qbk>
together
with generated html

regards
Andy Little



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

implicit_cast.qbk (3K) Download Attachment
index.html (4K) Download Attachment
12