Tuesday, April 3, 2018

Digest for comp.lang.c++@googlegroups.com - 11 updates in 7 topics

alessio211734 <alessio211734@yahoo.it>: Apr 03 06:56AM -0700

Hello guy,
 
I try to learn lamdba expression I need do some recursion inside the body of a function so I try to use lambda in this way:
 
auto expand = [&](CMeshO::VertexPointer vp, std::vector<CMeshO::VertexPointer> & region)
{
std::vector<CMeshO::VertexPointer> nearVerts;
MeshProcessing::nearVertex(vp, nearVerts);
for (auto v : nearVerts)
{
if (v->P().Y() < vp->P().Y())
{
region.push_back(v);
expand(v, region);
};
};
};
 
but I get some errors. So can I use lambda and recursion? I use visual studio 2015.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Apr 03 02:25PM

On Tue, 2018-04-03, alessio211734 wrote:
> body of a function so I try to use lambda in this way:
 
> auto expand = [&](CMeshO::VertexPointer vp,
> std::vector<CMeshO::VertexPointer> & region)
 
You don't seem to need to capture anything, so replace [&] with [].
 
> };
> };
 
> but I get some errors.
 
It's very helpful to list the errors, not just mention you get errors.
 
> So can I use lambda and recursion? I use visual studio 2015.
 
I note that your code is similar to
 
int expand = foo(expand);
 
i.e. you use expand before it has been defined. I'm not sure what the
workaround would be, but I suspect that's the error.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
alessio211734 <alessio211734@yahoo.it>: Apr 03 07:48AM -0700

Il giorno martedì 3 aprile 2018 16:26:14 UTC+2, Jorgen Grahn ha scritto:
 
> --
> // Jorgen Grahn <grahn@ Oo o. . .
> \X/ snipabacken.se> O o .
 
 
Error C3493 'expand' cannot be implicitly captured because no default capture mode has been specified ToothSection
expand(v, region);
 
Error C2064 term does not evaluate to a function taking 2 arguments
expand(vp, region);
Ben Bacarisse <ben.lists@bsb.me.uk>: Apr 04 12:03AM +0100

> };
 
> but I get some errors. So can I use lambda and recursion? I use visual
> studio 2015.
 
The trouble is you are trying to use expand before it's type can be
deduced.
 
One solution would be to avoid using auto. To do this you pretty much
have to use std::function because lambdas that have a capture are not
convertible to function pointers. To take a simpler example:
 
std::function<int(int)> f = [&f](int n) {
return n < 1 ? 1 : n * f(n-1);
};
 
If the lambda has no capture, f could be a pointer to function object,
but then you could not refer to f in the body.
 
There are some tricks you can play that simulate the effect of a Y
combinator, but these appeal to me simply on academic grounds. For
example I enjoyed the fact that this works with gcc:
 
auto f = [](int n, auto g){
if (n < 1) return 1;
else return n * g(n-1, g);
};
 
where the call now becomes f(5, f);
 
However, switching back to the big picture, if expand is the only thing
captured, why not write a named function to do this?
 
--
Ben.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Apr 03 02:35PM

Very late reply; I partly blame Easter.
 
On Mon, 2018-03-26, Ian Collins wrote:
>> my code more complex to use it.
 
> How so? Is the design more complex, or do you just end up with more,
> smaller pieces?
 
I'd put it like this: I end up with explicit flexibility that's not
used in runtime. Like dependency injection, where I end up with
pointers to abstract types passed in the constructors, where plain,
concrete members would have sufficed.
 
There may be ways around this, or a better way to reason about such
code, but I haven't found it yet. (But I know you're happy with it.)
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
legalize+jeeves@mail.xmission.com (Richard): Apr 03 04:17PM

[Please do not mail me a copy of your followup]
 
Jorgen Grahn <grahn+nntp@snipabacken.se> spake the secret code
>used in runtime. Like dependency injection, where I end up with
>pointers to abstract types passed in the constructors, where plain,
>concrete members would have sufficed.
 
Your testing alternative is link-time substitution. It's a giant
PITA, but you can do it if you really dislike abstract interface
injection.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Latimerius <l4t1m3r1us@gmail.com>: Apr 03 03:27AM -0700

On Friday, 30 March 2018 08:49:42 UTC+2, Alf P. Steinbach wrote:
> Both `tuple` and `function` have templated constructors that can take
> just about any argument.
 
Ah alright, I think I get it now. I sort of overlooked the templated std::tuple constructors that indeed can take just about anything. If I understand correctly now, in their presence the conversion from lambda to C::Fn is not visible to the initial overload resolution of C's constructors as it only happens afterwards, inside the templated std::tuple constructor. This would indeed make both C's constructors equivalent in terms of overload resolution, each requiring a single argument conversion.
 
Now the remaining question is, why the templated std::tuple constructors are not explicit as they, I believe, should be (until C++17 when they became conditionally explicit). This could be just an implementation defect but apparently, both libstdc++ and libc++ behave the same here even when compiling in C++11 mode. How likely is it that two high-quality independent implementations have the same defect?
 
Thanks!
Christiano <christiano@engineer.com>: Apr 02 04:46PM -0300

I was reading this page:
http://cpp-tip-of-the-day.blogspot.com.br/2013/11/how-is-stddeque-implemented.html
 
The problem is:
Ok, there is chunks of data which will be allocated according with the
necessity, for right or left.
However, How can the mapping of the chunks be implemented?
 
If the mapping is implemented as a vector of pointer to allocated data
(with fixed size), so there will be shifts when a new chunk is
push_front-created, for example.
 
Example:
 
[0x100, 0x200, 0x300] is the mapping (three chunks)
 
now a new chunk (pointer to 0x400 for example) is allocated and added to
beginning of chunks.
 
[0x400, 0x100, 0x200, 0x300]
 
You can notice that the three address were shifted when this behavior (I
think) is not the desired.
 
So, how could the mapping to chunks be implemented?
Robert Wessel <robertwessel2@yahoo.com>: Apr 02 10:59PM -0500

On Thu, 29 Mar 2018 23:23:26 -0700, Tim Rentsch
>necessarily lead to understandable programs. (And which I
>believe is one of the points you were making, or at least would
>agree with.)
 
 
Yes.
 
 
>needed. Like what you said, I don't mean to make an arbitrary
>rule, but to give a useful empirical guideline for after-the-fact
>assessment.
 
 
My "limits" are a bit higher. I personally find sizes that low as
often forcing (or at least "strongly suggesting") decomposition
because you can, rather than because you should. Still, I'd say the
difference between a median of 10 and a median of 20 is more a quibble
than a qualitative change.
Daniel <danielaparker@gmail.com>: Apr 02 05:12PM -0700

On Monday, April 2, 2018 at 11:45:56 AM UTC-4, Tim Rentsch wrote:
> think I understand some of the motivations behind it, but it
> grates on my low-level linguistic mental machinery, and that is
> almost always a sign that somewhere a poor choice was made.
 
Agreed. Although I think users of a library may have a different
perspective :-) As a user of boost, I really don't care what the
namespace names are, I look them up in the online docs, and use them.
I think it's library makers that agonize over the names, as here.

> > and am thinking of changing it to cbor, cbor, and packed_cbor.
 
Did do that
 
 
> Depending on what "packed" is supposed to mean, "packed_cbor" is
> either pointlessly redundant or self-contradictory.
 
Good point. It's accepted terminology to "unpack" a cbor encoded byte array
into a form that can be more readily manipulated, and then "pack" that back
into a byte array encoded as cbor, but "packed_cbor" conjures an oxymoron,
thanks for pointing that out.
 
> would be a better choice for the class name. Yes, the name is a
> little long, but it is nicely descriptive, and most likely will
> be used relatively rarely.
 
Thanks for the suggestion, will reflect on it.
 
Daniel
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 03 12:42AM +0100

On 03/04/2018 00:13, Rick C. Hodgin wrote:
>> wasted.
 
> I believe people should be paid for their labor. I think $240 for the
> first year, and $120 for ongoing years is sufficient for PVS-Studio.
 
It costs what it costs not what you think it should cost you batshit
crazy pretentious cockwomble.
 
/Flibble
--
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates
a world that is so full of injustice and pain. That's what I would say."
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.

No comments: