On Sunday, 30 March 2014 at 12:42:16 UTC, Jack Applegame wrote:
Target is to create a template for mapping member "array
accessor" to member function.
For example:
class Foo {
...
int elementsAccessor(size_t index) { ... }
...
mixin MagicTemplateMixin!("elements", elementsAccessor);
On 03/30/14 15:36, Jack Applegame wrote:
> Wraper structure again. Is there solution without it?
No. D only allows op overloading in structs/unions/classes, so
one of those will be necessary. The simpliest solution would be
something like:
class C {
int elementsAccessor(size_t index) { .
Wraper structure again. Is there solution without it?
On Sunday, 30 March 2014 at 12:42:16 UTC, Jack Applegame wrote:
Target is to create a template for mapping member "array
accessor" to member function.
For example:
class Foo {
...
int elementsAccessor(size_t index) { ... }
...
mixin MagicTemplateMixin!("elements", elementsAccessor);
Sorry. Not "getter", should be "elementsAccessor" instead.
Target is to create a template for mapping member "array
accessor" to member function.
For example:
class Foo {
...
int elementsAccessor(size_t index) { ... }
...
mixin MagicTemplateMixin!("elements", elementsAccessor);
// or better
alias elements = SuperMagicTemplate!elementsAccess
spir Wrote:
> On 01/25/2011 06:03 PM, Simen kjaeraas wrote:
> >
> > Of course, given a non-template function, it is impossible to safely
> > pass a function to it.
>
> Dont you count this as typesafe function passing?
> void writeRounding (int function (float) roundingScheme) {...}
He mean
> How do you not pass them in a safe manner? If you are casting things,
of course you don't get type safety.
Yep, I was talking about non-template functions.
Only way to pass an arbitrary function is via void*
On 01/25/2011 06:03 PM, Simen kjaeraas wrote:
Of course, given a non-template function, it is impossible to safely
pass a function to it.
Dont you count this as typesafe function passing?
void writeRounding (int function (float) roundingScheme) {...}
Denis
--
_
vita es
Trass3r wrote:
2. What is the reason for Phobos defining param funcs as template
params?
Correct me if I'm wrong but there's no way to pass an arbitrary
function to a function in a type-safe way. If you use pointers and
casts you can't check if the passed function meets certain
requirements (
Trass3r Wrote:
> > 2. What is the reason for Phobos defining param funcs as template
> params?
>
> Correct me if I'm wrong but there's no way to pass an arbitrary
> function to a function in a type-safe way. If you use pointers and
> casts you can't check if the passed function meets certain
> re
> 2. What is the reason for Phobos defining param funcs as template
params?
Correct me if I'm wrong but there's no way to pass an arbitrary
function to a function in a type-safe way. If you use pointers and
casts you can't check if the passed function meets certain
requirements (parameters, return
On Tue, 25 Jan 2011 10:21:29 -0500, spir wrote:
Hello,
This post is about the various roles D templates can play. I had to
write a higher-order function (hof) that takes as parameter a func which
itself returns any kind of type. Thus, the hof is also templated. (Below
the simplest case I
spir wrote:
1. Is the fact that we have so many ways to define the same thing a Good
Thing, according to you?
Yes.
2. What is the reason for Phobos defining param funcs as template
params? Efficiency? Why?
Efficiency is one reason, as DMD is unable to inline functions passed as
paramet
Hello,
This post is about the various roles D templates can play. I had to write a
higher-order function (hof) that takes as parameter a func which itself returns
any kind of type. Thus, the hof is also templated. (Below the simplest case I
could find as example.)
Unlike in functional style,
15 matches
Mail list logo
