Rectangle 27 141

It's a "pointer to member" - the following code illustrates its use:

#include <iostream>
using namespace std;

class Car
{
    public:
    int speed;
};

int main()
{
    int Car::*pSpeed = &Car::speed;

    Car c1;
    c1.speed = 1;       // direct access
    cout << "speed is " << c1.speed << endl;
    c1.*pSpeed = 2;     // access via pointer to member
    cout << "speed is " << c1.speed << endl;
    return 0;
}

As to why you would want to do that, well it gives you another level of indirection that can solve some tricky problems. But to be honest, I've never had to use them in my own code.

Edit: I can't think off-hand of a convincing use for pointers to member data. Pointer to member functions can be used in pluggable architectures, but once again producing an example in a small space defeats me. The following is my best (untested) try - an Apply function that would do some pre &post processing before applying a user-selected member function to an object:

void Apply( SomeClass * c, void (SomeClass::*func)() ) {
    // do hefty pre-call processing
    (c->*func)();  // call user specified function
    // do hefty post-call processing
}

The parentheses around c->*func are necessary because the ->* operator has lower precedence than the function call operator.

Could you show an example of a tricky situation where this is useful? Thanks.

I have an example of using pointer-to-member in a Traits class in another SO answer.

An example is writing a "callback"-type class for some event-based system. CEGUIs UI event subscription system, for example, takes a templated callback that stores a pointer to a member function of your choosing, so that you can specify a method to handle the event.

There is a pretty cool example of pointer-to-data-member usage in a template function in this code

I have recently used pointers to data members in serialization framework. Static marshaller object was initialized with list of wrappers containing pointer to serializable data members. An early prototype of this code.

C++: Pointer to class data member "::*" - Stack Overflow

c++ class pointers
Rectangle 27 7

You are going to need a template, and to change the inheritance to use the template, as you will see. The trick is to make it work whether the derived class has an X to overshadow the base-class X or not.

template<class C>
struct A {
    static const int X = 1;
    template<typename T>
    static int getX(decltype(T::X)*) 
        { return T::X; }
    template<typename T>
    static void getX(...)
        { return X; }
    static void printX()
        { std::cout << "X " << getX<C>(0) << std::endl; }
};

struct B: public A<B> {
    static const int X = 2;
};

struct B2: public A<B2> {
    // No X
};

int main(){
    B b;
    b.printX(); // Prints X 2
    B2 b2;
    b2.printX(); // Prints X 1
}

Warmer! But cumbersome a little bit. And BTW, why did you use decltype(T::X) with asterisk? Why pointer, not value?

+1 Nice solution! (@OlegG the pointer is necessary so the dummy argument 0 works regardless of the type of X)

Nice solution but I still think that the design is bad and Oleg needs to sit down and either rethink it or tell us what he's actually trying to do.

@NikB. See the second edition of my question, please

@JiveDadson: generally speaking, usage of templates in this task is not very good solution because of inheritance necessity. Your idea to use decltype() is nice but it will better to invent some analogue of this for a current type value. Then we'll just write cout << this::X << endl and that was all I need. The question is how to invent that this?

C++ static const members overriding - Stack Overflow

c++ static-members
Rectangle 27 7

Even though there are plenty of good explanations above, I'm missing a practical way to separate templates into header and body. My main concern is avoiding recompilation of all template users, when I change its definition. Having all template instantiations in the template body is not a viable solution for me, since the template author may not know all if its usage and the template user may not have the right to modify it. I took the following approach, which works also for older compilers (gcc 4.3.4, aCC A.03.13).

For each template usage there's a typedef in its own header file (generated from the UML model). Its body contains the instantiation (which ends up in a library which is linked in at the end). Each user of the template includes that header file and uses the typedef.

#ifndef MyTemplate_h
#define MyTemplate_h 1

template <class T>
class MyTemplate
{
public:
  MyTemplate(const T& rt);
  void dump();
  T t;
};

#endif
#include "MyTemplate.h"
#include <iostream>

template <class T>
MyTemplate<T>::MyTemplate(const T& rt)
: t(rt)
{
}

template <class T>
void MyTemplate<T>::dump()
{
  cerr << t << endl;
}
#ifndef MyInstantiatedTemplate_h
#define MyInstantiatedTemplate_h 1
#include "MyTemplate.h"

typedef MyTemplate< int > MyInstantiatedTemplate;

#endif
#include "MyTemplate.cpp"

template class MyTemplate< int >;
#include "MyInstantiatedTemplate.h"

int main()
{
  MyInstantiatedTemplate m(100);
  m.dump();
  return 0;
}

This way only the template instantiations will need to be recompiled, not all template users (and dependencies).

c++ - Why can templates only be implemented in the header file? - Stac...

c++ templates c++-faq
Rectangle 27 1

1) In fact, you're right. xsl:for-each is a sort of "anonymous inline template". It's actually bad practice in many cases, since it tends to indicate that the stylesheet is being written procedurally rather than rule-driven... but it is occasionally the best way to express your logic. As with most programming languages, there's more than one way to solve most problems and it's up to the programmer to develop a sense of style to pick the best one.

2) As Ian Roberts said, "yes, that will work, but books/child::* can be shortened to books/* as child:: is the default axis". (He does deserve the credit for answering that one -- I was half-asleep and didn't get a Round Tuit.)

Thanks keshlam .How can i accept your answer for (1) as well as @IanRoberts anwer for (2) ? can you quote his reply or need I? I have to try putting the position() or <xsl:number/> inside the <xsl:template /> to see if i get the expected output as in the case of putting position() inside the <xsl:for-each />. I will try it out and accept soon.

Here you see why it's a good idea to split different questions in the first place. Create a new question for 2.

@GnterZchbauer Yes, you're right. Going forward, i will ensure i will stick to one question per thread. I don't think appropriate to break this thread as it is complete now. However, I still have a question related to using position() on the two approaches, and i will post it in a seperate question.

I posted my query on position() usage in template vs for-each , as a different SO question - stackoverflow.com/questions/21470578/

XSLT Correct usage of child::* , Difference between using xsl:for-each...

xslt xslt-1.0
Rectangle 27 1

There's a helper template library that ships with Django (humanize) which has a filter called intcomma that sounds like it would do what you want.

Usage in a template:

{% load humanize %}
${{ value|intcomma }}

Thanks. I should have mentioned that I am cycling through the variables dynamically, hence why I'm wondering why when I have set everything I still don't get my int's seperated out

Django localisation - Stack Overflow

django
Rectangle 27 99

<UserControl ...>
    <TextBlock x:Name="myTextBlock" />
</UserControl>

In the code-behind file, you could write:

var myTextBlock = (TextBlock)this.FindName("myTextBlock");

Of course, because it's defined using x:Name, you could just reference the generated field, but perhaps you want to look it up dynamically rather than statically.

This approach is also available for templates, in which the named item appears multiple times (once per usage of the template).

How can I find WPF controls by name or type? - Stack Overflow

wpf controls find
Rectangle 27 8

Even though there are plenty of good explanations above, I'm missing a practical way to separate templates into header and body. My main concern is avoiding recompilation of all template users, when I change its definition. Having all template instantiations in the template body is not a viable solution for me, since the template author may not know all if its usage and the template user may not have the right to modify it. I took the following approach, which works also for older compilers (gcc 4.3.4, aCC A.03.13).

For each template usage there's a typedef in its own header file (generated from the UML model). Its body contains the instantiation (which ends up in a library which is linked in at the end). Each user of the template includes that header file and uses the typedef.

#ifndef MyTemplate_h
#define MyTemplate_h 1

template <class T>
class MyTemplate
{
public:
  MyTemplate(const T& rt);
  void dump();
  T t;
};

#endif
#include "MyTemplate.h"
#include <iostream>

template <class T>
MyTemplate<T>::MyTemplate(const T& rt)
: t(rt)
{
}

template <class T>
void MyTemplate<T>::dump()
{
  cerr << t << endl;
}
#ifndef MyInstantiatedTemplate_h
#define MyInstantiatedTemplate_h 1
#include "MyTemplate.h"

typedef MyTemplate< int > MyInstantiatedTemplate;

#endif
#include "MyTemplate.cpp"

template class MyTemplate< int >;
#include "MyInstantiatedTemplate.h"

int main()
{
  MyInstantiatedTemplate m(100);
  m.dump();
  return 0;
}

This way only the template instantiations will need to be recompiled, not all template users (and dependencies).

c++ - Why can templates only be implemented in the header file? - Stac...

c++ templates c++-faq
Rectangle 27 8

Even though there are plenty of good explanations above, I'm missing a practical way to separate templates into header and body. My main concern is avoiding recompilation of all template users, when I change its definition. Having all template instantiations in the template body is not a viable solution for me, since the template author may not know all if its usage and the template user may not have the right to modify it. I took the following approach, which works also for older compilers (gcc 4.3.4, aCC A.03.13).

For each template usage there's a typedef in its own header file (generated from the UML model). Its body contains the instantiation (which ends up in a library which is linked in at the end). Each user of the template includes that header file and uses the typedef.

#ifndef MyTemplate_h
#define MyTemplate_h 1

template <class T>
class MyTemplate
{
public:
  MyTemplate(const T& rt);
  void dump();
  T t;
};

#endif
#include "MyTemplate.h"
#include <iostream>

template <class T>
MyTemplate<T>::MyTemplate(const T& rt)
: t(rt)
{
}

template <class T>
void MyTemplate<T>::dump()
{
  cerr << t << endl;
}
#ifndef MyInstantiatedTemplate_h
#define MyInstantiatedTemplate_h 1
#include "MyTemplate.h"

typedef MyTemplate< int > MyInstantiatedTemplate;

#endif
#include "MyTemplate.cpp"

template class MyTemplate< int >;
#include "MyInstantiatedTemplate.h"

int main()
{
  MyInstantiatedTemplate m(100);
  m.dump();
  return 0;
}

This way only the template instantiations will need to be recompiled, not all template users (and dependencies).

c++ - Why can templates only be implemented in the header file? - Stac...

c++ templates c++-faq
Rectangle 27 8

Even though there are plenty of good explanations above, I'm missing a practical way to separate templates into header and body. My main concern is avoiding recompilation of all template users, when I change its definition. Having all template instantiations in the template body is not a viable solution for me, since the template author may not know all if its usage and the template user may not have the right to modify it. I took the following approach, which works also for older compilers (gcc 4.3.4, aCC A.03.13).

For each template usage there's a typedef in its own header file (generated from the UML model). Its body contains the instantiation (which ends up in a library which is linked in at the end). Each user of the template includes that header file and uses the typedef.

#ifndef MyTemplate_h
#define MyTemplate_h 1

template <class T>
class MyTemplate
{
public:
  MyTemplate(const T& rt);
  void dump();
  T t;
};

#endif
#include "MyTemplate.h"
#include <iostream>

template <class T>
MyTemplate<T>::MyTemplate(const T& rt)
: t(rt)
{
}

template <class T>
void MyTemplate<T>::dump()
{
  cerr << t << endl;
}
#ifndef MyInstantiatedTemplate_h
#define MyInstantiatedTemplate_h 1
#include "MyTemplate.h"

typedef MyTemplate< int > MyInstantiatedTemplate;

#endif
#include "MyTemplate.cpp"

template class MyTemplate< int >;
#include "MyInstantiatedTemplate.h"

int main()
{
  MyInstantiatedTemplate m(100);
  m.dump();
  return 0;
}

This way only the template instantiations will need to be recompiled, not all template users (and dependencies).

c++ - Why can templates only be implemented in the header file? - Stac...

c++ templates c++-faq
Rectangle 27 8

Even though there are plenty of good explanations above, I'm missing a practical way to separate templates into header and body. My main concern is avoiding recompilation of all template users, when I change its definition. Having all template instantiations in the template body is not a viable solution for me, since the template author may not know all if its usage and the template user may not have the right to modify it. I took the following approach, which works also for older compilers (gcc 4.3.4, aCC A.03.13).

For each template usage there's a typedef in its own header file (generated from the UML model). Its body contains the instantiation (which ends up in a library which is linked in at the end). Each user of the template includes that header file and uses the typedef.

#ifndef MyTemplate_h
#define MyTemplate_h 1

template <class T>
class MyTemplate
{
public:
  MyTemplate(const T& rt);
  void dump();
  T t;
};

#endif
#include "MyTemplate.h"
#include <iostream>

template <class T>
MyTemplate<T>::MyTemplate(const T& rt)
: t(rt)
{
}

template <class T>
void MyTemplate<T>::dump()
{
  cerr << t << endl;
}
#ifndef MyInstantiatedTemplate_h
#define MyInstantiatedTemplate_h 1
#include "MyTemplate.h"

typedef MyTemplate< int > MyInstantiatedTemplate;

#endif
#include "MyTemplate.cpp"

template class MyTemplate< int >;
#include "MyInstantiatedTemplate.h"

int main()
{
  MyInstantiatedTemplate m(100);
  m.dump();
  return 0;
}

This way only the template instantiations will need to be recompiled, not all template users (and dependencies).

c++ - Why can templates only be implemented in the header file? - Stac...

c++ templates c++-faq
Rectangle 27 8

Even though there are plenty of good explanations above, I'm missing a practical way to separate templates into header and body. My main concern is avoiding recompilation of all template users, when I change its definition. Having all template instantiations in the template body is not a viable solution for me, since the template author may not know all if its usage and the template user may not have the right to modify it. I took the following approach, which works also for older compilers (gcc 4.3.4, aCC A.03.13).

For each template usage there's a typedef in its own header file (generated from the UML model). Its body contains the instantiation (which ends up in a library which is linked in at the end). Each user of the template includes that header file and uses the typedef.

#ifndef MyTemplate_h
#define MyTemplate_h 1

template <class T>
class MyTemplate
{
public:
  MyTemplate(const T& rt);
  void dump();
  T t;
};

#endif
#include "MyTemplate.h"
#include <iostream>

template <class T>
MyTemplate<T>::MyTemplate(const T& rt)
: t(rt)
{
}

template <class T>
void MyTemplate<T>::dump()
{
  cerr << t << endl;
}
#ifndef MyInstantiatedTemplate_h
#define MyInstantiatedTemplate_h 1
#include "MyTemplate.h"

typedef MyTemplate< int > MyInstantiatedTemplate;

#endif
#include "MyTemplate.cpp"

template class MyTemplate< int >;
#include "MyInstantiatedTemplate.h"

int main()
{
  MyInstantiatedTemplate m(100);
  m.dump();
  return 0;
}

This way only the template instantiations will need to be recompiled, not all template users (and dependencies).

c++ - Why can templates only be implemented in the header file? - Stac...

c++ templates c++-faq
Rectangle 27 7

Even though there are plenty of good explanations above, I'm missing a practical way to separate templates into header and body. My main concern is avoiding recompilation of all template users, when I change its definition. Having all template instantiations in the template body is not a viable solution for me, since the template author may not know all if its usage and the template user may not have the right to modify it. I took the following approach, which works also for older compilers (gcc 4.3.4, aCC A.03.13).

For each template usage there's a typedef in its own header file (generated from the UML model). Its body contains the instantiation (which ends up in a library which is linked in at the end). Each user of the template includes that header file and uses the typedef.

#ifndef MyTemplate_h
#define MyTemplate_h 1

template <class T>
class MyTemplate
{
public:
  MyTemplate(const T& rt);
  void dump();
  T t;
};

#endif
#include "MyTemplate.h"
#include <iostream>

template <class T>
MyTemplate<T>::MyTemplate(const T& rt)
: t(rt)
{
}

template <class T>
void MyTemplate<T>::dump()
{
  cerr << t << endl;
}
#ifndef MyInstantiatedTemplate_h
#define MyInstantiatedTemplate_h 1
#include "MyTemplate.h"

typedef MyTemplate< int > MyInstantiatedTemplate;

#endif
#include "MyTemplate.cpp"

template class MyTemplate< int >;
#include "MyInstantiatedTemplate.h"

int main()
{
  MyInstantiatedTemplate m(100);
  m.dump();
  return 0;
}

This way only the template instantiations will need to be recompiled, not all template users (and dependencies).

c++ - Why can templates only be implemented in the header file? - Stac...

c++ templates c++-faq
Rectangle 27 7

Even though there are plenty of good explanations above, I'm missing a practical way to separate templates into header and body. My main concern is avoiding recompilation of all template users, when I change its definition. Having all template instantiations in the template body is not a viable solution for me, since the template author may not know all if its usage and the template user may not have the right to modify it. I took the following approach, which works also for older compilers (gcc 4.3.4, aCC A.03.13).

For each template usage there's a typedef in its own header file (generated from the UML model). Its body contains the instantiation (which ends up in a library which is linked in at the end). Each user of the template includes that header file and uses the typedef.

#ifndef MyTemplate_h
#define MyTemplate_h 1

template <class T>
class MyTemplate
{
public:
  MyTemplate(const T& rt);
  void dump();
  T t;
};

#endif
#include "MyTemplate.h"
#include <iostream>

template <class T>
MyTemplate<T>::MyTemplate(const T& rt)
: t(rt)
{
}

template <class T>
void MyTemplate<T>::dump()
{
  cerr << t << endl;
}
#ifndef MyInstantiatedTemplate_h
#define MyInstantiatedTemplate_h 1
#include "MyTemplate.h"

typedef MyTemplate< int > MyInstantiatedTemplate;

#endif
#include "MyTemplate.cpp"

template class MyTemplate< int >;
#include "MyInstantiatedTemplate.h"

int main()
{
  MyInstantiatedTemplate m(100);
  m.dump();
  return 0;
}

This way only the template instantiations will need to be recompiled, not all template users (and dependencies).

c++ - Why can templates only be implemented in the header file? - Stac...

c++ templates c++-faq
Rectangle 27 7

Even though there are plenty of good explanations above, I'm missing a practical way to separate templates into header and body. My main concern is avoiding recompilation of all template users, when I change its definition. Having all template instantiations in the template body is not a viable solution for me, since the template author may not know all if its usage and the template user may not have the right to modify it. I took the following approach, which works also for older compilers (gcc 4.3.4, aCC A.03.13).

For each template usage there's a typedef in its own header file (generated from the UML model). Its body contains the instantiation (which ends up in a library which is linked in at the end). Each user of the template includes that header file and uses the typedef.

#ifndef MyTemplate_h
#define MyTemplate_h 1

template <class T>
class MyTemplate
{
public:
  MyTemplate(const T& rt);
  void dump();
  T t;
};

#endif
#include "MyTemplate.h"
#include <iostream>

template <class T>
MyTemplate<T>::MyTemplate(const T& rt)
: t(rt)
{
}

template <class T>
void MyTemplate<T>::dump()
{
  cerr << t << endl;
}
#ifndef MyInstantiatedTemplate_h
#define MyInstantiatedTemplate_h 1
#include "MyTemplate.h"

typedef MyTemplate< int > MyInstantiatedTemplate;

#endif
#include "MyTemplate.cpp"

template class MyTemplate< int >;
#include "MyInstantiatedTemplate.h"

int main()
{
  MyInstantiatedTemplate m(100);
  m.dump();
  return 0;
}

This way only the template instantiations will need to be recompiled, not all template users (and dependencies).

c++ - Why can templates only be implemented in the header file? - Stac...

c++ templates c++-faq
Rectangle 27 7

Even though there are plenty of good explanations above, I'm missing a practical way to separate templates into header and body. My main concern is avoiding recompilation of all template users, when I change its definition. Having all template instantiations in the template body is not a viable solution for me, since the template author may not know all if its usage and the template user may not have the right to modify it. I took the following approach, which works also for older compilers (gcc 4.3.4, aCC A.03.13).

For each template usage there's a typedef in its own header file (generated from the UML model). Its body contains the instantiation (which ends up in a library which is linked in at the end). Each user of the template includes that header file and uses the typedef.

#ifndef MyTemplate_h
#define MyTemplate_h 1

template <class T>
class MyTemplate
{
public:
  MyTemplate(const T& rt);
  void dump();
  T t;
};

#endif
#include "MyTemplate.h"
#include <iostream>

template <class T>
MyTemplate<T>::MyTemplate(const T& rt)
: t(rt)
{
}

template <class T>
void MyTemplate<T>::dump()
{
  cerr << t << endl;
}
#ifndef MyInstantiatedTemplate_h
#define MyInstantiatedTemplate_h 1
#include "MyTemplate.h"

typedef MyTemplate< int > MyInstantiatedTemplate;

#endif
#include "MyTemplate.cpp"

template class MyTemplate< int >;
#include "MyInstantiatedTemplate.h"

int main()
{
  MyInstantiatedTemplate m(100);
  m.dump();
  return 0;
}

This way only the template instantiations will need to be recompiled, not all template users (and dependencies).

c++ - Why can templates only be implemented in the header file? - Stac...

c++ templates c++-faq
Rectangle 27 3

The preferred method of integrating jQuery plugins into Vue 2 is to wrap them in a component. Here is an example of your Chosen plugin wrapped in a component that handles both single and multiple selects.

Vue.component("chosen-select",{
  props:{
    value: [String, Array],
    multiple: Boolean
  },
  template:`<select :multiple="multiple"><slot></slot></select>`,
  mounted(){
    $(this.$el)
      .val(this.value)
      .chosen()
      .on("change", e => this.$emit('input', $(this.$el).val()))
  },
  watch:{
    value(val){
       $(this.$el).val(val).trigger('chosen:updated');
    }
  },
  destroyed() {
      $(this.$el).chosen('destroy');
  }
})

And this is an example of usage in a template:

This component doesn't handle multiple selects correctly, but leaving it here because it was the original answer that was accepted.

Vue.component("chosen-select",{
  props:["value"],
  template:`<select class="cs-select" :value="value"><slot></slot></select>`,
  mounted(){
    $(this.$el)
      .chosen()
      .on("change", () => this.$emit('input', $(this.$el).val()))
  }
})

This component supports v-model. So that you can use it in your template like so:

<chosen-select v-model='cities'>
  <option value="Toronto">Toronto</option>
  <option value="Orleans">Orleans</option>
</chosen-select>

Hi Bret, Thankyou for your reply. My problem is that select data is coming from the server, I cannot change the select to chosen-select.

@wagas Do you mean the options are coming from the server?

I am using Python Django and the whole form is coming from the server. Because of data inside options changes on every refresh. The only thing I can do is add attributes like v-model etc

@Waqas You can use is to tell Vue to treat a normal select as a Chosen select. jsfiddle.net/q21ygz3h/2

vuejs2 - Vue 2 With Jquery Chosen - Stack Overflow

vuejs2 vue-component
Rectangle 27 6

Even though there are plenty of good explanations above, I'm missing a practical way to separate templates into header and body. My main concern is avoiding recompilation of all template users, when I change its definition. Having all template instantiations in the template body is not a viable solution for me, since the template author may not know all if its usage and the template user may not have the right to modify it. I took the following approach, which works also for older compilers (gcc 4.3.4, aCC A.03.13).

For each template usage there's a typedef in its own header file (generated from the UML model). Its body contains the instantiation (which ends up in a library which is linked in at the end). Each user of the template includes that header file and uses the typedef.

#ifndef MyTemplate_h
#define MyTemplate_h 1

template <class T>
class MyTemplate
{
public:
  MyTemplate(const T& rt);
  void dump();
  T t;
};

#endif
#include "MyTemplate.h"
#include <iostream>

template <class T>
MyTemplate<T>::MyTemplate(const T& rt)
: t(rt)
{
}

template <class T>
void MyTemplate<T>::dump()
{
  cerr << t << endl;
}
#ifndef MyInstantiatedTemplate_h
#define MyInstantiatedTemplate_h 1
#include "MyTemplate.h"

typedef MyTemplate< int > MyInstantiatedTemplate;

#endif
#include "MyTemplate.cpp"

template class MyTemplate< int >;
#include "MyInstantiatedTemplate.h"

int main()
{
  MyInstantiatedTemplate m(100);
  m.dump();
  return 0;
}

This way only the template instantiations will need to be recompiled, not all template users (and dependencies).

c++ - Why can templates only be implemented in the header file? - Stac...

c++ templates c++-faq
Rectangle 27 6

Even though there are plenty of good explanations above, I'm missing a practical way to separate templates into header and body. My main concern is avoiding recompilation of all template users, when I change its definition. Having all template instantiations in the template body is not a viable solution for me, since the template author may not know all if its usage and the template user may not have the right to modify it. I took the following approach, which works also for older compilers (gcc 4.3.4, aCC A.03.13).

For each template usage there's a typedef in its own header file (generated from the UML model). Its body contains the instantiation (which ends up in a library which is linked in at the end). Each user of the template includes that header file and uses the typedef.

#ifndef MyTemplate_h
#define MyTemplate_h 1

template <class T>
class MyTemplate
{
public:
  MyTemplate(const T& rt);
  void dump();
  T t;
};

#endif
#include "MyTemplate.h"
#include <iostream>

template <class T>
MyTemplate<T>::MyTemplate(const T& rt)
: t(rt)
{
}

template <class T>
void MyTemplate<T>::dump()
{
  cerr << t << endl;
}
#ifndef MyInstantiatedTemplate_h
#define MyInstantiatedTemplate_h 1
#include "MyTemplate.h"

typedef MyTemplate< int > MyInstantiatedTemplate;

#endif
#include "MyTemplate.cpp"

template class MyTemplate< int >;
#include "MyInstantiatedTemplate.h"

int main()
{
  MyInstantiatedTemplate m(100);
  m.dump();
  return 0;
}

This way only the template instantiations will need to be recompiled, not all template users (and dependencies).

c++ - Why can templates only be implemented in the header file? - Stac...

c++ templates c++-faq
Rectangle 27 1

You need to forward declare usages of the template class with the proper linkage (declspec import/export for visual studio or 'extern' for everything else) so that the compiler does not try to generate code for those imported types.

#ifdef _WIN32
#    define TEMPLATE_EXTERN
#    ifdef EXPORT
#        define LIB_EXPORT __declspec(dllexport)
#    else
#        define LIB_EXPORT __declspec(dllimport)
#    endif
#else
#    define TEMPLATE_EXTERN extern
#    define LIB_EXPORT
#endif

class PropertyHelper<const T>
{
public:
    typedef typename PropertyHelper<T>::return_type return_type;

    static inline return_type fromString(const String& str)
    {
        return PropertyHelper<T>::fromString(str);
    }

    static const int SomeValue;
};

// forward declare the specialization
TEMPLATE_EXTERN template class LIB_EXPORT PropertyHelper<float>;
// define the symbol to turn on exporting
#define EXPORT
#include "class.h"
// explicitly instantiate the specialization
template class PropertyHelper<float>
#include "class.h"
int main() {
    PropertyHelper<float> floatHelper; // should be imported, class.h was not #include'ed with EXPORT defined
    return 0;
}

What are you instantiating and why? This is merely a class offering static functions.

c++ - How to separate definition from the declaration for a class temp...

c++ templates c++11 dll
Rectangle 27 384

I understand the situation a bit better now (in no small amount due to the answers here!), so I thought I add a little write-up of my own.

There are two distinct, though related, concepts in C++11: Asynchronous computation (a function that is called somewhere else), and concurrent execution (a thread, something that does work concurrently). The two are somewhat orthogonal concepts. Asynchronous computation is just a different flavour of function call, while a thread is an execution context. Threads are useful in their own right, but for the purpose of this discussion, I will treat them as an implementation detail.

There is a hierarchy of abstraction for asynchronous computation. For example's sake, suppose we have a function that takes some arguments:

int foo(double, char, bool);

First off, we have the template std::future<T>, which represents a future value of type T. The value can be retrieved via the member function get(), which effectively synchronizes the program by waiting for the result. Alternatively, a future supports wait_for(), which can be used to probe whether or not the result is already available. Futures should be thought of as the asynchronous drop-in replacement for ordinary return types. For our example function, we expect a std::future<int>.

Now, on to the hierarchy, from highest to lowest level:

std::async: The most convenient and straight-forward way to perform an asynchronous computation is via the async function template, which returns the matching future immediately:

auto fut = std::async(foo, 1.5, 'x', false);  // is a std::future<int>

We have very little control over the details. In particular, we don't even know if the function is executed concurrently, serially upon get(), or by some other black magic. However, the result is easily obtained when needed:

auto res = fut.get();  // is an int

We can now consider how to implement something like async, but in a fashion that we control. For example, we may insist that the function be executed in a separate thread. We already know that we can provide a separate thread by means of the std::thread class.

The next lower level of abstraction does exactly that: std::packaged_task. This is a template that wraps a function and provides a future for the functions return value, but the object itself is callable, and calling it is at the user's discretion. We can set it up like this:

std::packaged_task<int(double, char, bool)> tsk(foo);

auto fut = tsk.get_future();    // is a std::future<int>

The future becomes ready once we call the task and the call completes. This is the ideal job for a separate thread. We just have to make sure to move the task into the thread:

std::thread thr(std::move(tsk), 1.5, 'x', false);

The thread starts running immediately. We can either detach it, or have join it at the end of the scope, or whenever (e.g. using Anthony Williams's scoped_thread wrapper, which really should be in the standard library). The details of using std::thread don't concern us here, though; just be sure to join or detach thr eventually. What matters is that whenever the function call finishes, our result is ready:

auto res = fut.get();  // as before

Now we're down to the lowest level: How would we implement the packaged task? This is where the std::promise comes in. The promise is the building block for communicating with a future. The principal steps are these:

As an example, here's our very own "packaged task":

template <typename> class my_task;

template <typename R, typename ...Args>
class my_task<R(Args...)>
{
    std::function<R(Args...)> fn;
    std::promise<R> pr;             // the promise of the result
public:
    template <typename ...Ts>
    explicit my_task(Ts &&... ts) : fn(std::forward<Ts>(ts)...) { }

    template <typename ...Ts>
    void operator()(Ts &&... ts)
    {
        pr.set_value(fn(std::forward<Ts>(ts)...));  // fulfill the promise
    }

    std::future<R> get_future() { return pr.get_future(); }

    // disable copy, default move
};

Usage of this template is essentially the same as that of std::packaged_task. Note that moving the entire task subsumes moving the promise. In more ad-hoc situations, one could also move a promise object explicitly into the new thread and make it a function argument of the thread function, but a task wrapper like the one above seems like a more flexible and less intrusive solution.

Promises are intimately related to exceptions. The interface of a promise alone is not enough to convey its state completely, so exceptions are thrown whenever an operation on a promise does not make sense. All exceptions are of type std::future_error, which derives from std::logic_error. First off, a description of some constraints:

Here is a little test series to demonstrate these various exceptional behaviours. First, the harness:

#include <iostream>
#include <future>
#include <exception>
#include <stdexcept>

int test();

int main()
{
    try
    {
        return test();
    }
    catch (std::future_error const & e)
    {
        std::cout << "Future error: " << e.what() << " / " << e.code() << std::endl;
    }
    catch (std::exception const & e)
    {
        std::cout << "Standard exception: " << e.what() << std::endl;
    }
    catch (...)
    {
        std::cout << "Unknown exception." << std::endl;
    }
}

The same exception is thrown if there is more than one of either of set_value or set_exception.

int test()
{
    std::promise<int> pr;
    auto fut = pr.get_future();

    {
        std::promise<int> pr2(std::move(pr));
    }   // Error: "broken promise"

    return fut.get();
}

You said "...which effectively synchronizes the program by waiting for the result.". What does "synchronizes" mean here? What does the entire statement mean? I'm unable to understand this. None of the meaning of "synchronize" from this dictionary entry helps me understand the sentence. Does just "waiting" mean "synchronization"? Does every wait synchronize? I think I partially understand what you mean, but I'm not sure what you actually mean.

Nice answer, thanks for your help.About the part of std::async, I remember that we could determine it would spawn another thread or work synchronous with flag(std::launch::async, std::launch::deferred)

@FelixDombek: Perfect forwarding etc. std::function has many constructors; no reason not to expose those to the consumer of my_task.

@DaveedV.: Thanks for the feedback! Yes, that is test case 7: If you destroy the promise without setting either value or exception, then calling get() on the future raises an exception. I will clarify this by adding "before it is destroyed"; please let me know if that's sufficiently clear.

Finally got() my future of grokking the thread support library on the promise of your amazing explanation!

c++ - What is std::promise? - Stack Overflow

c++ multithreading c++11 promise standard-library