Re: [boost] [fusion] ftag

From: Andy Little (andy_at_[hidden])
Date: 2006-09-22 21:40:16

"Joel de Guzman" <joel_at_[hidden]> wrote in message 
news:45148B4C.3030804_at_boost-consulting.com...
> Andy Little wrote:
>> "Joel de Guzman" <joel_at_[hidden]> wrote in message
>> news:ef1t83$bhv$1_at_sea.gmane.org...
>>> Andy Little wrote:
>>>> "David Abrahams" <dave_at_[hidden]> wrote in message
>>>> news:87fyenkjh9.fsf_at_pereiro.luannocracy.com...
>>>>> AFAICT the name ftag should be changed to something more descriptive
>>>>> and more certainly unique, e.g. boost_fusion_iterator_tag.  Is there
>>>>> a reason it needs to be so short?
>>>> Why make such a trivial  change to the  interface post review? AFAICS now 
>>>> is
>>>> too
>>>> late, and will cause unnecessary pain to users.. like myself.
>>> Well, actually, it shouldn't be a part of the interface.
>>> Here, I'm used to calling it the f#%$tag :) It's not supposed
>>> to be for public consumption, and I intend to enforce that.
>>> Either way, it's not a good name (especially for minors. ;)
>>> and it must be changed.
>>
>> And BTW its pretty public in the 'make your own iterator" part of the docs.
>
> Yeah. That's unfortunate. I asked Dan to fix it. Anyway, I suggest you
> do the right thing: specialize tag_of.
>
>> So far I have made 5 fusion style iterators. Next is the matrix minor 
>> iterator,
>> which extracts minors from a matrix, as a prelude to extracting cofactors.
>
> Cool!
>
>> Fusion::Views are wonderful things ....
>
> Views are wonderful things. If you remember, I mentioned this idea
> about a const string library using Fusion like views. I'm betting
> such a library will rock in terms of performance.

hmmm.. Fusion is a bit wasted on strings ( I only need them for output, what is 
slow as a dog anyway)  AFAICS. Seems to be "quite" good at inlining generic 
matrix concatenation though ... Actually I can't see how I would speed the 
output of my current efforts, once optimised  by VC8 express, even if I coded 
each instantiation by hand :-)

There do seem to be limits to when the compiler will optimise a view though, It 
may have something to do with copying references(aka joint-view) as raw bytes, 
after which AFAICS the compiler will treat them as pointers. that said that is 
only an impression so far.

regards
Andy Little

regards
Andy Little