Christian Ridderström <[EMAIL PROTECTED]> writes:
>> No I don't agree.
>
| You don't find the first form easier to read?
I think I agree after all :-) I just had to disagree at first go.
| You're welcome... btw, you have referred to 'tr1' in some of the mails,
| what is that?
The upcomming add
Christian Ridderström wrote:
> You're welcome... btw, you have referred to 'tr1' in some of the
> mails, what is that?
The extensions to the C++ standard library are collectively know as
Technical Report #1 and have beed tentatively grouped together in
sub-namespace std::tr1. See
http://anubis.d
On Mon, 5 Jan 2004, Lars Gullik Bjønnes wrote:
> If you as a not so experienced C++ STL programmer can grasp the use of
> bind this quickly I am not worried about obfuscation.
I was experienced in C++ a decade ago but haven't really used it since...
In those days there was no bind, and templates
Lars Gullik Bjønnes wrote:
> I thought not... let me check... I can not see it here:
>
> http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1540.pdf
My misunderstanding then. Thanks.
(I do keep reading of Joel de Guzmann's on-going Fusion of bind,
lambda and mpl and that lambda and bind canno
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>> So this is what my new version of BranchList.C looks like:
>
| I have no complaints about this at all.
>
| Do I understand things correctly if I say that you now think that
| nested binds are not an improvement?
Let's say:
On Mon, Jan 05, 2004 at 11:34:14AM +0100, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> >> that is of course also my goal. and a lot of intent is hidden in bad
> >> nameing. (match() anyone..., ok we are matching... but _what_. Just
> >> naming the functor EqualBranchN
On Mon, Jan 05, 2004 at 10:16:39AM +0100, Lars Gullik Bjønnes wrote:
> Christian Ridderström <[EMAIL PROTECTED]> writes:
>
> | On Sun, 4 Jan 2004, Lars Gullik Bjønnes wrote:
> >
> >> >> Where is the obfuscation?
> >
> | I found
> >
> | list.remove_if(bind2nd(match(), s));
> >
> | easier to un
Lars Gullik Bjønnes wrote:
> | My question is whether we can avoid these arbitrarily-named
> | functors and have code which is understandable at-a-glance. If the
> | code above could be replaced with
> | return (from == lambda::_1.from() && to ==
> | lambda::_2.to());
> | then I'd b
On Sat, Jan 03, 2004 at 03:24:49PM +0100, Lars Gullik Bjønnes wrote:
>
> I know that I am the one who began introducing pimpls to lyx. After
> that I have become quite wary of them... and feel more and more that
> you should have a good reason to use them.
>
> This boils down to: (right now) Wha
Lars Gullik Bjønnes wrote:
> So this is what my new version of BranchList.C looks like:
I have no complaints about this at all.
Do I understand things correctly if I say that you now think that
nested binds are not an improvement?
An aside: you said in an earlier mail something about only intro
Angus Leeming <[EMAIL PROTECTED]> writes:
>> that is of course also my goal. and a lot of intent is hidden in bad
>> nameing. (match() anyone..., ok we are matching... but _what_. Just
>> naming the functor EqualBranchNames() would make things a lot
>> nicer.)
>
| Agree whole-hearedly.
So this is
Angus Leeming <[EMAIL PROTECTED]> writes:
| Yes, it's a good book.
yes it is.
| I note a couple of functors in your patch where the operator() is
| const but the variables have become mutable. That seems to me to be
| a total cheat ;-)
Yes. I am not happy about it. (except for the RegEx one).
Lars Gullik Bjønnes wrote:
> Also the reason why I did all this was a direct result of reading
> "Effective STL" by Scott Meyers.
>
> Main recommandations about functors:
>
> - operator() should always be const
> (functors might be copied around by standard
>
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>
>> [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
>>
>> | that is of course also my goal. and a lot of intent is hidden in
>> | bad nameing. (match() anyone..., ok we are matching... but _what_.
>> | Just naming the functor
Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | Finally, I agree that Lars would carry all before him if he used
> | code like this.
>
> I am not quite sure what this sentence means, can you spell it out
> for me?
Nobody could possibly complain if you introduced cod
Lars Gullik Bjønnes wrote:
> [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
>
> | that is of course also my goal. and a lot of intent is hidden in
> | bad nameing. (match() anyone..., ok we are matching... but _what_.
> | Just naming the functor EqualBranchNames() would make things a lot
> | nic
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Angus Leeming <[EMAIL PROTECTED]> writes:
>
| | Finally, I agree that Lars would carry all before him if he used
| | code like this.
>
| I am not quite sure what this sentence means, can you spell it out for
| me?
|
| | The intent is transparent
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| that is of course also my goal. and a lot of intent is hidden in bad
| nameing. (match() anyone..., ok we are matching... but _what_. Just
| naming the functor EqualBranchNames() would make things a lot nicer.)
Did you see there there were two fun
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| | Just guessing from the name 'lambda'... isn't it like the lambda
| | operator in lisp etc?
>
| A little bit.
>
| I am not sure of the lambda syntax, but it might look like:
>
| _1->getBranch() == name
Ah... I didn't see that you had created a
Angus Leeming <[EMAIL PROTECTED]> writes:
| Finally, I agree that Lars would carry all before him if he used
| code like this.
I am not quite sure what this sentence means, can you spell it out for
me?
| The intent is transparent and it is the intent that I'm
| interested in when reading throu
Christian Ridderström <[EMAIL PROTECTED]> writes:
| On Mon, 5 Jan 2004, Lars Gullik Bjønnes wrote:
>
>> If you want obfuscation have a look at this.
>> (no, I won't actually admit that this is obfuscated.)
>> (I find especially the logical_and usage a bit funny :-) )
>
| Ok... I read about half of
Christian Ridderström <[EMAIL PROTECTED]> writes:
| On Sun, 4 Jan 2004, Lars Gullik Bjønnes wrote:
>
>> >> Where is the obfuscation?
>
| I found
>
| list.remove_if(bind2nd(match(), s));
>
| easier to understand on a high level compared to
>
| list.remove_if(bind(equal_to(),
|
Christian Ridderström wrote:
> On Mon, 5 Jan 2004, Lars Gullik Bjønnes wrote:
>
>> If you want obfuscation have a look at this.
>> (no, I won't actually admit that this is obfuscated.)
>> (I find especially the logical_and usage a bit funny :-) )
>
> Ok... I read about half of it before I got ti
On Mon, 5 Jan 2004, Lars Gullik Bjønnes wrote:
> If you want obfuscation have a look at this.
> (no, I won't actually admit that this is obfuscated.)
> (I find especially the logical_and usage a bit funny :-) )
Ok... I read about half of it before I got tired... My conclusion is that
Lars is ess
On Sun, 4 Jan 2004, Lars Gullik Bjønnes wrote:
> >> Where is the obfuscation?
I found
list.remove_if(bind2nd(match(), s));
easier to understand on a high level compared to
list.remove_if(bind(equal_to(),
bind(&Branch::getBranch, _1),
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
bool BranchList::remove(string const & s)
{
List::size_type const size = list.size();
-list.remove_if(bind2nd(match(), s));
+list.remove_if(bind(equal_to(),
+
Lars Gullik Bjønnes wrote:
>>> bool BranchList::remove(string const & s)
>>> {
>>> List::size_type const size = list.size();
>>> -list.remove_if(bind2nd(match(), s));
>>> +list.remove_if(bind(equal_to(),
>>> +bind(&Branch::getBranch, _1),
>>> +
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>
>> bool BranchList::remove(string const & s)
>> {
>> List::size_type const size = list.size();
>> -list.remove_if(bind2nd(match(), s));
>> +list.remove_if(bind(equal_to(),
>> +
Lars Gullik Bjønnes wrote:
> bool BranchList::remove(string const & s)
> {
> List::size_type const size = list.size();
> -list.remove_if(bind2nd(match(), s));
> +list.remove_if(bind(equal_to(),
> +bind(&Branch::getBranch, _1),
> +
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| I know that I am the one who began introducing pimpls to lyx. After
| that I have become quite wary of them... and feel more and more that
| you should have a good reason to use them.
>
| This boils down to: (right now) What is the use of the pimp
30 matches
Mail list logo
