auto foo(...) ->decltype(this) Is there some workaround?

I have next class and try to declare member function which will return pointer to a that type but next code

template<class Key, int b> class b_plus_tree_inner_node {
  auto split() -> decltype(this) {}
};

gives me such error

invalid use of ‘this’ at top level

can i do it in another way, i now about existence of typedef, but may be its possible with decltype?

EDITED:

i want to accomplish this:

b_plus_tree_inner_node<Key, b>* split() {...}

If you want a member function declare it inside the class:

template<class Key, int b> class b_plus_tree_inner_node {
   b_plus_tree_inner_node* split(){}
   // also valid:
   //b_plus_tree_inner_node<Key, b>* split(){}
};

If you want a non-member function, make it a template:

template<class Key, int b>
b_plus_tree_inner_node<Key, b>* split(){}

The standard does allow you to write auto split() -> decltype(this) {} but GCC 4.6 doesn't support it yet (the trunk of GCC 4.7 does).

if info method is public you can do:

//...
public function fire()
{
    $self = $this;
    $self->info('starting chunk');
    item::chunk(1000, function($items) use ($self)
    {
        foreach ($items as $item)
        {
            $self->info($item->img);
        }
    }
    );

}
//...


if info is private you can't and you need to upgrade to php 5.4, because in php 5.3 the context in the closure is not the same of the object context.

the easiest custom approach i've seen and used as far is to create a <h:inputhidden> field with a <f:validator> wherein you reference all involved components as <f:attribute>. if you declare it before the to-be-validated components, then you can obtain the submitted values inside the validator by uiinput#getsubmittedvalue().

e.g.

<h:form>
    <h:inputhidden id="foo" value="true">
        <f:validator validatorid="foovalidator" />
        <f:attribute name="input1" value="#{input1}" />
        <f:attribute name="input2" value="#{input2}" />
        <f:attribute name="input3" value="#{input3}" />
    </h:inputhidden>
    <h:inputtext binding="#{input1}" value="#{bean.input1}" />
    <h:inputtext binding="#{input2}" value="#{bean.input2}" />
    <h:inputtext binding="#{input3}" value="#{bean.input3}" />
    <h:commandbutton value="submit" action="#{bean.submit}" />
    <h:message for="foo" />
</h:form>

(please note the value="true" on the hidden input; the actual value actually doesn't matter, but keep in mind that the validator won't necessarily be fired when it's null or empty, depending on the jsf version and configuration)

with

@facesvalidator(value="foovalidator")
public class foovalidator implements validator {

    @override
    public void validate(facescontext context, uicomponent component, object value) throws validatorexception {
        uiinput input1 = (uiinput) component.getattributes().get("input1");
        uiinput input2 = (uiinput) component.getattributes().get("input2");
        uiinput input3 = (uiinput) component.getattributes().get("input3");
        // ...
        
        object value1 = input1.getsubmittedvalue();
        object value2 = input2.getsubmittedvalue();
        object value3 = input3.getsubmittedvalue();
        // ...
    }

}

if you declare the <h:inputhidden> after the to-be-validated components, then the values of the involved components are already converted and validated and you should obtain them by uiinput#getvalue() or maybe uiinput#getlocalvalue() (in case the uiinput isn't isvalid()) instead.

see also:

  • validator for multiple fields (jsf 1.2 targeted)

alternatively, you can use 3rd party tags/components for that. richfaces for example has a <rich:graphvalidator> tag for this, seam3 has a <s:validateform> for this, and omnifaces has several standard <o:validatexxx> components for this which are all showcased here. omnifaces uses a component based approach whereby the job is done in uicomponent#processvalidators(). it also allows customizing it in such way so that the above can be achieved as below:

<h:form>
    <o:validatemultiple id="foo" components="input1 input2 input3" validator="#{foovalidator}" />
    <h:inputtext id="input1" value="#{bean.input1}" />
    <h:inputtext id="input2" value="#{bean.input2}" />
    <h:inputtext id="input3" value="#{bean.input3}" />
    <h:commandbutton value="submit" action="#{bean.submit}" />
    <h:message for="foo" />
</h:form>

with

@managedbean
@requestscoped
public class foovalidator implements multifieldvalidator {

    @override
    public boolean validatevalues(facescontext context, list<uiinput> components, list<object> values) {
        // ...
    }
}

the only difference is that it returns a boolean and that the message should be specified as message attribute in <o:validatemultiple>.

something along these lines, perhaps (untested):

template <typename f>
class composer {
  int n_;
  f f_;
public:
  composer(int n, f f) : n_(n), f_(f) {}

  template <typename t>
  t operator()(t x) const {
    int n = n_;
    while (n--) {
      x = f_(x);
    }
    return x;
  }
};

template <int n, typename f>
composer<f> compose(f f) {
  return composer<f>(n, f);
}

edit: and for the second case (tested this time):

#include <iostream>

template <typename f0, typename... f>
class composer2 {
    f0 f0_;
    composer2<f...> tail_;
public:
    composer2(f0 f0, f... f) : f0_(f0), tail_(f...) {}

    template <typename t>
    t operator() (const t& x) const {
        return f0_(tail_(x));
    }
};

template <typename f>
class composer2<f> {
    f f_;
public:
    composer2(f f) : f_(f) {}

    template <typename t>
    t operator() (const t& x) const {
        return f_(x);
    }
};

template <typename... f>
composer2<f...> compose2(f... f) {
    return composer2<f...>(f...);
}

int f(int x) { return x + 1; }
int g(int x) { return x * 2; }
int h(int x) { return x - 1; }

int main() {
  std::cout << compose2(f, g, h)(42);
  return 0;
}

this is my opinion.

when using auto as type specifier, it's cleaner to use:

auto q = p;   // type of q is same as type of p
auto r = {p}; // type of r is std::initializer_list<...>

when using explicit type specifier, it's better to use {} instead of ().

int a{};   // value initialized to 0
int b();   // declares a function (the most vexing parse)

one could use

int a = 0; // value initialized to 0

however, the form

int a{};

can be used to value initialize objects of user defined types too. e.g.

struct foo
{
   int a;
   double b;
};


foo f1 = 0;  // not allowed.
foo f1{};    // zero initialized.

Tags: C++ C++11