Re: What is a secret of mpl::set?

David Abrahams wrote:
> The tiny prototype that started all this is at: 
> http://lists.boost.org/MailArchives/boost/msg53032.php

Thanks, Dave. This gives me an idea.

--

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

Re: Re: Front page... with new logo.

>On Tue, 30 Nov 2004 12:28:44 -0500 (EST), Rob Stewart <stewart <at> sig.com> wrote:
> How about something based upon this:  C++<boost>
> 
> (I know it isn't valid C++ syntax, but doesn't it suggest
> parameterizing C++ with Boost, thus configuring C++ and, by
> implication, making it better?)
> 
I quite like that idea.  Perhaps emphasise the os in boost for the
dual connotations of open source and operating system.  bit of colour
for a rocket.  can type it as text.

what about a font style similar to some one else's suggestion with a
bit of shadow...

could do with a better font / shading.

$AUD 0.005,

matt hurd.
matthurd <at> acm.org

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

Re: Re: Front page... with new logo.

On Wed, 1 Dec 2004 12:08:44 +1100, Matt Hurd <matt.hurd <at> gmail.com> wrote:

> I quite like that idea.  Perhaps emphasise the os in boost for the
> dual connotations of open source and operating system.  bit of colour
> for a rocket.  can type it as text.
> 
> what about a font style similar to some one else's suggestion with a
> bit of shadow...

Too many colors and the oddball foNT siZinG looks horrible.  Yes Boost
is open source, but highlighting "OS" further confuses an already
confusing set of glyphs.

--

-- 
Caleb Epstein
caleb dot epstein at gmail dot com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Logos - Last Minute Change of Heart

Jonathan Wakely wrote:
> [...]
> Right now, before your very eyes, watch the logo bicycle shed become
> a voting system bicycle shed - tada!   

I agree with one aspect...that talking about voting is premature.  At
this point, I don't think there are enough submissions to have a good
vote.  Frankly, I think it would be more constructive to solicit
volunteers to run the suggested logo contest.  Only after that gets
running and we get some more logos to look at does it make sense to me
to talk about voting.  For instance, should the contest have a prize?
If so, what?  If it's only a matter of pride in being listed on the
Boost site, is that enough motivation to attract a wide pool of
contestants?

Dave

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

Re: [signals] Performance

On Sun, 17 Oct 2004 19:36:39 -0500
"Aaron W. LaFramboise" <aaronrabiddog51 <at> aaronwl.com> wrote:

> On the other hand, as Alexandrescu in _Modern C++ Design_ quotes Len
> Lattanzi, "Belated pessimization is the leaf of no good." 
> Alexandrescu goes on to write, "A pessimization of one order of
> magnitude in the runtime of a core object like a functor, a smart
> pointer, or a string can easily make the difference between success
> and failure for a whole project" (Ch. 4, p. 77).  Library writers
> often do not have the same liberty as application writers to go back
> later, after profiling, and fix their slow code.

Right.  My application is entirely event drive, with boost:signal()
dispatching every event.  The application will be processing thousands
of messages per second, each one causing at least one signal()
invocation.

> Preliminary analysis suggests that the performance efficiency of the
> demultiplexor when using this dispatcher is "bad."  While I can not
> yet offer meaningful numbers, it seems that there is something quite
> slow happening under the covers in the Signals library.  I have not
> examined the implementation of the Signals library at all, however. 
> The extent of this problem, and whether it is easily fixable, remains
> to be seen.

I have not done much examination either, but to satisfy my curiosity, I
hacked together a "lite" implementation of the signals interface that
provides *minimum* functionality.  Same interface as boost::signal<>,
w.r.t. connect(), disconnect() and operator() (i.e, dispatching a
signal).  Also, allows connect/disconnect/replace inside a slot handler.

Re: [signals] Performance

One more thing.  The test linked against the signals shared library. 
Linking static speeds things up measurably, but not much, and does not
change the order of magnitude in difference.

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

Re: [signals] Performance

Jody Hagins wrote:

> I have not done much examination either, but to satisfy my curiosity, I
> hacked together a "lite" implementation of the signals interface that
> provides *minimum* functionality.  Same interface as boost::signal<>,
> w.r.t. connect(), disconnect() and operator() (i.e, dispatching a
> signal).  Also, allows connect/disconnect/replace inside a slot handler.
>  It does not provide return value combining and the fancier features. 

This is very useful information!

The primary observation I make from this is how much slower by ratio
Boost.Signals is.  I'm going to look at your test 'lite' implementation
later.  Is there some additional feature Boost.Signals is offering that
causes it to do all of this extra work?

> Note that there seems to be some heavy overhead just in calling
> signal().  The output files show several different size runs, on two
> different architectures/compiler versions.

It's also useful to know how much of a win it is to group as many calls
as possible into a single signal rather than separating them into
separate signals.

Aaron W. LaFramboise

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

Re: typeof integrated

I read the following from the documents:

===================================
The BOOST_TYPEOF_REGISTER_TEMPLATE_X macro accepts
 a template name and a preprocessor sequence describing template
parameters, where each parameter should be described as one of the
following:
§         class
§         typename
§         [unsigned] char
§         [unsigned] short
§         [unsigned] int
§         [unsigned] long
§         unsigned
§         bool

For example:

BOOST_TYPEOF_REGISTER_TEMPLATE_X(foo, (class)(unsigned int)(bool));
===================================

I wonder if other non-type template parameter is supported. For example:

template <void (*)()>
struct template_with_func_ptr_param {};

BOOST_TYPEOF_REGISTER_TEMPLATE_X(
    template_with_func_ptr_param,
    (void (*)())
); // is this legal or possible?

Re: Front page redesign...

Rob Stewart wrote:
> From: "David B. Held" <dheld <at> codelogicconsulting.com>
> 
>>Rob Stewart wrote:
>>
>>>From: Rene Rivera <grafik.list <at> redshift-software.com>
>>>[...]
>>>-- As viewed with my browsers, which work quite nicely at other
>>>   web sites, there is way too much white, and not enough
>>>   black/blue from the text.  IOW, the contrast is really low
>>>   because the lines of the letters are so thin.  This is more
>>>   pronounced with the blue of the links than with the black, but
>>>   both are a problem.
>>
>>I think dense text is much harder to read.  When space is at a
>>premium, then I think dense text is acceptable.  But given the choice
>>between a crowded page and a more open one, I prefer the latter.
>>Dense text tends to make it more difficult to find things, I think.
> 
> 
> At present, there's no danger of that problem.  Note, I'm not
> talking about the whitespace between paragraphs or sections of
> the page, but about how little black or blue there is where there
> is text.  It is difficult for me to read the text because the
> letters are washed out by the white background.

I think we'd need to see a screen capture of what you see. I think you
are the only one so far to complain about the text not being dense
enough. Everyone else has complained about the opposite. Hence why I
went through the task of figuring out how to use the IE "smaller" font

Re: Re: Front page redesign...

Rob Stewart wrote:
> -- The chevron icons do nothing for me.  They aren't indicative
>    of the section they call out and there are only three on the
>    page.  If they differed for each section, they might provide
>    value, or if they were more visually useful, they might be
>    better.  As suggestions for the latter, you could use drop
>    caps in the headings instead of icons, per se, or you could
>    use a partial box:
> 
>    | Welcome to Boost.org!
>    +-----------
> 
>    The partial box would be sized to be just a portion of the
>    width of the headings (and the same width for all of them).

They are indicative of a section, nothing else. They call attention to a 
section without overloading the text itself, as the text is already 
bolder. It's good that there are only three, or two, as otherwise they 
would loose their indication power, they stand out more the fewer there 
are. As pointed out in the early designs making such indicators more 
visually meaningful was described as distractions from the text. Doing 
the design you suggests would clash with the rest of the design. The one 
alternative would be to use the same design element as that of the menu 
box and the search box on the header like:

   Welcome to Boost.org!
  ----------------------
   |
   |   The Boost web site...
       emphasis is on libraries...