headers
Christopher Kohlhoff | 1 Sep 2005 01:15
Favicon

Re: asio networking proposal

Hi Rob,

--- Rob Stewart <stewart <at> sig.com> wrote:
> I'd say that unless you know that using virtual functions causes
> problems, you shouldn't presume that they do.  If users say the
> library is too big and this technique significantly affects the
> size, then it may be worth considering at that time.

As I said in another reply, I did find a need to do this change to
eliminate code bloat with several compilers. As an example, Borland C++
5.6.4 seems to add approximately 100 bytes to the executable for each
asynchronous call if a virtual function is used in win_iocp_operation.
As the change didn't impact the public interface of asio, it seemed
like a win.

Cheers,
Chris
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 2 comments |
headers
Aleksey Gurtovoy | 1 Sep 2005 01:51
Favicon

Re: New implementation of remove_xxx for vintage compilers

Eric Niebler writes:
> Aleksey Gurtovoy wrote:
>> I'd like to see a comparison of compilation times between the old and
>> the new implementation and the latter being stress tested on
>> Boost.Python tests before it officially replaces the current
>> code.
>> 
>
> I'm not sure what you mean. The "current code" for remove_pointer, et 
> al. for VC6 and VC7 is broken -- it does nothing. 

It does, see
http://www.boost.org/doc/html/boost_typetraits/category.html#transform.broken_compiler_workarounds_.

> You want to see a 
> performance comparison between code that doesn't work and code that 
> does. Why?

Because we have code that depends on Type Traits working reliably on
MSVC 6.5 -- and taking a reasonable amount of time to compile.

--

-- 
Aleksey Gurtovoy
MetaCommunications Engineering
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 23 comments |
headers
Arkadiy Vertleyb | 1 Sep 2005 01:59
Picon
Favicon

Re: Please help understanding regression results

"Martin Wille" <mw8329 <at> yahoo.com.au> wrote

> Arkadiy Vertleyb wrote:
> > What does a blank space (as opposed to "pass"/"fail"/"n/a") mean in the
> > regression table?
>
> It means that either a test was not run or that the testing system was
> unable to retrieve the results.

Hmmm, what would be possible reasons for this?  How do I start figuring out
what's wrong?

For example, typeof gcc tests on the darwin and OSL2 (linux) passed, while
the ones on your machine are left blank...

Regards,
Arkadiy

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 3 comments |
headers
Arkadiy Vertleyb | 1 Sep 2005 02:08
Picon
Favicon

Re: New implementation of remove_xxx for vintage compilers

"Aleksey Gurtovoy" <agurtovoy <at> meta-comm.com> wrote

> Eric Niebler writes:
> > Aleksey Gurtovoy wrote:
> >> I'd like to see a comparison of compilation times between the old and
> >> the new implementation and the latter being stress tested on
> >> Boost.Python tests before it officially replaces the current
> >> code.
> >>
> >
> > I'm not sure what you mean. The "current code" for remove_pointer, et
> > al. for VC6 and VC7 is broken -- it does nothing.
>
> It does, see
>
http://www.boost.org/doc/html/boost_typetraits/category.html#transform.broke
n_compiler_workarounds_.
>
> > You want to see a
> > performance comparison between code that doesn't work and code that
> > does. Why?
>
> Because we have code that depends on Type Traits working reliably on
> MSVC 6.5 -- and taking a reasonable amount of time to compile.

If this is related to only VC6 and VC7.0, then a typeof-using implementation
would compile fast (and not require registration) since for these compilers
the only possible option is to use the Igor' Chesnokov's MSVC-specific trick
(not emulation).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Niebler | 1 Sep 2005 02:19
Picon
Favicon

Re: New implementation of remove_xxx for vintage compilers

Aleksey Gurtovoy wrote:
> Eric Niebler writes:
>>
>>I'm not sure what you mean. The "current code" for remove_pointer, et 
>>al. for VC6 and VC7 is broken -- it does nothing. 
> 
> 
> It does, see
> http://www.boost.org/doc/html/boost_typetraits/category.html#transform.broken_compiler_workarounds_.
> 
> 
>>You want to see a 
>>performance comparison between code that doesn't work and code that 
>>does. Why?
> 
> 
> Because we have code that depends on Type Traits working reliably on
> MSVC 6.5 -- and taking a reasonable amount of time to compile.
> 

Ah. But the fact remains that remove_pointer et al. are indeed broken on 
VC6 and VC7, and the regression tests bear this out.

http://tinyurl.com/8fs7w

IMO, the best path is to preserve the meaning of 
BOOST_BROKEN_COMPILER_TYPE_TRAITS_SPECIALIZATION for compilers without 
PTS. That is, it still defines full specializations of the type traits 
templates. But the typeof implementation should be what the primary 
template uses for compilers without PTS. That way, everything that is
(Continue reading)

Permalink | Reply | 21 comments |
headers
David Abrahams | 1 Sep 2005 02:57
Picon
Picon
Favicon
Gravatar

Re: [1.33.1] Goals, tasks, schedule

Martin Wille <mw8329 <at> yahoo.com.au> writes:

> David Abrahams wrote:
>
>>                                                  We've never done a
>> point release before so it never became an issue.
>
> Yes, let's forget about 1.30.1  ;-)

Done ;-)

--

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
David Abrahams | 1 Sep 2005 03:04
Picon
Picon
Favicon
Gravatar

Re: [boost thread rework] New version uploaded to Boost Vault

Ion Gaztañaga <igaztanaga <at> gmail.com> writes:

> Hi to all,
>
>   I've just finished implementing the lockable objects of Kevlin's 
> proposal based on Boost mutexes and conditions. Since boost mutex 
> operations are private and only available with locks, I haven't found a 
> way to implement Kevlin's interface over boost threads without using 
> some very nasty tricks. If someone has a better idea, let me know.
>
>   The implementation nearly fills all the proposal of the documentation, 
> so I will wait for new elements so that I can continue with this 
> project. This elements are present in the current version:
>
> -> threader and joiner classes
> -> lockable, try_lockable, condition_lockable
> -> locker, try_locker
> -> locking_ptr
>
> There are open issues in the paper like timeout handling and new 
> possible lockers, (for example, for conditional_lockable objects). As 
> soon as I get more information I will continue developing it.

I don't want to be a buzz-kill and I know it's not glamorous, but I'm
really concerned about the health of the existing Boost.Thread
primitives.  IIUC, none of these cool high-level components you're
working on can act as full replacements for the existing stuff.

In particular, for example, the Boost.Thread documentation needs a lot
of work.  The code, apparently, needs a rewrite in order to get it to
(Continue reading)

Permalink | Reply | 56 comments |
headers
David Abrahams | 1 Sep 2005 03:06
Picon
Picon
Favicon
Gravatar

Re: [Boost.Thread]: consider removing catch(...) from thread_proxy

Roland Schwarz <roland.schwarz <at> chello.at> writes:

> Matt Gruenke schrieb:
>
>>You don't see why I consider silently swallowing unhandled exceptions to 
>>be effectively hiding program errors?  I'll try my best to support that 
>>claim, but I think we may have encountered a fundamental difference of 
>>opinions.
>>
>>  
>>
> Of course I do see a problem in "swallowing unhandled exceptions to
> be effectively hiding program errors". I don't think there is an issue of
> opinions.
>
> What I am trying to say is simply:
> Wheter the catch all is present or not will _not_ help to address this 
> problem!

Not from a portable C++ point-of-view, no.
A platform or C++ implementation is free to implement its own
swallowing, so there's no guarantee that there will be less error
masking.

> This is a technical issue only.
>
> What woul help is calling some (possibly user supplied) handler from the
> catch clause. (Or leave it to the debugger to do something reasonably.)
> But perhaps I did not understand correctly your point and we both
> effectively are suggesting the very same?
(Continue reading)

Permalink | Reply | 6 comments |
headers
David Abrahams | 1 Sep 2005 03:16
Picon
Picon
Favicon
Gravatar

Re: New implementation of remove_xxx for vintage compilers

Eric Niebler <eric <at> boost-consulting.com> writes:

> Ah. But the fact remains that remove_pointer et al. are indeed broken on 
> VC6 and VC7, and the regression tests bear this out.
>
> http://tinyurl.com/8fs7w
>
> IMO, the best path is to preserve the meaning of 
> BOOST_BROKEN_COMPILER_TYPE_TRAITS_SPECIALIZATION for compilers without 
> PTS. That is, it still defines full specializations of the type traits 
> templates. But the typeof implementation should be what the primary 
> template uses for compilers without PTS. That way, everything that is 
> working now, keeps working with no change in performance.

I think it would better to do some actual speed testing there.  After
all, using the typeof hack *could* turn out to be much faster and use
fewer resources than doing it the other way.

It's a pretty easy test.

--

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 20 comments |
headers
David Abrahams | 1 Sep 2005 03:12
Picon
Picon
Favicon
Gravatar

Re: Very fast delimited record parsing with boost

"Scott Woods" <scottw <at> qbik.com> writes:

> "David Abrahams" <dave <at> boost-consulting.com> wrote:
>
>
>> 
>> This appeared on comp.lang.c++.moderated a few days ago.
>> 
>
>
> I have dealt with some similar requirements. My solution
> may be useful to this guy, but most likely not. Was there a
> an associated mail address?

I enclosed the entire posting, so the From: address
should have been clearly visible in it.

Yep, 

  "Andy" <garth_rockett-at-yahoo.com>

--

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply | 0 comments |

Gmane