Diskussion:C++-Metaprogrammierung

Autorenverlinkung bei den Literaturempfehlungen

IMHO sollten nur wichtige und bekannte Autoren zu einem Wikipedia-Artikel verlinkt werden; vor allem, wenn die Artikel noch gar nicht existieren, halte ich das pauschale Verlinken für überflüssig. Leider kann ich nicht entscheiden, welche Autoren "bekannt" sind und welche nicht. --Christoph 00:08, 26. Mai 2005 (CEST)

Nette Spielerei - Theoriefindung?

Die C++-Metaprogrammierung ist eine nette Spielerei - mehr imo aber auch nicht. Variablen z.B. sind als Template-Parameter nicht erlaubt. Es geht nur darum, den Compiler für die Berechnung zu misbrauchen. Das funktioniert nur, wenn die Parameter zur Compile-Zeit bekannt sind. Folgendes Beispiel funktioniert *nicht*:

 #include <iostream>
  
 template<long B,unsigned long E>
 struct pow_helper {
   static const double value;
 };
 template<long B,unsigned long E>
 const double pow_helper<B,E>::value=B*pow_helper<B,E-1>::value;
  
 template<long B>
 struct pow_helper<B,0> {
   static const double value;
 };
 template<long B>
 const double pow_helper<B,0>::value=1;
  
 template<long B,long E>
 struct power {
    static const double value;
 };
 template<long B,long E>
 const double power<B,E>::value= E<0 ? 1.0/pow_helper<B,E<0 ? -E : E>::value :
 pow_helper<B,E<0 ? -E : E>::value;
  
 int main() {
   for (int i = 1; i < 20; i++) {
       std::cout << power<2,i>::value << std::endl;
   }
 }

Außerdem drängt sich mir der Verdacht auf, dass es sich hierbei um Theoriefindung, nicht um Theoriedarstellung handelt. Das wäre ein potentieller Löschgrund.--ChristianHujer 23:51, 18. Mär 2006 (CET)

Sehe ich anders: Die Bibliothek boost::spirit etwa benutzt ausgiebig Template-Metaprogrammierung. spirit erlaubt dem Benutzer, eine Grammatik in Pseudo-EBNF-Notation direkt im C++-Code anzugeben; diese wird dann u.a. per Template-Metaprogrammierung in einen passenden Parser umgewandelt. Zu welchem Anteil genau Metaprogrammierung bei dieser Bibliothek eine Rolle spielt, weiß ich nur ungefähr, da ich mir den spirit-Quellcode nicht angesehen habe. Diese Bibliothek habe ich aber z.B. bereits erfolgreich in einem kleineren Projekt eingesetzt, es handelt sich also um mehr als eine theoretische Spielerei.

In boost lassen sich bestimmt weitere, bessere Beispiele finden.

Nachtrag: Beispielsweise boost::staticassert würde ohne Template-Metaprogrammierung nicht so elegant funktionieren. boost::typetraits überhaupt nicht. Allerdings habe ich diese Bibliotheken im Gegensatz zu spirit noch nie eingesetzt. --Christoph 12:03, 19. Mär 2006 (CET)

Nachtrag 2: Zur Signifikanz von boost: Teile von boost werden voraussichtlich in den kommenden C++-Standard einfließen (s. boost.org-Hauptseite); zwar nicht unbedingt boost::spirit, dennoch spricht diese Tatsache dafür, dass Boost mehr ist als eine kleine Bibliothek, die eine nette Spielerei darstellt. --Christoph 12:09, 19. Mär 2006 (CET)

Ich sag nicht, boost sei Spielerei. Ich sage, Metaprogrammierung mit Templates ist es. Ich behaupte, mal man versucht dadurch, C++ deklarative Programmierung einzuhauchen - eher schlecht als recht mangels Laufzeitparametrisierbarkeit. Und zu Spirit - naja, haut mich nun nicht wirklich vom Hocker. Zum static assert - wäre es nicht besser, assert wäre ein Schlüsselwort, sodass man schreiben könnte "static assert expr;" mit expr als Ausdruck, der zur Übersetzungszeit vollständig evaluierbar sein muss? Einerseits ist es zwar gut, dass die Syntax von C++ es erlaubt, solche fehlenden Syntaxelemente mit Krücken nachzubilden. Andererseits leidet die ohnehin teilweise schlechte Maintainability von C++-Programmen darunter noch zusätzlich. Und die Compilerfehlermeldung beim static assert mit Template ist auch nur deshalb verständlich, weil das Symbol verständlich ist. Um das klar zu stellen: Ich bin für assertions. Ich stelle nur die Sinnhaftigkeit des Misbrauchs von Templates zur Metaprogrammierung in Frage. Besser wäre es, man würde C++ um deklarative Sprachelemente erweitern ähnlich Prolog.--ChristianHujer 12:55, 19. Mär 2006 (CET)

Template-Metaprogrammierung ist sehr interessant im Zusammenhang mit Codegenerierung. Spirit führt es ja vor. Kann natürlich sein das du Spirit nicht sinnvoll findest. Aber es zeigt eine praktische Benutzung von Template-Metaprogrammierung. --Kingruedi 14:42, 19. Mär 2006 (CET)

Niemand wird ernsthaft behaupten, dass die aktuelle C++-Syntax toll ist, aber was anderes gibt es halt nicht (nein, Codegeneratoren sind keine Alternative). Die Tatsache, dass man mit Metaprogrammierung Dinge wie static asserts nachbilden kann, ohne die Sprache aufzufetten, ist ein ganz klares Plus. C++0x wird viele Neuerungen beinhalten, die u.a. Metaprogrammierung und generische Programmierung deutlich erleichtern sollen.--80.121.21.79 00:27, 26. Nov. 2007 (CET)

Mit variadischen Templates bekommen Typlisten syntaktischen Zucker, wirklich einfacher werden sie aber nicht. Eine umfassende Introspection/Reflection zur Kompilierzeit wäre beispielsweise genial. Oder die Template-Instantiierung über externe Quellcode-Erzeuger/normalen C++-Code als alternative zur funktionalen Programmierung.--Chricho 13:09, 18. Jul. 2009 (CEST)

Siehe "C++ Template Metaprogramming" 1.4.2: "By the time we are through, you'll probably think of template metaprogramming as 'computing with types'". Das man dabei auch 'values' auf 'types' abbilden kann ist nur eine Variante - und zwar eine interessante. Es geht hier darum, eine 'borderline' zwischen Kompilation und Ausführung auszumachen und ggf. zu sehen, wieweit sie in die eine oder andere Richtung verschoben werden kann. Und das finde ich allemal interessant genug, um sich damit auseinanderzusetzen. [ Frank B. ]

Das Ganze ist nicht mehr als eine Spielerei. Schon immer neigen gewisse Kreise dazu das letzte aus gewissen Sprachen das letzte heraus zu kitzeln. Die Welt besteht aber nicht nur aus Nerds, sondern zu 95% aus normalen Programmierern und denen ist das eine Latte zu hoch. Auch wenn es funktioniert - das Ganze ist nicht wartbar. Es ist nicht sofort erkennbar, was der Code macht und wenn ein Fehler auftritt -debug das Ganze einmal! Es gibt ganz wenige Anwendungsbereiche, wo eine solche Metaprogrammierung Sinn macht - Parserbau ist eine davon. Es ist aber nicht für die normale Programmierung geeignet und das sollte mehr herausgearbeitet werden. 84.170.120.5 17:06, 7. Mai 2010 (CEST)

Ob jemand der Diskutanten hier C++-Metaprogrammierung toll/sinnvoll/elegant/interessant findet oder nicht, spielt keine Rolle für die Relevanz des Themas. Relevant ist es, da es, da C++-Metaprogrammierung zum einen, weil sie Eingang in die wissenschaftl. Forschung (Compilerbau, Programmiersprachen-Design etc.) gefunden hat – siehe Literaturliste – und zum anderen, weil sie in den genannten und verlinkten Bibliotheken auch praktisch genutzt wird. --RokerHRO 14:24, 10. Nov. 2011 (CET)

Metaprogrammierung mittels C- Makros

"Es gibt aber auch Metaprogrammierung mittels C-Makros"

So stehts im Artikel. Kann das denn jemand bestätigen? Ich habe im Internet nichts darüber gefunden... Auch ist es AFAIK nicht möglich rekursive C Makros zu definieren, wodurch die Metaprogrammierung mit Hilfe von C- Makros schon arg eingeschränkt wäre, falls es sowas wirklich geben sollte. Gruß--Demoncleaner 23:37, 13. Aug 2006 (CEST)

Beispiel "power" vereinfachen?

Ohne dass ich jemanden angreifen möchte, aber der Beispiel-Code ist nicht ganz koscher w.r.t. Kompilierzeit-Auswertung:

 template<long B, unsigned long E>
 struct pow_helper {
   static long const value = B * pow_helper<B, E - 1>::value;
 };

static long const: Warum kein enum? Eine statische Membervariable kann ganz schnell "aus versehen" ein lvalue werden (siehe nächsten Punkt) und nimmt wahrscheinlich Speicherplatz im Kompilat in Anspruch. (siehe auch Vandevoorde/Josuttis)

 template<long B, long E>
 struct power {
    static double const value;
 };

static const double: Und schon haben wir einen L-Value, der evtl. erst zur Laufzeit ausgewertet wird. Außerdem lässt sich power::value nicht als Argument für andere templates verwenden (in meinen Augen das Killer-Argument gegen das Vorhandene, da sich das Template dadurch nicht innerhalb der C++-Metaprogrammierung verwenden lässt). Ich denke, wir sollten darauf verzichten bis der Standard es richtet.

Nachtrag: Natürlich lassen sich Fließkommaberechnungen innerhalb der Template-Meta-Programmierung durchführen, aber nicht mit builtin-Typen. Thierry Berger-Perrin hat hierzu das IEEE-konforme "Metafloat" veröffentlicht.

 template<long B, long E>
 double const power<B, E>::value= E < 0 ? 1.0 / pow_helper<B, E < 0 ? -E : 0>::value
                                        : pow_helper<B, E < 0 ? 0 : E>::value;

Hier wird der Compiler versuchen, ingesamt vier Verzweigungen { ? (?1:2) : (?3:4) } auszuwerten, nur für die erste Rekursion. Der ternäre Operator sollte niemals in dieser Weise verwendet werden. Ich weiß, er wird benötigt, da double-Werte nicht als Parameter verwendet werden können, und somit keine negativen Exponenten erlaubt sind, aber er macht aus einem linear komplexem Konstrukt ein exponentielles.

Ich schlage vor, wir ersetzen das Konstrukt durch eine einfache, KISS-konforme Lösung, die auch vom Anfänger begriffen werden kann. Man könnte dann einen Hinweis auf die Fließkomma-Problematik im Text platzieren.

Mein Vorschlag:

 // static_pow.h
 template <int BASE, unsigned int EXP> struct pow {
     enum { value = BASE * pow<BASE, EXP-1>::value };
 };

 template <int BASE> struct pow<BASE, 0> {
     enum { value = 1 };
 };


 // main.h
 #include <iostream>
 int main () {
    // Tests for base 2.
    ::std::cout << "2^0 = " << pow<2,0>::value << '\n';
    ::std::cout << "2^1 = " << pow<2,1>::value << '\n';
    ::std::cout << "2^2 = " << pow<2,2>::value << '\n';
    ::std::cout << "2^3 = " << pow<2,3>::value << '\n';
    ::std::cout << "2^16 = " << pow<2,16>::value << '\n';

    ::std::cout << "-2^0 = " << pow<-2,0>::value << '\n';
    ::std::cout << "-2^1 = " << pow<-2,1>::value << '\n';
    ::std::cout << "-2^2 = " << pow<-2,2>::value << '\n';
    ::std::cout << "-2^3 = " << pow<-2,3>::value << '\n';
    ::std::cout << "-2^16 = " << pow<-2,16>::value << '\n';
 }

Phresnel 10:52, 17. Feb. 2009 (CET)

Gute Idee. Make it so! :-) --RokerHRO 14:26, 10. Nov. 2011 (CET)

Typlisten!

Auf jeden Fall müssen Typlisten erwähnt werden. In der deutschsprachigen Wikipedia wird dieses mächtige Konzept in keinem Satz erwähnt. Nach dem Urlaub füge ich es eventuell hinzu. --Chricho 12:56, 18. Jul. 2009 (CEST)

Hm, schade, dass dein Urlaub so lange geht. Oder hast du es inzwischen vergessen oder die Lust verloren? --RokerHRO 14:27, 10. Nov. 2011 (CET)

Ähnlichkeit zu Haskell ansprechen?

C++-Templates ähneln sehr stark puren Haskell-Funktionen, nur eben zur Kompilierzeit. Man kann ja einmal vergleichen:
Haskell: eql-Specializers
C++: Template-Spezialisierung
Haskell: Elementare Rechenoperationen und Typen
C++: Genau das selbe
Haskell: Arrays und Listen
C++: (Typ-)listen (Listen von Nicht-Typen sind selbstverständlich auch möglich)
Haskell: Starke und statische Typisierung
C++: Überwiegend starke und statische Typisierung (implizite Umwandlungen nur zwischen integrierten Typen)
Haskell: Keine Seiteneffekte
C++: Keine Seiteneffekte

So viel Ähnlichkeit verdient doch einen kurzen Satz zu Beginn bei der funktionalen Programmierung. Gegen diese funktionale Programmierung habe ich ja nichts, nur schade, dass sich diese Struktur in der Instantiierung wieder findet. Typ-Listen lassen sich leider nicht linearisieren und man kann dann nur noch auf einen guten Optimierer hoffen, der dämliche if-Abfragen und Aufrufe verschiedener Funktions-Template-Instantiierungen auflöst. --Chricho 13:06, 18. Jul. 2009 (CEST)

Mir fällt gerade auf, was ich da für einen Schwachsinn geschrieben habe. Ist halt eine rein funktionale Programmiersprache, da muss man sie ja nicht gleich mit allen anderen vergleichen. --Chricho 12:47, 5. Feb. 2010 (CET)

Generalüberholung des Artikels

Habe den Artikel generalüberholt. Gehe auf die Details in Kürze näher ein. Bitte mitdiskutieren und keinen Editwar starten. --Casu17 (Diskussion) 16:45, 17. Mär. 2012 (CET)

Wollte nur einige alten Abschnitte vorerst wieder hineinpacken und die Schreibweise „Templatemetaprogrammierung“ wieder einfügen, weil ich nicht sehe, wieso man dort einen Bindestrich benutzen sollte. --Chricho ¹ ² 16:48, 17. Mär. 2012 (CET)

Was man auf jeden Fall verbessern sollte: Bei der Berechnung konstanter Ausdrücke und statischen Assertions handelt es sich nicht an sich um Metaprogrammierung, sie dienen eher als Hilfsmittel zu dieser. Es sollte mehr herausgestrichen werden, was Metaprogrammierung in C++ ausmacht, im Moment konzentriert der Artikel sich viel zu sehr auf Berechnungen zur Compilezeit und nicht auf Metaprogrammierung. Zudem habe ich das Beispiel jetzt noch gekürzt, das mit den negativen Exponenten ist hier völlig irrelevant. --Chricho ¹ ² 16:53, 17. Mär. 2012 (CET)

Die Schreibweise ohne Bindestrich geht von mir aus ok. Ich wollte damit nur die Lesbarkeit verbessern. So wichtig ist es aber auch wieder nicht. --Casu17 (Diskussion) 16:54, 17. Mär. 2012 (CET)

Ganz deiner Meinung bezüglich der negativen Exponenten. Die machen das Beispiel nur unnötig kompliziert. Habe das Beispiel nochmals vereinfacht. --Casu17 (Diskussion) 17:06, 17. Mär. 2012 (CET)

Abgrenzung "Metaprogrammierung"/"Berechnungen zur Compilezeit"

Meiner Meinung nach gibt es dazwischen keinen Unterschied. Siehe auch Einleitung. Hast du Belege für deine Vermutung? --Casu17 (Diskussion) 17:11, 17. Mär. 2012 (CET)

Sicher. Schau dir Metaprogrammierung an. Das Entscheidende bei dieser ist die Möglichkeit, Programmstrukturen erzeugen zu können, ob Compile- oder Laufzeit spielt gar nicht mal eine Rolle, bei vielen Lisp-Dialekten etwa ist das nicht getrennt. Über constexpr ist an sich keine Metaprogrammierung möglich, das Vorausberechnen von eine paar Werten ist keine Metaprogrammierung. Das Potenz-Beispiel ist sinnvoll, weil daran sichtbar wird, dass hier eine zumindest im Sinne der Berechenbarkeit vollständige Programmiersprache zur Metaprogrammierung vorliegt. Und solche Konstrukte können natürlich der Metaprogrammierung dienen, ebenso wie constexpr, das gerade zur Vereinfachung solcher eingeführt wurde, sie machen aber nicht die Metaprogrammierung aus. --Chricho ¹ ² 17:17, 17. Mär. 2012 (CET)

Werte gehören auch zum Programmcode. --Casu17 (Diskussion) 17:33, 17. Mär. 2012 (CET)

Na, dann wäre ja jegliche Form von Programmierung Metaprogrammierung. Der Wert, den der Benutzer für seinen Namen eingegeben hat, bestimmt ja auch, was der Code dann macht. Naja, laut en:Meta programming wird das Wort auch für die Berechnung von Sachen zur Compilezeit verwandt, da sollte man sich nochmal nach einer ordentlichen Quelle umschauen. Wenn diese Doppelbelegung hier auch verwendet werden soll, dann muss das zumindest klar dargestellt werden. --Chricho ¹ ² 17:42, 17. Mär. 2012 (CET)

Entscheidend ist meiner Meinung nach, dass Code von Code erzeugt wird (was beim Benutzernamen nicht der Fall ist). Bei 1+1 könnte man also im weitesten Sinne auch von Metaprogrammierung sprechen. Bei Konstrukten mit constexpr ist der erzeugende Code darüber hinaus isolierbar und dadurch wiederverwendbar. Außerdem ist der erzeugende Code parametrierbar. --Casu17 (Diskussion) 17:58, 17. Mär. 2012 (CET)

Dann halt nicht der Benutzername sondern eine große Tabelle von Primzahlen oder sowas. ;) --Chricho ¹ ² 18:03, 17. Mär. 2012 (CET)

Eine Tabelle ist kein Programmcode. --Casu17 (Diskussion) 19:31, 17. Mär. 2012 (CET)

Und wenn const und constexpr davor steht, ist es Programmcode? Und der Compiler wird dann auch nichts anderes machen, als eine Tabelle in der Objekt-Datei anzulegen in dem entsprechenden Format. --Chricho ¹ ² 01:29, 18. Mär. 2012 (CET)

Konstante Ausdrücke

Konstante Ausdrücke waren schon vor C++11 definiert, etwa war 1+1 schon immer ein konstanter Ausdruck, weshalb man ihn als Templateparameter benutzen durfte. C++11 führt nun eine neue Art konstanter Ausdrücke ein: Aufrufe von als constexpr markierten Funktionen mit konstanten Ausdrücken als Parametern. Siehe zur Wortverwendung etwa [1], dort wird definiert, was ein konstanter Ausdruck sein soll. --Chricho ¹ ² 17:28, 17. Mär. 2012 (CET)

Ja. Aber das habe ich doch geschrieben. --Casu17 (Diskussion) 17:33, 17. Mär. 2012 (CET)

Verzeihung, falsch gelesen, ich probiers nochmal. --Chricho ¹ ² 17:38, 17. Mär. 2012 (CET)

Zufrieden? --Chricho ¹ ² 17:44, 17. Mär. 2012 (CET)

Schon besser. Wenigstens steht nicht mehr das Schlüsselwort im Mittelpunkt. Das ist nämlich völlig nebensächlich. Während der Entwicklung dieser Spracherweiterung wurden auch Varianten diskutiert, die ohne ein neues Schlüsselwort auskommen. --Casu17 (Diskussion) 17:47, 17. Mär. 2012 (CET)

Ja, du hast vollkommen Recht, das das nebensächlich ist, mir war einfach nichts besseres eingefallen, um zu vermeiden, dass es so klingt, als bezöge sich der Begriff „konstante Ausdrücke“ nur darauf. --Chricho ¹ ² 17:51, 17. Mär. 2012 (CET)

Nennung der Jahreszahl statt C++11

Im Editkommentar hast du geschrieben: entscheidend ist nicht das Jahr, sondern der Standard, gabs auch schon vor 2011 in den Entwürfen. C++11 ist aber genau 2011 erschienen, nicht vorher und nicht nachher. Die Allgemeinverständlichkeit ist bei Nennung der Jahreszahl besser. --Casu17 (Diskussion) 19:29, 17. Mär. 2012 (CET)

Das würde Sinn machen bei Sprachen, die eine einzige Implementierung haben und ständig neue Features bekommen, da kann man dann sagen, in dem und dem Jahr wurde ein bestimmtes Feature eingebaut. Hier ist das irreführend, weil der unbedarfte Leser vielleicht nicht weiß, wie das bei C++ läuft und das mit Compilersupport etc. verwechselt. Man kann ja eine kleine Erklärung hinzufügen. --Chricho ¹ ² 19:32, 17. Mär. 2012 (CET)

Typlisten

Meiner Meinung nach schießt das Thema "Typlisten" zu weit über das eigentliche Thema des Artikels hinaus. Der Zusammenhang zum Artikelgegenstand wird auch überhaupt nicht erklärt. Von mir aus kann der gesamte Abschnitt raus. --Casu17 (Diskussion) 01:28, 18. Mär. 2012 (CET)

Wir sollten uns fragen: Was genau wollen wir eigentlich drin haben? Typlisten sind ein Kernkonzept, um fortgeschrittene C++-Metaprogrammierung umzusetzen, will man etwa gewisse Patterns mit Hilfe von C++-Metaprogrammierung in allgemeiner Form verwirklichen, ist so etwas notwendig, auch wenn man in vielen Fällen dann heutzutage noch variadische Templates zur Hilfe ziehen würde, aber das widerspricht dem ja nicht konzeptuell, sondern ergänzt die praktische Umsetzung. In solchen Fällen sind Typlisten jedenfalls wesentlich wichtiger als Berechnungen von Potenzen, welche nicht gerade näher dran an der Metaprogrammierung sind. Wir sollten uns einigen, worauf wir mit dem Artikel hinaus wollen. Eigentlich müssten ganz andere Aspekte viel stärker betont werden: Policy based design (mit Optimierungsaspekten), statischer Polymorphismus, Umsetzung von Patterns. Im Moment beschränkt es sich eher auf Hilfsmittel (wie man sie etwa in großem Umfang in boost::mpl findet) statt auf das, was man damit macht. --Chricho ¹ ² 01:42, 18. Mär. 2012 (CET)

Darin, das Thema sinnvoll (!) zu vertiefen, stimme ich überein. Aber warum muss der Abschnitt während der Zeit im Artikel bleiben? Wenn wir uns später entscheiden, ihn in irgendeiner Form einzubauen, können wir das immer noch tun. So, wie der Abschnitt momentan aussieht, also ohne Erklärung des Zusammenhanges, ist es nur verwirrend. So darf ein Artikel nicht online gehen. Deswegen bin ich dafür, den Abschnitt vorläufig zu entfernen. --Casu17 (Diskussion) 13:54, 18. Mär. 2012 (CET)

Das Beispiel ist wohl zu lang. Was hälst du von einem Abschnitt „In Templatemetaprogrammierung verwendete Konstrukte“, in den man dann Typlisten ohne ein solch gigantisches Beispiel einfügt? --Chricho ¹ ² 14:04, 18. Mär. 2012 (CET)

Ich sähe gerne einen Abschnitt der Dinge thematisiert, die du anfangs angesprochen hast: Codegenerierung (also nicht reine Wertberechnung). Es sollte etwas sein, das typischerweise in der Templatemetaprogrammierung verwendet wird, aber dennoch leicht zu verstehen ist. Der Abschnitt sollte in keinem Fall zu einer reinen Aufzählung oder Sammlung von Programmierbeispielen verkommen. --Casu17 (Diskussion) 14:18, 18. Mär. 2012 (CET)

Was meinst du mit „es sollte etwas sein, das“? Du meinst ein aussagekräftiges Beispiel? --Chricho ¹ ² 14:26, 18. Mär. 2012 (CET)

Deine letzten Änderungen waren schon ganz gut. --Casu17 (Diskussion) 17:02, 18. Mär. 2012 (CET)

Syntaxhervorhebung

Ich nehme an, du hast das geändert, weil du constexpr richtig gehighlighted sehen wolltest. Man sollte aber nicht wegen eines Mangels in der Software die Struktur des Seitencodes kaputt machen. Das wird schon noch. --Chricho ¹ ² 13:31, 18. Mär. 2012 (CET)

Ja, es ging um die Einfärbung von constexpr. Das steht auch in meinem letzten Editkommentar. Aber wo steht eigentlich geschrieben "Es sollte stets <source> verwendet werden"? --Casu17 (Diskussion) 13:45, 18. Mär. 2012 (CET)

Meine Erfahrung mit der Wikipedia, dass man im Allgemeinen auf sinnvollen, gut wartbaren Quelltext achtet, statt auf Hacks, um einzelne Formatierungen zu verbessern. So kann man es einfacher ändern und wenn ein neues Geshi das mal unterstützt, muss mans dann nicht ändern. Zudem verwenden manche Benutzer eigenes CSS, um Code anders zu formatieren als die Standardwerte, was nicht mehr funktioniert, wenn man das so macht. --Chricho ¹ ² 13:52, 18. Mär. 2012 (CET)

Ich habe grundsätzliche Vorbehalte gegenüber der integrierten Syntaxhervorhebung. Zum Beispiel ist sie mir zu bunt. Ich halte mehr von einer inhaltsbezogenen Einfärbung, d.h. es werden nicht irgendwelche Teile hervorgehoben, die ein Skript entscheidet, sondern solche Stellen, auf die das Augenmerk im Zusammenhang mit dem dazu gehörenden Text gelenkt werden soll. Das ist auch das Konzept von Qualitätsautoren außerhalb der Wikipedia. --Casu17 (Diskussion) 14:01, 18. Mär. 2012 (CET)

Da ich mir unsicher bin, wie das handzuhaben ist, habe ich hier nachgefragt, ob noch jemand dazu ein Statement abgeben könnte. --Chricho ¹ ² 14:28, 18. Mär. 2012 (CET)

PNG-Bild mit Syntaxhervorhebung

Ich habe jetzt ein PNG-Bild eingebaut. Einwände? --Casu17 (Diskussion) 02:05, 27. Mär. 2012 (CEST)

Ja, das ist eine noch schlechtere Lösung:

• Alle Kritikpunkte an der HTML-Benutzung treffen hier genauso zu (also an HTML-Benutzung an sich, nicht an der Verwendung von <font> im speziellen):
  • Code unsauber
  • Schlechter zu überarbeiten
  • Uneinheitlich
  • Nicht per persönlichem CSS anpassbar
• Kann nicht durchsucht oder als Text kopiert werden
• Speicherverschwendung
• Kann nicht ordentlich skaliert werden

Gruß --Chricho ¹ ²

Was meinst du mit "Code unsauber"? Und was meinst du mit "Kann nicht ordentlich skaliert werden"? --Casu17 (Diskussion) 02:30, 27. Mär. 2012 (CEST)

Unsauber: Der Code ist nicht expressiv, es lässt sich nicht ablesen, was dort steht, geschweige denn editieren.

Skalieren: Schrift lässt sich im Browser vergrößern und verkleinern (ohne Qualitätseinbußen). --Chricho ¹ ² 10:36, 27. Mär. 2012 (CEST)

Syntaxhervorhebung der Schlüsselwörter durch Fettdruck

Ich habe jetzt eine Variante mit Wikimedia-Bordmitteln umgesetzt. Einwände? Kommentare? --Casu17 (Diskussion) 03:05, 27. Mär. 2012 (CEST)

Eher eine Notlösung als eine Lösung. Sollte so bald wie möglich wieder raus und durch die automatische Formatierung ersetzt werden. --KMic (Diskussion) 01:38, 23. Apr. 2012 (CEST)