C++03 / C++11: Einige Fragen beim Schreiben einer Library

Sone

cooky451 schrieb:

Vergiss C++03 einfach.

YMMD

Variadic Templates braucht meine Library auch. Was die C++03-Version betrifft: Soll ich da einfach einen Haufen Default-Parameter benutzen? Wenn ja, wie viele?

Was brauchst du denn genau an variadic templates? Bestimmt nichts was wirklich nur variadic templates können. Erklär mal anhand eines Beispiels.

Sone schrieb:

Was brauchst du denn genau an variadic templates? Bestimmt nichts was wirklich nur variadic templates können. Erklär mal anhand eines Beispiels.

Größtenteils für das Event-System.
Beispiel:

template<typename Type, typename = typename std::enable_if<std::is_function<Type>::value>::type>
	class Event{
...

		template<typename... Arguments, typename ResultType = result_type, typename = typename std::enable_if<std::is_same<void, ResultType>::value == true>::type>
		result_type process(Arguments&&... arguments) const{

			for(const auto& function : functions_vector_)
				function(std::forward<Arguments>(arguments)...);
		}

		template<typename... Arguments, typename ResultType = result_type, typename = typename std::enable_if<std::is_same<void, ResultType>::value == false>::type>
		std::vector<result_type> process(Arguments&&... arguments) const{
			std::vector<result_type> results;

			for(const auto& function : functions_vector_)
				results.push_back(function(std::forward<Arguments>(arguments)...));

			return results;
		}

...

	};

Sone

Also Funktions-Argumente forwarden.
Naja. Gabs schon in Loki (Alexandrescu - Modern C++ Design), halt für Funktionen mit bis zu AFAIK 15 Parametern. Und ohne perfect forwarding natürlich, aber das gibt es in C++03 eben sowieso nicht.

void invoke(std::function<void(int)> const& f) { f(4); }

...
// Bitte nicht auf is_function<Type>::value testen, ich will das auch mit std::funciton verwenden können!!!111
template<typename Type>
class Event{
      template <typename Invoker>
      result_type process(Invoker i) { foreach (f : funcs) i(f); }
}

@Sone: Seit wann ist Loki ein Massstab?

cooky451 schrieb:

Vergiss C++03 einfach.

Thats a good point.

Ich weiß ja nichtmal ob überhaupt jemand irgendwann mal meine Library benutzen möchte. Ich belasse es dann vorerst mal bei C++11 und wenn dann irgendwann mal Bedarf auf C++03 entsteht, kann ich den Kram ja umschreiben.

Haltet ihr das für eine gute Idee?

SeppJ

ichBinKnuddelig schrieb:

Haltet ihr das für eine gute Idee?

Ja. Wir haben 2013, so langsam sind C++11-Compiler auch auf trägeren Systemen angekommen^*. Die verbliebenen Systeme sind die, die niemals upgraden werden und noch immer mit VS6, GCC3 oder gar mit einer DOS-Version von Turbo-C++ (von anno 1985) arbeiten, weil irgendein Entscheider gegen einen Wechsel ist (oder es ihm einfach egal ist). Die unterstützen dann in der Regel nicht einmal C++98 richtig. Wenn du (mit C++11) maximal portabel bleiben möchtest, dann lass erst einmal Features aus, die nicht in allen großen Compilern (Microsoft, GCC, Clang, eventuell noch Intel und IBM) imlementiert sind.
http://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport

^*: Man denke daran, dass C++11 wesentlich älter ist als 2011 und viele Features davon schon lange vorher verbreitet waren. Bloß eben noch nicht offiziell.

hustbaer

@SeppJ
Wir haben ne riesen Code-Base die wir erst vor ein paar Jahren mühsam auf VS 2005 upgegraded haben.
Ein Upgrade auf VS 2012 ist im nächsten Jahr unwahrscheinlich.
Trotzdem würde ich nicht sagen dass unser Code "niemals upgegraded" wird.

Auf C++ 03 Systeme Rücksicht nehmen finde ich also nicht ganz verkehrt.

Wobei ich es auch niemandem übel nehme wenn er seine Open-Source (oder auch Closed-Source) C++ Library so programmiert dass z.B. VS 2012 vorausgesetzt wird. Muss jeder für sich entscheiden.
Ich würde aber eben jmd. der gerne Rücksicht nehmen will nicht sagen "vergiss C++ 03", weil das danach klingt als ob es keinen mehr interessieren würde. Was definitiv nicht so ist.

SeppJ

Aber prinzipiell hättet ihr einen C++11-Compiler auf dem System (oder könntet einen holen), der hinreichend kompatibel ist, um am Ende alles zusammen zu linken.

Das Interface der Bibliothek darf man natürlich gerne kompatibel zu C++03 halten, aber bei den Interna würde ich keine Rücksicht mehr nehmen.

hustbaer

SeppJ schrieb:

Aber prinzipiell hättet ihr einen C++11-Compiler auf dem System (oder könntet einen holen), der hinreichend kompatibel ist, um am Ende alles zusammen zu linken.

Ja.
Nur was nutzt uns das? Man kann nicht einfach VS 2005 und VS 2012 Code zusammenknoten, wenn das Interface C++ ist.
Mit nem C-DLL Interface geht es natürlich, aber es geht hier ja um C++ Libs.

Das Interface der Bibliothek darf man natürlich gerne kompatibel zu C++03 halten, aber bei den Interna würde ich keine Rücksicht mehr nehmen.

Siehe oben, ich wüsste nicht was uns das bringen sollte.

TNA

[quote="SeppJ"]

ichBinKnuddelig schrieb:

Die verbliebenen Systeme sind die, die niemals upgraden werden und noch immer mit VS6, GCC3 oder gar mit einer DOS-Version von Turbo-C++ (von anno 1985) arbeiten, weil irgendein Entscheider gegen einen Wechsel ist (oder es ihm einfach egal ist). Die unterstützen dann in der Regel nicht einmal C++98 richtig.

Ganz so schwarzweiß ist das nicht. Bei uns ist z.B. mit GCC 3.7 erst mal Ende der Fahnenstange, weil die neueren eine älter ABI für ARM nicht mehr unterstützen, die wir benötigen. Damit werden wir manches von C++11 nie nutzen können. Auch gestaltet sich die Anbindung der Standardbibliothek sehr schwierig und kommt erst langsam Schritt für schritt. "Thread" wird es wohl spät bis nie geben, da das mit unserem Jobmanagement konzeptionell nicht zusammenpasst.

TyRoXx

ichBinKnuddelig schrieb:

std::function<> , das ist doch erst seit C++11 dabei, nicht? Wenn ja, dann wäre die beste Lösung wohl eine eigene Klasse dafür zu bauen, right?

boost::function

ichBinKnuddelig schrieb:

std::mutex ist erst seit C++11 dabei, aber ich brauch für die 03-Version einen plattformunabhängigen Weg um einige Stellen meiner Library thread-sicher zu machen. Irgendwelche Vorschläge?

boost::mutex

ichBinKnuddelig schrieb:

Variadic Templates braucht meine Library auch. Was die C++03-Version betrifft: Soll ich da einfach einen Haufen Default-Parameter benutzen? Wenn ja, wie viele?

Boost.Preprocessor oder Boost.MPL

ichBinKnuddelig schrieb:

Größtenteils für das Event-System.
Beispiel:

template<typename Type, typename = typename std::enable_if<std::is_function<Type>::value>::type>
	class Event{
[...]
	};

Sieht so ähnlich aus wie Boost.Signals2.

Boost hat auch Mittel, um Unterschiede zwischen Implementationen auszugleichen. Da gibt es zum Beispiel BOOST_CONSTEXPR , einen Ersatz für <cstdint> , Emulation von RValue-Referenzen, Container wie vector und so weiter.

Warum nicht einfach Boost nehmen?

TyRoXx: Danke für die Vorschläge, aber

ichBinKnuddelig schrieb:

[...] Auch wenn man einige meiner Probleme mit anderen diversen Libraries (z.B. boost) lösen könnte, verzichte ich darauf, weil ich ganz einfach nicht will, dass meine Library von anderen Libraries abhängig ist.[...]

Ich werd erstmal kucken wie sich die Library, die sich an den 11er Standard lehnt in der Öffentlichkeit schlägt, wenn dann wie bereits erwähnt wirklich noch Bedarf an C++03 auftritt geh ich nochmal auf den Thread ein.

Bis dahin nochmals Danke an alle!

SeppJ

hustbaer schrieb:

Nur was nutzt uns das? Man kann nicht einfach VS 2005 und VS 2012 Code zusammenknoten, wenn das Interface C++ ist.

Kann man nicht? Dann ziehe ich meine Bemerkung zurück. Da ich VS in der Praxis nicht kenne, war ich davon ausgegangen, dass sich das vernünftig verhält.

Nexus

ichBinKnuddelig schrieb:

TyRoXx: Danke für die Vorschläge, aber [...]

Wie gesagt, man kann halt nicht alles haben. Boost ist genau für solche Zwecke ideal, ausserdem ist es wohl die meistgenutzte C++-Bibliothekssammlung.

SeppJ schrieb:

Kann man nicht?

Sind bei g++ die Binaries verschiedener Major-Releases kompatibel zueinander?

Nexus schrieb:

SeppJ schrieb:

Kann man nicht?

Sind bei g++ die Binaries verschiedener Major-Releases kompatibel zueinander?

Nicht nur die Major-Releases vom g++ (welche ungefähr 10 mal weniger sind als MSVC-Major-Releases).
Auch sind clang, gcc und andere Compiler (vermutlich auch Intel, IBM) zueinander binärkompatibel. Der gemeinsame Nenner ist die Itanium ABI.

Probleme können Linkabhängigkeiten mit der glibc o.Ä. machen, aber die sind (bis auf seltene Kleinigkeiten) rückwärtskompatibel.

Das Problem bei __cplusplus ist doch dass das erst auf zb. C++11 gesetzt wird, wenn der Standard voll umgesetzt wird - meines Wissens nach gab es aber noch nie einen Compiler der einen Standard zu 100% umgesetzt hat, Blüten wie export etc sei dank.

Lieber mit __GNUC__, __GNUC_MINOR__, __GNUC_PATCHLEVEL__ und __GXX_EXPERIMENTAL_CXX0X__ arbeiten wenn der GCC das Ziel ist, bei Visual Studio wohl _MSC_VER

hustbaer

@SeppJ
Das Problem ist die Standard-Library.

asc

Ethon_ schrieb:

...meines Wissens nach gab es aber noch nie einen Compiler der einen Standard zu 100% umgesetzt hat, Blüten wie export etc sei dank.

Comeau C++ konnte soviel ich weiß als einziger das von dir angesprochene export, und galt wenn ich mich richtig erinnere tatsächlich als komplett Standardkompatibel (Ich aber kein echter Compiler, sondern eher ein Meta-Compiler der aus C++ C macht, und dies an einen anderen Compiler weitergibt).

[Anderseits scheint Comeau inzwischen tot zu sein, Updates kommen jedenfalls seit langen keine mehr]

Ethon_ schrieb:

Das Problem bei __cplusplus ist doch dass das erst auf zb. C++11 gesetzt wird, wenn der Standard voll umgesetzt wird...

Man sollte zumindest darauf achten, welche Features von den Zielcompilern schon (richtig) unterstützt werden. Leider arbeiten wir z.B. noch mit dem C++ Builder (Und dank einer Problematik konnten wir noch nicht vom 2007ener wechseln, aber auch die neueren sollen wohl noch nicht wirklich gut den C++ Standard unterstützen).

TNA

Ethon_ schrieb:

Das Problem bei __cplusplus ist doch dass das erst auf zb. C++11 gesetzt wird, wenn der Standard voll umgesetzt wird - meines Wissens nach gab es aber noch nie einen Compiler der einen Standard zu 100% umgesetzt hat, Blüten wie export etc sei dank.

Wenn ich das richtig verstehe, unterstützt Clang zusammen mit der Libcxx mittlerweile C++11 zu 100%. Zumindest laut eigenen Angaben.