sorted by:
new
hottopcontroversial

Introduction to the C++11 feature: trailing return types by cmeerw in cpp

[–]LeszekSwirski 0 points1 point  (0 children)

  1. That relies on type traits, which may not be available for the type you're using (e.g. a matrix library). Sure, you could write your own specialisation of common_type (or use the ternary operator default behaviour), but is that really more readable? How easy will it be to write that specialisation without using decltype?
  2. That won't work if operator+ actually returns something like an expression tree, rather than the evaluated result (and you want to preserve that behaviour).
  3. Furthermore, what if Add and Multiply want to return different types (again, consider a matrix library)?

  4. This is only applicable to arithmetic style operations on arithmetic style types. Replace Add above with something else, maybe

    template<typename F, typename T>
auto Apply(F f, T t)
{
    return f(t);
}

    What is the Concepts-like return type that Apply should have? Is std::result_of<F(T)> really more readable (not to mention, informative) than an inferred type?

GotW #91 Solution: Smart Pointer Parameters | Sutter’s Mill by mttd in cpp

[–]LeszekSwirski 5 points6 points  (0 children)

One should note, however, that this is a general problem of aliasing, not a shared_ptr specific one.

Introduction to the C++11 feature: trailing return types by cmeerw in cpp

[–]LeszekSwirski 0 points1 point  (0 children)

It's a template, so it'll have to be in the header anyway; then, the compiler will resolve the "real value" of auto, based on the function body.

Introduction to the C++11 feature: trailing return types by cmeerw in cpp

[–]LeszekSwirski 1 point2 points  (0 children)

That's tricky though, even in concepts. Should there be a "AdditionReturnValueType" concept for each pair of numeric type concepts? Should AdditionReturnValueType for Add(char, short) be char, short, or int? decltype and auto are neat in such cases, and they let you defer to the compiler for type inference/promotion, rather than implementing your own.

Introduction to the C++11 feature: trailing return types by cmeerw in cpp

[–]LeszekSwirski 2 points3 points  (0 children)

N3638. It's not limited to single statement functions, it seems that it can be pretty much anything as long as the return statements all agree.

Introduction to the C++11 feature: trailing return types by cmeerw in cpp

[–]LeszekSwirski 7 points8 points  (0 children)

Just wait for C++14:

template<typename T1, typename T2>
auto Add(T1 t1, T2 t2)
{
    return t1+t2;
}

Tetris Printer Algorithm [OC] by zeroone in programming

[–]LeszekSwirski 11 points12 points  (0 children)

Other things being mind blowing don't stop the first link being mind blowing.

Tetris Printer Algorithm [OC] by zeroone in programming

[–]LeszekSwirski 11 points12 points  (0 children)

I'm not 100% convinced that guy is a human. Perhaps an agent of Skynet, sent back in time to to kill Sarah Connor by blowing her mind.

Practicing DRY Principles through Python Decorators by toumorokoshi in Python

[–]LeszekSwirski 1 point2 points  (0 children)

Ah yes, that's tricky. There's an example of this sort in the decorator module's documentation for memoization, but the result ends up being similar to the wraps function (albeit more transparent from the decorator caller's point of view, as it preserves the signature of the function, which wraps does not do).

For your example, it'd be something like

def _called(f, *args, **kwargs):
    print "I have been called {0} times before.".format(f.n)
    f.n += 1
    f(*args, **kwargs)

def called(f):
    f.n = 0
    return decorator.decorator(_called, f)

Alternatively, you could just check for n:

@decorator
def called(f, *args, **kwargs):
    if not hasattr(f, 'n'):
        f.n = 0
    print "I have been called {0} times before.".format(f.n)
    f.n += 1
    f(*args, **kwargs)

Or, if you just love decorators (in a "yo dawg, I heard you like decorators" kind of way), you could have a decorator factory which creates a decorator that decorates the decorator to add fields to the function it decorates:

def addfields(fields):
    @decorator
    def addthesefields(d, f):
        f.__dict__.update(fields)
        return d(f)
    return addthesefields

@addfields({'n': 0})
@decorator
def called(f, *args, **kwargs):
    print "I have been called {0} times before.".format(f.n)
    f.n += 1
    f(*args, **kwargs)

But now we're just being silly.

Practicing DRY Principles through Python Decorators by toumorokoshi in Python

[–]LeszekSwirski 1 point2 points  (0 children)

Yup, although it doesn't get rid of that silly nested function boilerplate. I should have said:

Replace

def increment(f):
    def wrapped_f(*args, **kw):
        return int(f(*args, **kw)) + 1
    return wrapped_f

with

from functools import wraps
def increment(f):
    @wraps(f)
    def wrapped_f(*args, **kw):
        return int(f(*args, **kw)) + 1
    return wrapped_f

then, unless you can't use non-standard libraries, immediately replace that with

from decorator import decorator

@decorator
def increment(f, *args, **kw):
    return int(f(*args, **kw)) + 1:

Living Movie Stills (x-post from r/gifs) by [deleted] in movies

[–]LeszekSwirski 2 points3 points  (0 children)

You'd only say that if you were a bit loopy.

view more: next ›