Re: [boost] New libraries implementing C++11 features in C++03

Subject: Re: [boost] New libraries implementing C++11 features in C++03
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-11-25 04:24:49

On Fri, Nov 25, 2011 at 7:11 PM, Nathan Ridge <zeratul976_at_[hidden]> wrote:
>
>> From: mikhailberis_at_[hidden]
>>
>> On Fri, Nov 25, 2011 at 6:06 PM, Nathan Ridge <zeratul976_at_[hidden]> wrote:
>> >
>> > And they won't support Boost.Local functions?
>> >
>>
>> If Boost.Local functions are just function objects then sure. My point
>> is that I don't see the need for Boost.Local for me to be able to
>> leverage these libraries in C++03 or C++11.
>
> Who ever said the point of Boost.Local was to be able to leverage these
> libraries?

So what was your point in asking the question in the first place?

> The point of Boost.Local is to be able define functions locally,
> close to where they are used, with C++ statement syntax.
>

You mean using C++03 statement syntax of course. And "close to where
they are used" is not the same as "where they are required".

Like I said already before, the difference between 0 lines (Phoenix
functions defined in-lined) and at least 1 line away (Boost.Local) is
*infinite* compared to 1 line away for local functions and more lines
away with non-local functions.

>> >
>> > The arguments to the transformed and filtered adaptors are all C++11
>> > lambdas defined immediately above these lines. How do you think this
>> > code would look if I instead dropped the lambda definitions inline?
>> > Or would you have wasted extra lines and time defining these little
>> > one-or-two-liner functions that are not used anywhere else, out of line?
>> >
>>
>> I think You're Doing It Wrong (tm). If I was doing this, all these
>> function objects would be types themselves, they would be testable
>> outside this context, and they can even be just forward declared and
>> linked statically later on.
>>
>> I don't see why they need or have to be C++11 lambdas at all if
>> they're not just a one-or-two liner and if they have names that do
>> make sense as types.
>
> They *are* one-or-two-liners, and it would be overkill to define them
> out of line.
>

So why are they even chained filters? Why not just:

push_back(container, range | transformed([](element_type const & e) {
  // put all the logic right here
  }
  | filtered([](element_type const & e) {
  // put all the filtering logic right here
  });

Since you're already using C++11? Why even have the placeholder names
in place at all if you don't need it anymore? I don't get it.

>> >
>> > Now repeat this argument, substituting a class for namespace N, and two
>> > methods for A and B, and you have a use case for local functions.
>> >
>>
>> No, I would create nested namespaces specific to the requirements of
>> functions A and B (maybe call them impl_A and impl_B). There's no
>> *need* for local functions in this case you're proposing.
>
> Right, so now you're introducing a new construct (impl_A) just for this
> purpose, because you can't do the natural thing which is to just define
> the functions where they are used, i.e. inside A.
>
> What if you were defining A inline in the class definition? How far
> would impl_A be from A?
>

So here's the thing: from a design perspective, why do you even need a
local function at all? What would you need that local function for?

Is it going to be a parameter to an STL algorithm? If so make it
testable in isolation (from an engineering standpoint) and make it
something that stands alone (from a design standpoint).

Is it going to be called like a normal function? If so then why not
make them normal functions that are not local and be done with it?

If you really needed that function defined in-line as a lambda
function then we already have libraries for that. I don't see what the
need is for yet another library to do exactly the same thing.

>> > Are you suggesting I propose it for the next standard of C++? That would
>> > be silly, as C++11 already has a solution (lambdas), and the whole point
>> > is to make the feature accessible to people who can't use C++11 yet.
>>
>> See my point now?
>
> Well that is precisely why we are proposing a library, and not a language
> feature - we already have the language feature, some people just can't use
> it yet!
>

But it's not lambda's you want to use, it's local functions (which
aren't really even local functions) so there's no point in having this
library at all!

>> > Or are you suggesting that I propose a compiler-specific language
>> > extension for my compiler? That will not fly in an environment where
>> > one's code has to run of many different compilers, and in any case
>> > it goes completely against the spirit of having a language standard
>> > in the first place.
>>
>> Right, so you see why I don't think Boost.Local even makes sense?
>
> I'm sorry, I don't. While compiler-specific language extensions go against
> the spirit of having a language standard, libraries that emulate a language
> feature and work in standard C++ across platforms, such as Boost.Local,
> are very much in line with that spirit. This is what Boost has been doing
> with Foreach, Typeof, Lambda, etc.

So Foreach came at a time when there wasn't even a discussion on
C++0x. Same for typeof, lambda, shared_ptr, etc. -- it's not the same
situation now, where someone's proposing a library that's immediately
antiquated and superseded by a language feature. *This* is why I don't
think it even makes sense to have Boost.Local at all because, frankly,
we've been fine without local functions since 2003 -- what's another
couple of years?

>> >
>> > So you admit that bad errors messages are a problem that users run into
>> > frequently, and that we're not likely to see a solution from the compiler side
>> > any time soon... but you say a library that solves this problem is not
>> > important enough for Boost?
>>
>> Yes, they're not important enough for Boost if what it provides isn't
>> compelling enough to be provided by Boost. If the only thing a library
>> has is "prettier error messages when things are broken" then it's a
>> great library for broken code -- which makes that advantage null and
>> void because IT'S NOT AN ADVANTAGE BECAUSE YOUR CODE DOESN'T COMPILE.
>>
>> Am I not getting through here?
>>
>> Whoever loved a library that looked great when your code fails to
>> compile? This is CRAZY TALK.
>
> How often do you write code that is right the first time around?

Why does this matter?

> Even for
> an experienced programmer, and especially with a new library, more often
> than not your code will initially be broken. To fix it, you need to
> understand the problem, and you need the library's help to do so.
>

This is anecdotal. Hardly convincing in a *logical* and *rational* standpoint.

> So, since writing wrong code is just as much a reality of programming
> as writing working code, having a library that helps you fix your code
> when it's broken is just as important as having a library that runs
> your working code (OK, maybe not "just as important" - but quite
> important).

You got it wrong here: having a *compiler* that helps you fix your
code when it's broken is what you want, not a library!

*sigh*

This is getting tiring because I just keep repeating myself. This is useless.

Cheers

-- 
Dean Michael Berris
http://goo.gl/CKCJX