class A
{
  FIELD(char, 1)
  FIELD(int, 2)
  FIELD(float, 3)
};

// склейку токенов лучше брать готовую, чем голый оператор ## и потом удивляться правилам подстановки макроаргументов
#define FIELD_NAME(suffix)  BOOST_PP_CAT(field,suffix)
#define GETTER_NAME(suffix) BOOST_PP_CAT(get,suffix)

#define FIELD(type, suffix) \
  private: \
    type FIELD_NAME(suffix); \
  public: \
    type GETTER_NAME(suffix) const { return FIELD_NAME(suffix); } \

class A
{
public:
   struct InternalData
   {
      char field1;
      int field2;
      float field3;
   };

   const InternalData&  GetData() const { return data; }

private:
   InternalData  data;
};

   template<typename T>
   typename enable_if< has_key< mpl::set<AllowedAccessor1, AllowedAccessor2>, T>, const InternalData&>::type
      GetData() const { return data; }

DD>>Объявить поля public Или речь идет о создании только RO доступа?

Bjarne Stroustrup: Going to the big class hierarchy is again, you write more code than you need to, and you get too much connection between different parts. I particularly dislike classes with a lot of get and set functions. That is often an indication that it shouldn't have been a class in the first place. It's just a data structure. And if it really is a data structure, make it a data structure.
My rule of thumb is that you should have a real class with an interface and a hidden representation if and only if you can consider an invariant for the class.

Bill Venners: What do you mean by invariant?

Bjarne Stroustrup: What is it that makes the object a valid object? An invariant allows you to say when the object's representation is good and when it isn't. Take a vector as a very simple example. A vector knows that it has n elements. It has a pointer to n elements. The invariant is exactly that: the pointer points to something, and that something can hold n elements. If it holds n+1 or n-1 elements, that's a bug. If that pointer is zero, it's a bug, because it doesn't point to anything. That means it's a violation of an invariant. So you have to be able to state which objects make sense. Which are good and which are bad. And you can write the interfaces so that they maintain that invariant. That's one way of keeping track that your member functions are reasonable. It's also a way of keeping track of which operations need to be member functions. Operations that don't need to mess with the representation are better done outside the class. So that you get a clean, small interface that you can understand and maintain.

Bill Venners: So the invariant justifies the existence of a class, because the class takes the responsibility for maintaining the invariant.

Bjarne Stroustrup: That's right.

Bill Venners: The invariant is a relationship between different pieces of data in the class.

Bjarne Stroustrup: Yes. If every data can have any value, then it doesn't make much sense to have a class. Take a single data structure that has a name and an address. Any string is a good name, and any string is a good address. If that's what it is, it's a structure. Just call it a struct. Don't have anything private. Don't do anything silly like having a hidden name and address field with get_name and set_address and get_name and set_name functions. Or even worse, make a virtual base class with virtual get_name and set_name functions and so on, and override it with the one and only representation. That's just elaboration. It's not necessary.

class a{

char  field1; 
int   field2;
float field3;

public:

char  get1(){return field1;}
int   get2(){return field2;}
float get3(){return field3;}

//template<class T> T get(){return ???;}

};

template<class T>
auto get_1(T const& t) -> decltype(t.field_1)
{ return t.field_1; }

template<class Final> class define_getters
{
  auto get_1() const -> decltype(((Final*)this)->field_1)
  { return ((Final*)this)->field_1; }

  auto get_2() const -> decltype(((Final*)this)->field_2)
  { return ((Final*)this)->field_2; }

  // и т.д. - нагенерить макросами
};

class A : public define_getters<A>
{
  friend class define_getters<A>;
  int field_10;
};

#define DECLARE_FIELDS(seq) BOOST_PP_SEQ_FOR_EACH_I(DECLARE_NTH_FIELD, fake_data, seq)
#define DECLARE_NTH_FIELD(r, data, i, elem) DECLARE_FIELD(elem, i)

class A
{
  DECLARE_FIELDS( // синтаксис непривычный, зато не требует variadic macros
    (int)
    (float)
    (char)
  )
};

class A
{
  DECLARE_FIELDS(
    ((int))
    ((float)(foo)) // именованное поле
    ((char)(bar))
    ((long))
  )
// превратится в
public:
  typedef structure<int,float,char,long> fields;
  typedef int2type<2> foo;
  typedef int2type<3> bar;
private:
  fields m_fields;
public:
  template<int I>   typename fields::get_type<I       >::type get_i() const { return m_fields.get_value<I>(); }
  template<class T> typename fields::get_type<T::value>::type get_t() const { return m_fields.get_value<T::value>(); }
};

template<class T>
class b{
T val;
public:
b(T v):val(v){}
void get(T* v){*v=val;}
};

class a: public b<char>, public b<int>, public b<float> {
public:
a(char c,int i,float f):b<char>(c),b<int>(i),b<float>(f){}
};

main(){

a<char,int,float> aa(1,2,3);

char field1;
int field2;
float field3;
aa.get(&field1);
aa.get(&field2);
aa.get(&field3);
cout<<"\nfield1="<<(int)field1;
cout<<"\nfield2="<<field2;
cout<<"\nfield3="<<field3;
 
}

class a{

char  field1;
int   field2;
float field3;

public:

a(char c,int i,float f):field1(c),field2(i),field3(f){}

void get(char* v){*v=field1;}
void get(int* v){*v=field2;}
void get(float* v){*v=field3;}

};

int main(int argc,char* argv[]){

a aa(1,2,3);

char field1;
int field2;
float field3;
aa.get(&field1);
aa.get(&field2);
aa.get(&field3);
cout<<"\nfield1="<<(int)field1;
cout<<"\nfield2="<<field2;
cout<<"\nfield3="<<field3;

}

P>main(){

P>a<char,int,float> aa(1,2,3);

main(){

a aa(1,2,3);

template<class T1,class T2,class T3>
class a: public b<T1>, public b<T2>, public b<T3> {
public:
a(char c,int i,float f):b<T1>(c),b<T2>(i),b<T3>(f){}
};

typedef set<int, float> S;
S s(12, 5.5f);
std::cout << at_key<int>(s) << std::endl;
std::cout << at_key<float>(s) << std::endl;
std::cout << result_of::has_key<S, double>::value << std::endl;

using b<char>::get;
using b<int>::get;
using b<float>::get;

http://lib.ru/CPPHB/cpptut.txt

— Определяйте интерфейс так, чтобы открывать минимальное количество
требуемой информации:
- Используйте, всюду где это можно, частные данные и функции-члены.
— Используйте описания public или protected, чтобы отличить
запросы разработчика производных классов от запросов обычных
пользователей.

http://lib.web-malina.com/getbook.php?bid=4536&page=5

Правила Правой Руки (*)

Здесь приводится набор правил, которых вам хорошо бы
придерживаться изучая C++. Когда вы станете более опытны, вы можете
превратить их в то, что будет подходить для вашего рода
деятельности и вашего стиля программирования. Они умышленно сделаны
очень простыми, поэтому подробности в них опущены. Не воспринимайте
их чересчур буквально. Написание хороших программ требует ума,
вкуса и терпения. Вы не собираетесь как следует понять это с самого
начала; поэкспериментируйте!
[1] Когда вы программируете, вы создаете конкретное
представление идей вашего решения некоторой задачи. Пусть
структура отражает эти идеи настолько явно, насколько это
возможно:
[1] Если вы считате "это" отдельным понятием, сделайте его
классом.

____________________
(*) Некоторые легко запоминаемые эмпирические правила, "Правила-
помошники." (прим. перев.)

— стр 18 —

[2] Если вы считате "это" отдельным объектом, сделайте его
объектом некоторого класса.
[3] Если два класса имеют общим нечто существенное, сделайте
его базовым классом. Почти все классы в вашей программе
будут иметь нечто общее; заведите (почти) универсальный
базовый класс, и разработайте его наиболее тщательно.
[2] Когда вы определяете класс, который не реализует
некоторый математический объект, вроде матрицы или
комплексного числа, или тип низкого уровня, вроде связанного
списка, то:
[1] Не используйте глобальные данные.
[2] Не используйте глобальные функции (не члены).
[3] Не используйте открытые данные-члены.
[4] Не используйте друзей, кроме как чтобы избежать [a], [b]
или [c].
[5] Не обращайтесь к данным-членам или другим объектам
непосредственно.
[6] Не помещайте в класс "поле типа"; используйте виртуальные
функции.
[7] Не используйте inline-функции, кроме как средство
существенной оптимизации.

class Foo
{
public:
    char  field1;
    int   field2;
    float field3;
public:
    template<typename T, typename F>
    T get(T F::*field) const
    {
        return this->*field;
    }
};

std::cout << foo.get(&Foo::field1) << std::endl;

const char Foo::*field1 = &Foo::field1;

std::cout << foo.get(field1) << std::endl;

    template<typename T, typename F>
    T* get1(T F::*field) 
    {
        return &(this->*field);
    }

template<typename T, typename F>
const T& get(T F::*field) const
{
    return this->*field;
}

template<typename T, typename F>
void get(F field, T& result) const
{
    result = this->*field;
}

template<typename T>class CFieldWithGetter {
public:
    CFieldWithGetter();
//    CFieldWithGetter( const CFieldWithGetter& other ) : body( other.body ) {}
    template<typename T1>
    CFieldWithGetter( const T1& a1 ) : body( a1 ) {}
    template<typename T1, typename T2>
    CFieldWithGetter( const T1& a1, const T2& a2 ) : body( a1, a2 ) {}
    //  и т. д.

    void swap( T& other ) { std::swap( body, other ); }
    void swap( CFieldWithGetter& other ) { std::swap( body, other.body ); }

    // В принципе вместо этого можено сеттер написать
    void opearator = ( const T& other ) { body = other; }
    void opearator = ( const CFieldWithGetter& other ) { body = other.body; }

    //  Внимание!!! Всё ради этого!!!
    const T& Get() const { return body; }
private:
    T body;
};

struct MyData {
    CFieldWithGetter<int> field_1;
    CFieldWithGetter<char> field_1;
    CFieldWithGetter<std::string> field_1;
};

10.2.8 Structures and Classes [class.struct]
...
Which style you use depends on circumstances and taste. I usually prefer to use struct for classes
that have all data public. I think of such classes as ‘‘not quite proper types, just data structures.’’

10.5 Advice [class.advice]
Use public data (structs) only when it really is just data and no invariant is meaningful for the
data members; §10.2.8.