Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Tue, Jan 06, 2004 at 07:14:48PM +0100, Lars Gullik Bjønnes wrote:
>> Andre Poenitz <[EMAIL PROTECTED]> writes:
>>
>> | case 1 seems to be uniformly better. So why not use it?
>>
>> because it is some ~10 lines longer.
>
| I see about 5 which goes down to 4 for the unnecessary 'public' when
| changing the class to a struct. Furthermore does not take into account
| any '#include' and 'using' lines (none for #1, some otherwise).
or if you make it really terse
struct SameName : public std::unary_function<Foo, bool> {
SameName(std::string const & name) : name_(name) {}
bool operator()(Foo const & foo) const { return foo.name() == name_; }
std::string name_;
};
and as lambda:
bind(&Foo::name, _1) == name
| I don't think this is convincing evidence.
What is then?
it is
>
| I agree that having the one-shot definition far away from its usage is
| not nice and lambda might make this nicer.
"might make"?
Are you afraid of multi-line and hate one-liners?
>> And if the functor is only being used once... (the tables are turned
>> if the functor is used in several places)
>>
>> Also it is not unlikely that case 2 and 3 will catch up performance
>> wise when compilers get even better.
>
| You are already using 3.4, i.e. a compiler not used by the crowd with
| the next year or two.
>
| Not convincing again.
The argument is that compilers get better and that they are not that
bad _now_.
| IMO there is a draw between 'old fashioned code' and lambda and the tie
| breaker 'simple standard constructs' prefers 'old fashioned code'.
can you add some commas to make me understand the sentence?
| Btw I think we got a bad start in the new year. We have more serious
| problems then debating on how to make code looking fashionable.
I thought it as a nice start as it made me allocate some time, rather
than none, on lyx code.
--
Lgb
