Interesse an Win32/64/C++-Basislib?

Die meisten BG-Entwickler nutzen ja kein C++. Wir denken, das ist ein Fehler.
Unsere Erfahrungen mit C++ als Backend sind sehr gut.
Da es immer wieder mal Fragen nach unserer Technik gibt, denken wir darüber
nach, Teile davon einfach unter einer MIT/BSD-Lizenz freizugeben.
Wir würden dafür definitiv keinen DAU-Support leisten, adäquate Expertise oder
zumindest Fleiss wäre also Vorraussetzung.
Was unsere Lib leistet:
- Komplett 32bit/64bit-kompatibel
- Komplettes Framework ohne STL/CLib/Win32-Referenzen
- Memory Management
- Threads
- Strings
- Tcp/Ip
- Filehandling
- Config
- native HighPerf-C++-Datenbank
- Standard-Container (DynArray, Hashmap,...)
- Compression
- Crypt
- Bitmaps (JPG/GIF/TGA)
Bevor wir jetzt losrennen und da Aufwand treiben stellt sich erstmal die Frage,
ob es überhaupt Interesse an so etwas gibt.
Leider kann man hier keine Umfrage starten. Also bitte einfache Replies (gerne
auch mit Kommentaren):
[A] - Ja, das würde mich interessieren und ich kann damit auch was anfangen
- Wäre interessant mal zu sehen
[C] - Ich kann kein C++, aber ich würde es gerne lernen
[D] - Wozu soll das gut sein?
[E] - Wie lade ich das auf funpic hoch?

[C]

Versuch zurzeit da selber etwas zu programmieren.
Von daher wären Bespiele sehr gut!

Mit so einer Lib werden bestimmt einige anfangen auch mit C++ was zu entwickeln, weil einfach mal die ganze Vorarbeit Vergangenheit wäre.
Ich würde E nehmen, schon aus Prinzip
Da ich aber eh mit Java entwickle sollte es mich weniger interessieren. Aber nette Geste

([C] - man lernt nie aus )

[C]

[E]
ich bleibe vorerst mal bei meinen sprachen...ev bei genügend zeit mir java beibringen

[A]
Gibt es doxygen Dokumentation? Was habt ihr gegen STL? Kennt ihr boost? Fehlerweitergabe mit Errorcodes?
Habt ihr etwas was http header parst und http response header generiert?
Ich hoff' das waren jetzt nicht zu viele Fragen ;-)

Prinzipiell eine sehr interessante Sache, ich bin also eher bei .
Teile der Datenbank würde ich mir auf jeden Fall anschauen und eventuell irgendwie in mein Konzept hereinfließen lassen. Im Gegenzug würde ich dann evtl meine Datenbank unter einer reziproken Lizenz freigeben. Dies wäre dann [a].
Da ich persönlich aber kein C++ nutze und ich es auch in nächster Zukunft für BG-Projekte nicht vor habe, kann ich den Code direkt nicht nutzen.

Doxygen - Teilweise, würden wir noch etwas nacharbeiten
STL - Template bloat, Ärger beim Debuggen, viel überflüssiger Kram
Boost - Kennen wir, ist auch schön, bloss leider ohne STL nix
HTTP - Alles, was mit HTTP zu tun hat ist bei uns in einem eigenen Projekt. Sockets, String parsing usw sind allerdings in der Basislib schon drin.
Fehlercodes - Die Lib wirft grundsätzlich keine Exceptions, Error codes sind entweder straight bool oder Enums der jeweiligen Klasse.

[A]
Du solltest dir ausserdem vielleicht mal Ectroverse anschauen. Das ist ein Open Source Spiel das komplett in C geschrieben ist. Natürlich ist das keine Library und auch kein C++, aber vielleicht kann man da trotzdem noch was abschauen.

[C]
Auch wenn ich noch mit PHP rumdümpel und ein bisschen was in C# gemacht habe, würde mich das interessieren. Evtl bekomme ich sogar Lust mal was mit C++ zu machen, auch wenn bei mir nie mehr als ein "Hallo Welt, dein Name ist [..]" rausgekommen ist

[A]
einziger Nachteil wäre das ich mir das dann erstmaln in Objective C umschreiben müsste.

Wobei ich hier nur neugierig über auf euren Implementationsweg bin.
Viele Teile sind eh schon vorhanden, oder geplant bei mir.

Sodele...
Dann man viel Spass damit:
[SIZE=16]pixeltamer open source stuff[/SIZE]
Die Version heisst 1.0, weil wir normalerweise alles per ChangeList referenzieren, womit der Rest der Welt aber wohl nichts anfangen können wird.

Schönen Dank ;-)

Auch von mir. Werde mir das mal in Ruhe ansehen.

, aber wieso nicht OS unabhängig, wenn ihr eh schon auf win32-Aufrufe verzichtet?
Zumindest Windows und Linux wären sinnvoll.
Eventuell die OS-abhängigen Sachen wie sockets, logging, teilw. file io etc. auslagern bzw. abstrahieren?

[E] würde ich auch gern wissen.
Ansonsten [C]

Die Idee hinter ptBase ist unter anderem die _Möglichkeit_ eines Linux-Ports zu haben.
Deshalb ist der ganze Win32-Kram gekapselt.
Wenn man jetzt also einen Linux-Port machen will beschränkt sich das auf ptBase und die davon abhängigen Projekte (so sie nicht MFC odgl nutzen) müssen nicht verändert werden.
Dass es (noch) keinen Linux-Port gibt liegt daran,
a) dass wir Win32/64 einfach sehr viel besser kennen
b) dass wir Win64 für die bessere Basis eines hochperformanten Webservers halten
c) dass es im Moment für GCC keine IDE gibt, die auch nur ansatzweise an VStudio rankommt (Eclipse+CDT ist noch nicht so weit)
Bevor jetzt wegen b) ein Flamewar losbricht, möchte ich das auch noch begründen:
1. Es gibt auf Linux leider kein Äquivalent zu TransmitPackets. Das sehr sehr wichtig, wenn man nicht eh' schon sinnlos Cycles in PHP/Python/Perl/Ruby verbrät.
2. Das Threading unter Windows ist (zumindest für unsere Zwecke) besser steuerbar.