Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » C / C++ (ANSI-Standard) » Partielle Template-Spezialisierung

Forum | Hilfe | Team | Links | Impressum | > Suche < | Mitglieder | Registrieren | Einloggen
  Quicklinks: MSDN-Online || STL || clib Reference Grundlagen || Literatur || E-Books || Zubehör || > F.A.Q. < || Downloads   

Autor Thread - Seiten: > 1 <
000
07.12.2004, 14:36 Uhr
(un)wissender
Niveauwart



C++:
#include <algorithm>
#include <iostream>
#include <iterator>
#include <cstddef>

typedef std::size_t o3int32;

template <class T_a, o3int32 T_dimension, class T_base>
class SAssignment {
  public:
    typedef T_base BaseType;
    typedef T_a ArgType;

    // SRecurse template
    template <o3int32 I>
    struct SRecurse {
      static void assign(BaseType& V, const ArgType& argument) {
        V[I] = argument.evaluate(I);
        SRecurse<I - 1>::assign(V, argument);
      }
    };

    // SRecurse template specialization (ending condition)
   //Hier kracht es beim g++
    template <>
    struct SRecurse<0> {
      static void assign(BaseType& V, const ArgType& argument) {
        V[0] = argument.evaluate(0);
      }
    };

    static void assign(BaseType& V, const ArgType& argument) {
      SRecurse<T_dimension - 1>::assign(V, argument);
    }

};

struct Evaluator {
  int evaluate(int x) const { return 42; }
};


int main() {
  int *test = new int[10];
  SAssignment<Evaluator, 10, int *>::assign(test, Evaluator());
  std::copy(test, test+10, std::ostream_iterator<int>(std::cout, " "));
  delete [] test;
}



Moin!

An alle die Ahnung vom Standard haben.
Obigen Code habe ich ungefähr so im Internet gefunden, der VS 2003 nimmt den sofort und erzeugt korrekten Code. Der g++ 3.4 und andere erzählen aber was von ungültiger Spezialisierung. Ist dies tatsächlich der Fall? Meiner Meinung ist er Code korrekt, allerdings kann es Probleme mit den Gültigkeitsbereichen geben, da bin ich mit nicht sicher.
--
Wer früher stirbt ist länger tot.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
001
07.12.2004, 14:56 Uhr
virtual
Sexiest Bit alive
(Operator)


Habe den Standard zwar grade nicht im Orginal zur Hand

Zitat:

[temp.expl.spec]

An explicit specialization shall be declared in the namespace of
which the template is a member, or, for member templates, in the
namespace of which the enclosing class or enclosing class
template is a member. An explicit specialization of a member
function, member class or static data member of a class template
shall be declared in the namespace of which the class template
is a member.



Für mich heißt das, daß du spezialisierungen eines genesteten Templates nur auf Namespace Level machen darfst. IMHO verhält sich der g++ da korrekt.
--
Gruß, virtual
Quote of the Month
Ich eß' nur was ein Gesicht hat (Creme 21)
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
002
07.12.2004, 14:58 Uhr
virtual
Sexiest Bit alive
(Operator)


Nachtrag, zur untermauerung
--
Gruß, virtual
Quote of the Month
Ich eß' nur was ein Gesicht hat (Creme 21)
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
003
07.12.2004, 15:29 Uhr
(un)wissender
Niveauwart


Erstmal dank, virtual.
Also, volle Spezialisierung ist nur im gleichen Gültigkeitbereich (Klassendefinition, namespace) erlaubt, aber die partielle Spezialisierung hat diese Beschränkung nicht.
Lösung ist also die Einführung eines Dummy-Template-Parameters.


C++:
#include <algorithm>
#include <iostream>
#include <iterator>
#include <cstddef>

typedef std::size_t o3int32;

template <class T_a, o3int32 T_dimension, class T_base>
class SAssignment {
  public:
    typedef T_base BaseType;
    typedef T_a ArgType;

    // SRecurse template

    template <o3int32 I, typename T = void>
    struct SRecurse {
      static void assign(BaseType& V, const ArgType& argument)
       {
        V[I] = argument.evaluate(I);
        SRecurse<I - 1>::assign(V, argument);
      }
    };

    // SRecurse template specialization (ending condition)
    template <typename T>
    struct SRecurse<0, T> {
      static void assign(BaseType& V, const ArgType& argument)
      {
       V[0] = argument.evaluate(0);
      }
    };


    static void assign(BaseType& V, const ArgType& argument) {
      SRecurse<T_dimension - 1>::assign(V, argument);
    }

};

struct Evaluator {
  int evaluate(int x) const { return 42; }
};


int main() {
  int *test = new int[10];
  SAssignment<Evaluator, 10, int *>::assign(test, Evaluator());
  std::copy(test, test+10, std::ostream_iterator<int>(std::cout, " "));
  delete [] test;
}



Ich erkenne nicht ganz den Sinn hinter dieser Regelung (C++ hat einige dieser seltsamen Sachen), manchmal frage ich mich, ob da immer viel nachgedacht wurde...
--
Wer früher stirbt ist länger tot.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
004
07.12.2004, 15:55 Uhr
virtual
Sexiest Bit alive
(Operator)



Zitat von (un)wissender:
Erstmal dank, virtual.
Ich erkenne nicht ganz den Sinn hinter dieser Regelung (C++ hat einige dieser seltsamen Sachen), manchmal frage ich mich, ob da immer viel nachgedacht wurde...

Ich glaube ich erwähnte schon meine Meinung dazu

Das Problem ist bei C++ halt ganz einfach, daß niemals ein sauberer Schlußstrich gegenüber C gezogen wurde und deshalb - anders als zB in Java - jede Menge Garbage mit rumgeschleppt wird.

Damit meine ich nicht allein die teilweise recht willkürlichen syntaktischen Gebilde, sondern eben auch der Stil, wie der Standard verfasst wurde, was er enthält und vor allem, was er nicht enthält.

Zwar mag die Nähe zu C in der Vergangenheit ein Pluspunkt gewesen sein, um die Akzeptanz bei C Puristen zu steigern, so ist es doch ein Verhängnis für C++, weil es so den Anschluß an die zukunft verlieren wird bzw. teilweise schon verloren hat.

Ich habe mir schon ernsthaft mal überlegt, aus den Zuckerstückchen von Java und C++ mal eine neue Sprache zu entwickeln. (Um die vermutliche Folgefrage/Unterstellung direkt zu beantworten: ich traue mir zwar zu, eine solche Sprache+Compiler zu entwickeln, habe aber keinerlei Ambitionen die Weltherrschaft zu übernehmen. Will sagen: wäre eher so eine Art Privatvergnügen ohne den Anspruch es wirklich besser zu machen als die Leute, die sich eigentlich damit auskennen. )
--
Gruß, virtual
Quote of the Month
Ich eß' nur was ein Gesicht hat (Creme 21)
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
005
07.12.2004, 19:13 Uhr
(un)wissender
Niveauwart


Nun, ich denke, diesse spezielle Problem hat nichts mit C-Kompatibilität zu tun.
Aber du hast schon recht, C++ benötigt einfach ein schlankeres und logischeres Design, das müssen die Standard-Leute mal einsehen und vor allem auch umsetzen.
Ob C++ den Anschluß verliert, weiß ich nicht, ich behaupte mal nein. Java ist eine gute Sprache, aber ihr fehlt im Vergleich zu C++ doch so einiges (const-Correctness, echte Templates, usw.). Aus C++ und Java eine Sprache der besten Stücke zu machen, fände ich wirklich eine gute Idee.
--
Wer früher stirbt ist länger tot.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
006
07.12.2004, 23:50 Uhr
virtual
Sexiest Bit alive
(Operator)



Zitat von (un)wissender:
Nun, ich denke, diesse spezielle Problem hat nichts mit C-Kompatibilität zu tun.

Da hast Du sicherlich recht, nur ist es eben die gleich schlampige Inkonsequenz die man bereits von einigen Punkten her kennt, die aus der C Syntax herrühren.


Zitat von (un)wissender:
Aber du hast schon recht, C++ benötigt einfach ein schlankeres und logischeres Design, das müssen die Standard-Leute mal einsehen und vor allem auch umsetzen.
Ob C++ den Anschluß verliert, weiß ich nicht, ich behaupte mal nein. Java ist eine gute Sprache, aber ihr fehlt im Vergleich zu C++ doch so einiges (const-Correctness, echte Templates, usw.).

Erst mal vorweg: weil Du sie in C++ als "echt" bezeichnest, werden sie in Java nicht "unecht". Sie sind dort eben einfach anders und verfolgen eine andere Zielrichtung

Ich denke halt, daß man rein vom theoretischen Standpunkt her sagen könnte, daß die zB Realisierung von Templates in C++ "schöner" sind. Man muß sich eben den Preis anschauen, den man dafür bereit ist zu zahlen. Mit Preis meine ich wirklich geld, denn Programmiersprachen müssen sich in der Praxis bewähren.

Beim Stichwort Wartung zB würde ich mal sagen, daß C++ deutlich schlechter als Java abschneidet. C++ bietet ein Mehrfaches an Fallstricken und benötigt ein Mehrfaches an Code als korrespondierende Java Programme. Wartung, das ist ein echtes Kostenproblem.

Ich würde ich mal behaupten, ist man mit einer Java basierten Produktentwicklung deutlich weniger Risikien und und Kosten ausgesetzt als mit einer C++ basierten Entwicklung. Diese Aussage bezieht sich natürlich nur auf Unternehmen, die eine solche Wahl haben, aber das sind eben viele. Aber wenn ich mir mal anschaue, was wir für einen Aparat hatten, als wir unsere Software noch in C++ hatten: Mehrere Entwicklungs und Testrechner für Windows, HP, AIX, Sun, Linux, DEC, Sinix, AS400 und wie sie alle heißen. Wenn Die wartung für den C++ Kram ausläuft, werden davon nicht mehr viele notwendig sein: vielleicht noch ein Rechner für jedes Betriebssystem und nicht mehr mindestens drei wie bisher.

Dann ist die "aus-einem-Guß-Stratgie" von Java ebenfalls nicht zu verachten: Klar, in C++ kann ich mir immer das bessere Toolkit aussuchen als die anderen. In Java nehm ich halt das was da ist. Na toll. Sagen wir die Entwicklungsmanschaft besteht aus 20 Leuten, davon geht pro Jahr einer raus und wird durch einen neuen ersetzt. Die Wahrscheinlichkeit, daß ich den C++ Freak auf ne Schulung schicken muß, (wahlweise weil er nur dachte, er könnte C++ [tun viele] oder weil er diese super Tolle Toolkit nicht kennt) ist erfahrungsgemäß um den Faktor 2-3 Mal höher als bei einem Java entwickler, der eben mit java eine leichtere Programmiersprache vor sich hat und bei dem es eine höhere Wahrscheinlichkeit gibt, daß er sich mit EJB oder JAAS mal auseinandergesetzt hat, weil es eben 0815 ist. Auch echte Kosten sowas.

Wir haben den Schwenk auf Java bereits zu mehr als 50% gemacht; alles neue wird in Java gemacht. Da bin ich auch keine Minute traurig drüber, ich war sogar einer derjenigen in der Firma, die das am meisten unterstützt haben. Und ich würde sagen: wir sind schneller und billiger geworden.

Mit anderen Worten: Programmiersprachen verschwinden nicht vom Markt weil sie "häßlich" sind oder bleiben auf den Markt weil sie "schön" sind. Über "schön" und "häßlich" kann man lange diskutieren. Über Geld nicht so sehr.
--
Gruß, virtual
Quote of the Month
Ich eß' nur was ein Gesicht hat (Creme 21)
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
007
08.12.2004, 06:48 Uhr
(un)wissender
Niveauwart


Keine Frage, Java ist recht einfach gehalten und damit prinzipiell wartbarer. Allerdings stimmt dieses "aus einem Guss" nicht uneingeschränkt, testen muss man trotzdem auf allen Zielsystem, nur viel weniger als in C++.
Allerdings hat die Programmierung mit C++ viel mit Disziplin zu tun. Wenn man mit Leuten zusammen programmiert, die alle sehr gutes C++ schreiben können (leider sehr selten) dann ist C++ mindestens so wartbar wie Java und von der Abstaktionseben sogar höher angesiedelt.
Die Sache mit den Bibos sehe ich als problemenatisch an, z.B. gibt es meines Wissens nach keine wirklich vernünftige GUI-Bibo, die auf allen Compilern läuft und Standard-C++ verwendet.
Wir werden sehen...


Zitat von virtual:

[...]schlampige Inkonsequenz[...]



Hart, aber fair.
Schon irgendwie traurig, das ganze.
--
Wer früher stirbt ist länger tot.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: > 1 <     [ C / C++ (ANSI-Standard) ]  


ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: