folgendes Szenario:
Es gibt eine Hierarchie von (Aufgaben-)Klassen, deren Konstruktoren eine große Anzahl von Parametern brauchen, von denen aber viele optional sein können.
Klassen weiter unten in der Ableitungshierarchie brauchen immer die Parameter der Basisklasse(n) und noch ein paar mehr.

Idee:
Die Parameter werden in eine andere (Parameter-)Klasse verpackt. Von dieser Parameter-Klasse wird dann ein Objekt an den Konstruktor der Aufgaben-Klassen übergeben. Damit erspart man sich Konstruktoren mit zig Parametern und Konstruktoren mit endlosen Parameterkombinationen.
Um Code-Duplikation zu vermeiden, wäre es hilfreich, wenn man die Parameter-Klassen parallel zu den Aufgaben-Klassen in einer eigenen Hierarchie erweitern könnte.
Außerdem sollten die Named Parameters in einer Fluent-Syntax geschrieben werden können.

Vereinfacht ungefähr so:

#include <string>
#include <iostream>

struct t_base_params
{
   t_base_params& set_i( int p_i )
   {
      m_i = p_i;
      return( *this );
   }

   t_base_params& set_d( double p_d )
   {
      m_d = p_d;
      return( *this );
   }

   t_base_params& set_s( const std::string& p_s )
   {
      m_s = p_s;
      return( *this );
   }

   int m_i;
   double m_d;
   std::string m_s;
};

class t_base
{
public:
   t_base( const t_base_params& p_params )
   {
      std::cout << p_params.m_i << std::endl;
      std::cout << p_params.m_d << std::endl;
      std::cout << p_params.m_s << std::endl;
   }
};

struct t_derived_0_params: public t_base_params
{
   t_derived_0_params& set_c( char p_c )
   {
      m_c = p_c;
      return( *this );
   }

   char m_c;
};

class t_derived_0: public t_base
{
public:
   t_derived_0( const t_derived_0_params& p_params ):
      t_base( p_params )
   {
      std::cout << p_params.m_i << std::endl;
      std::cout << p_params.m_d << std::endl;
      std::cout << p_params.m_s << std::endl;
      std::cout << p_params.m_c << std::endl;
   }
};

int main()
{
   t_base base_0( t_base_params().set_s( "Hallo" ).set_d( 18.87 ).set_i( 33 ) );
   t_derived_0 derived_0_0 ( t_derived_0_params().set_d( 123.456) .set_c( 'x' ) );

   std::string dummy;
   std::cin >> dummy;
}

Das funktioniert so leider nicht, da die Methoden aus der Basisklasse immer noch Referenzen auf ein Basisklassenobjekt liefern.
Und ich möchte die Methoden nicht virtuell machen und überschreiben, sonst habe ich ja trotzdem die Code-Verdopplung.
Was ich eigentlich bräuchte, wäre eine Methode, die immer den Typ der aktuellen Klasse zurück gibt.
Template ginge auch, wenn man den Rückgabetyp als Parameter angibt, aber dann wird der Aufruf sehr unschön.

Diese Lösung geht - aber elegant ist anders:

#include <string>
#include <iostream>

template< class t_return >
struct t_base_params
{
   t_base_params():
      m_i( 0 ),
      m_d( 0.0 ),
      m_s( "" )
   {
   }

   template< class t_source >
   t_base_params( const t_source& t_rhs ):
      m_i( t_rhs.m_i ),
      m_d( t_rhs.m_d ),
      m_s( t_rhs.m_s )
   {
   }

   t_return& set_i( int p_i )
   {
      m_i = p_i;
      return( me() );
   }

   t_return& set_d( double p_d )
   {
      m_d = p_d;
      return( me() );
   }

   t_return& set_s( const std::string& p_s )
   {
      m_s = p_s;
      return( me() );
   }

   int m_i;
   double m_d;
   std::string m_s;

protected:
   t_return& me()
   {
      return( static_cast< t_return& >( *this ) );
   }
};

class t_base
{
public:
   struct t_params: public t_base_params< t_params >
   {
      t_params():
         t_base_params< t_params >()
      {
      }

      t_params( const t_base_params< t_params >& t_rhs ):
         t_base_params< t_params >( t_rhs )
      {
      }
   };

   t_base( const t_params& p_params = t_params() )
   {
      std::cout << p_params.m_i << std::endl;
      std::cout << p_params.m_d << std::endl;
      std::cout << p_params.m_s << std::endl;
   }
};

template< typename t_return >
struct t_derived_0_params: public t_base_params< t_return >
{
   t_return& set_c( char p_c )
   {
      m_c = p_c;
      return( me() );
   }

   char m_c;
};

class t_derived_0: public t_base
{
public:
   struct t_params: public t_derived_0_params< t_params >
   {
      t_params():
         t_derived_0_params< t_params >()
      {
      }

      t_params( const t_derived_0_params< t_params >& t_rhs ):
         t_derived_0_params< t_params >( t_rhs )
      {
      }
   };

   t_derived_0( const t_params& p_params ):
      t_base()
   {
      std::cout << p_params.m_i << std::endl;
      std::cout << p_params.m_d << std::endl;
      std::cout << p_params.m_s << std::endl;
      std::cout << p_params.m_c << std::endl;
   }
};

int main()
{
   t_base base_0( t_base::t_params().set_s( "Hallo" ).set_d( 18.87 ).set_i( 33 ) );
   t_derived_0 derived_0_0 ( t_derived_0::t_params().set_d( 123.456) .set_c( 'x' ) );

   std::string dummy;
   std::cin >> dummy;
}

Gibt es eine sinnvolle und elegante Lösung für dieses Problem?

struct base
{
	int m_i;
};

struct derived : base
{
	double m_d;
};

Zuerst schreiben wir ein paar Attribut-Klassen, um den Objekten einen Wert zuzuweisen:

struct attribute_i
{
    explicit attribute_i(int i)
    : m_i(i)
    {
    }

    template <typename T>
    void modify(T& target) const
    {
       target.m_i = m_i;
    }

    int m_i;
};

// Analog für andere wie attribute_d. Wenn es zu viel Code wird, 
// verwende Makros

Um eine schöne Syntax zu ermöglichen, überladen wir den operator<< . Dabei habe ich std::enable_if verwendet, damit der Operator nicht für sämtliche Argumenttypen im Namensraum herangezogen wird.

#include <type_traits>

template <typename T, typename A>
typename std::enable_if<std::is_base_of<base, T>::value, T&>::type operator<< (T& target, A attribute)
{
    attribute.modify(target);
    return target;
}

Anwendung:

int main()
{
	base b;
	b << attribute_i(2);

	derived d;
	d << attribute_i(3) << attribute_d(4.5);
}

dot schrieb:

Ich würd mir an deiner Stelle zuerst mal überlegen, ob die große Anzahl an Parametern in deinen Konstrukturen nicht vielleicht ein Hinweis sein könnte, dass deine Klasse zuviel tut und diese Klasse daher möglicherweise vielleicht eigentlich mehrere Klassen sein sollte...

Bei den Klassen handelt es sich um Teile eines Abstraktions-Layers für verschiedene (z.T. alte) UI-Frameworks und da werden viele und viele verschiedene Parameter gesetzt. Daran läßt sich erst einmal wenig ändern.

@Nexus:
Danke für den interessanten Ansatz. Den werde ich genauer anschauen!

http://img4.fotos-hochladen.net/uploads/void666tujm5byvnr.png
*angst hab*

Der Teufel benutzt void* Zeiger? Interessant... der Code ist bestimmt die Hölle

dot schrieb:

Ich würd mir an deiner Stelle zuerst mal überlegen, ob die große Anzahl an Parametern in deinen Konstrukturen nicht vielleicht ein Hinweis sein könnte, dass deine Klasse zuviel tut und diese Klasse daher möglicherweise vielleicht eigentlich mehrere Klassen sein sollte...

Bei den Klassen handelt es sich um Teile eines Abstraktions-Layers für verschiedene (z.T. alte) UI-Frameworks und da werden viele und viele verschiedene Parameter gesetzt. Daran läßt sich erst einmal wenig ändern.

hmmm

void* schrieb:

dot schrieb:

Ich würd mir an deiner Stelle zuerst mal überlegen, ob die große Anzahl an Parametern in deinen Konstrukturen nicht vielleicht ein Hinweis sein könnte, dass deine Klasse zuviel tut und diese Klasse daher möglicherweise vielleicht eigentlich mehrere Klassen sein sollte...

Bei den Klassen handelt es sich um Teile eines Abstraktions-Layers für verschiedene (z.T. alte) UI-Frameworks und da werden viele und viele verschiedene Parameter gesetzt. Daran läßt sich erst einmal wenig ändern.

hmmm

Hmmm?

Gemeint sind Parameter wie Größe, Position, Farben, Fonts, Initialisierungswerte für den Inhalt von Steuerelementen (Texte), Beschriftungen, ... eben die diversen Properties, die für ein Widget gesetzt werden können. Und da der Code teilweise 20 Jahre auf dem Buckel hat, viele Entwickler dran rumgeschraubt haben, von Unix auf Windows portiert wurde und sonst einiges mitgemacht hat, ist die Benutzung der Grundlagenbibliotheken eben etwas inhomogen.
Und mit viele verschiedene Parameter ist eben gemeint, dass z.B. bei einer Combo-Box mal 7 Werte gesetzt werden und einmal 9, wovon 5 gleich sind wie beim ersten Aufruf und 4 eben anders.

dot schrieb:

void* schrieb:

dot schrieb:

Ich würd mir an deiner Stelle zuerst mal überlegen, ob die große Anzahl an Parametern in deinen Konstrukturen nicht vielleicht ein Hinweis sein könnte, dass deine Klasse zuviel tut und diese Klasse daher möglicherweise vielleicht eigentlich mehrere Klassen sein sollte...

Bei den Klassen handelt es sich um Teile eines Abstraktions-Layers für verschiedene (z.T. alte) UI-Frameworks und da werden viele und viele verschiedene Parameter gesetzt. Daran läßt sich erst einmal wenig ändern.

hmmm

Hmmm?

Gemeint sind Parameter wie Größe, Position, Farben, Fonts, Initialisierungswerte für den Inhalt von Steuerelementen (Texte), Beschriftungen, ... eben die diversen Properties, die für ein Widget gesetzt werden können.

Und da liegt der Hund begraben. Muss das alles in eine Klasse? Kann das nicht in Datenstrukturen unterteilt werden? Das ist eben unschönes Design...