VTools free Library
-
Wie gesagt, ich nehme gerne Kritik an - aber ich mag nicht über das leidige Thema streiten, warum das Rad immer wieder neu erfunden wird.
VConsole ist noch in der Entstehungen, aber deine Vorschläge nehme ich für die nächste Version an (vorsicht : gemeint ist nicht patch!)
VString ist für diejenigen unter euch gedacht, die Programme OHNE die MFC schreiben wollen/müssen, aber nicht auf den Komfort verzichten wollen:)
Sie handhabt sich etwas anders (nicht Index-Null-basierend), und hat einige sehr interessante Funktionen :
z.b. StringToType ()VString p("4E5"); ULONG d = (ULONG)(p.StringToType <double> ());
d = 400000;
(geht natürlich auch mit Kommazahlen (double statt ULONG verwenden))oder der IP-Address-String
VString(const STRING IPAddress,const STRING Port); //String als IP-Addresse mit Port bool IsValidIP(); int GetPort(); VString GetIP();
Außerdem sind die Vergleichsmethoden verändert worden:
bool CmpCaseSensitive; .. //reagiert auf CmpCaseSensitive int Compare(const STRING lpsz ) const; int CompareCase(const STRING lpsz) const; int CompareNoCase(const STRING lpsz ) const;
-
Jaja die Räder
- warten auf die nächste Version *g* :).
MfG SideWinder
-
Jaja die Räder
- warten auf die nächste Version *g* :).
MfG SideWinder
-
das hat jetzt nichts mit dem Rad neu erfinden zu tun - aber std::string waere besser als VString. nicht weil dein VString nicht uU besser ist als std::string, sondern weil ich dann deine library vernuenftig verwenden kann.
ich habe ueberall std::string - und auf einmal kommt n neuer string dazu. da muss ich dauernd umkopieren. bzw. ist c_str() auch nicht immer ideal (da es tw. doch ordentlich zeit verschlingt)
also wenn du dein VString behalten willst, dann mach doch bitte noch ueberladungen fuer std::string rein...
btw: warum verwendest du V als prefix?
pack die klassen doch lieber in einen namespace, zB vtools
so, ich geh jetzt einmal davon aus, dass ich auch den code kritisieren darf
#define LPCHAR char*
warum ist das noetig? und notfalls, lieber ein typedef. aber ich seh da irgendwie keinen sinndu uebergibst sehr gerne by value - uebergib doch besser by const reference - das spart dir ne kopie!
eine doku waere ideal.
denn wie verwendet man denn dein assert?OutputDebugV
das macht in der release version nur ein return; - ich wuerde es in der release version auch noch inlinen - dann sparst du dir den aufruf der funktion.detto bei TRACE_
#pragma warning(disable:4267)
#pragma warning(disable:4244)
#pragma warning(disable:4390)
#pragma warning(disable:4018)
#pragma warning(disable:4018)
#pragma warning(disable:4018)ist das wirklich noetig? soviele warnungen zu disablen? uU will der user sie aber doch haben. kannst du sie nicht irgendwie nur fuer deinen code ausschalten?
aufeinmal hast du C als prefix? (CThreadSafeClass) - warum?
#define VThreadSafeClass CThreadSafeClass
#define UnLock Unlockalso das erste #define wuerde ich zu einem typedef machen
und das 2. #define ist gefaehrlich.
was wenn der user irgendwo in seinem code UnLock verwendet? zB als member einer seiner klassen?die ganzen pragma once wuerde ich noch um echte include guards ergaenzen, dann kann man das auch auf non-ms-compatiblen compilern zum laufen bekommen.
warum verwendest du zB bei VConsole eine init methode? mach das doch gleich im Ctor.
ASSERTS(TRUE,"not implemented");
sollte wohl
ASSERTS(false,"not implemented");
heissen, oder? (VDialog::VDialog)warum verwendest du BOOL, TRUE und FALSE statt bool, true und false?
#define NULL 0
? was soll das denn ? (VSTring.cpp)
binde einfach cstdlib eindein VString sollte die operatoren+,== usw. als non-member haben.
VString s("hallo");
VString erg='x'+s;
geht bei dir nicht.#ifndef LPVOID
#define LPVOID void*
#endif
warum sowas? das wird doch in der windows.h schon definiert? (VString.h)ok, ich weiss, ich bin hart - aber das sind die sachen die mir aufgefallen sind.
-
ich habe ueberall std::string - und auf einmal kommt n neuer string dazu. da muss ich dauernd umkopieren. bzw. ist c_str() auch nicht immer ideal (da es tw. doch ordentlich zeit verschlingt)
also wenn du dein VString behalten willst, dann mach doch bitte noch ueberladungen fuer std::string rein...
du würdest also gerne nur durch die Änderung des Namespace, entweder std::string oder VString verwenden?
Vestehe ich das richtig?VString ist die allererste Version, und jemand anderes ist dabei, die Klasse etwas umzugestalten - danach sehe ich weiter, ob und wie das zu bewerkstelligen ist.
btw: warum verwendest du V als prefix?
Ich wollte die Klassen zu der Bibilothek bindend machen - als dass die Libraryklassen noch als solche erkannt werden.
Ist zwar nicht nötig- aber man erkennt dann sofort, dass es zu VTools gehört.
Das V kommt aus den Klassenbezeichnungen in RealVNC - ich habs übernommen, als ich damit arbeitete.pack die klassen doch lieber in einen namespace, zB vtools
siehe überladen (oben)
so, ich geh jetzt einmal davon aus, dass ich auch den code kritisieren darf
#define LPCHAR char*
warum ist das noetig? und notfalls, lieber ein typedef. aber ich seh da irgendwie keinen sinnLPCHAR war bei mir nicht definiert, und ich hatte mal tests mit ANSI und UNICODE gemacht.
du uebergibst sehr gerne by value - uebergib doch besser by const reference - das spart dir ne kopie!
Ist mir auch aufgefallen, aber bin nicht dazugekommen.
eine doku waere ideal.
denn wie verwendet man denn dein assert?Kann dies derzeit leider nicht machen.
Aber es ist schon in der TODO-Liste.OutputDebugV
das macht in der release version nur ein return; - ich wuerde es in der release version auch noch inlinen - dann sparst du dir den aufruf der funktion.
detto bei TRACE_die ASSERT-Routinen entstanden sehr schnell, weil die Notwendigkeit existierte (ohne MFC) und noch keine Release-Version erstellt wurde.
#pragma warning(disable:4267)
#pragma warning(disable:4244)
#pragma warning(disable:4390)
#pragma warning(disable:4018)
#pragma warning(disable:4018)
#pragma warning(disable:4018)ist das wirklich noetig? soviele warnungen zu disablen? uU will der user sie aber doch haben. kannst du sie nicht irgendwie nur fuer deinen code ausschalten?
Ich habs ausgeschaltet, weil ich die Fehler nie gesehen hatte, wg. den Warnungen. Aber für die Warnungen hatte ich auch keine Zeit. (Teufelskreis)
aufeinmal hast du C als prefix? (CThreadSafeClass) - warum?
Die Klasse stammt noch aus einer früheren Zeit - als VTools noch nicht existierte. Da hab ich vergessen, den Prefix zu ändern - deshalb das DEFINE
#define VThreadSafeClass CThreadSafeClass
#define UnLock Unlockalso das erste #define wuerde ich zu einem typedef machen
und das 2. #define ist gefaehrlich.
was wenn der user irgendwo in seinem code UnLock verwendet? zB als member einer seiner klassen?Das zweite DEFINE war nur für mich gedacht, weil ich einen Code hatte wo dies so drinstand, ich aber mit der Schreibweise nicht einverstanden war (und eine Änderung zu aufwendig gewesen wäre) - also löschen!
die ganzen pragma once wuerde ich noch um echte include guards ergaenzen, dann kann man das auch auf non-ms-compatiblen compilern zum laufen bekommen.
Klar - kann derzeit die Library auch nur unter MSC++ .NET testen.
warum verwendest du zB bei VConsole eine init methode? mach das doch gleich im Ctor.
Ist mir leider zu spät aufgefallen, dass im Constructor das "this->Init();" fehlt.
ASSERTS(TRUE,"not implemented");
sollte wohl
ASSERTS(false,"not implemented");
heissen, oder? (VDialog::VDialog)Ja - gut gesehen!
falls jemand versteht, wie man Resourcentemplate als String übergibt - her damitwarum verwendest du BOOL, TRUE und FALSE statt bool, true und false?
Gewohnheitssache
#define NULL 0
? was soll das denn ? (VSTring.cpp)
binde einfach cstdlib eindieses #define ist veraltet und kann gelöscht werden
dein VString sollte die operatoren+,== usw. als non-member haben.
VString s("hallo");
VString erg='x'+s;
geht bei dir nicht.Du meinst außerhalb der Klassendeklaration ?
#ifndef LPVOID
#define LPVOID void*
#endif
warum sowas? das wird doch in der windows.h schon definiert? (VString.h)stammt aus der Zeit, als Windows.h nicht verwendet wurde und ist veraltet.
ok, ich weiss, ich bin hart - aber das sind die sachen die mir aufgefallen sind.
Kommt sicher noch mehr. Die Library soll ja auch besser werden und nicht verharren
-
Dezipaitor schrieb:
also wenn du dein VString behalten willst, dann mach doch bitte noch ueberladungen fuer std::string rein...
du würdest also gerne nur durch die Änderung des Namespace, entweder std::string oder VString verwenden?
Vestehe ich das richtig?
[/quote]
ne, nicht ganz.
du hast momentan alle funktionen fuer char* und VString geschrieben.
nun verwenden die meisten leute aber std::string - was bei dir aber nicht funktioniert. ich wuerde also noch eine dritte version zu jeder deiner funktionen schreiben - mit std::string als parameter.pack die klassen doch lieber in einen namespace, zB vtools
siehe überladen (oben)
das habe ich nicht ganz verstanden? was ist da ueberladen?
eine library sollte schon einen eignen namespace haben (schon alleine wegen der namenskonflikte)warum verwendest du zB bei VConsole eine init methode? mach das doch gleich im Ctor.
Ist mir leider zu spät aufgefallen, dass im Constructor das "this->Init();" fehlt.
ich wuerde den anwender zwingen die objekte schon im Ctor zu initialisieren - dann hast du keine probleme mit "nicht initialisierten objekten"
warum verwendest du BOOL, TRUE und FALSE statt bool, true und false?
Gewohnheitssache
in Exceptional C++ gibts ein
[quote]
BOOL ist bloedsinn - es ist ein #define auf int
siehe: http://www.gotw.ca/gotw/026.htmdein VString sollte die operatoren+,== usw. als non-member haben.
Du meinst außerhalb der Klassendeklaration ?
exakt
Kommt sicher noch mehr. Die Library soll ja auch besser werden und nicht verharren
na da bin ich mal gespannt
-
vielleicht hast du lust,
die std::string routinen zu implementieren?
dann würde es auch schneller gehen
-
Ich verstehe allerdings immer noch nicht wieso die Konsolen-I/O-Klasse kein Streamkonzept verwendet.
MfG SideWinder
-
wenn dann würden nur die Operatoren (<< >>) zur und mit verbesserten Ein- und Ausgabe implementiert werden.
Bis jetzt komme ich noch ganz gut mit der Klasse so aus -aber wenn das jemand unbedingt sofort haben will, muss er sich wohl oder übel selber dran setzen.
Ich werde das wohl erst in einiger Zeit schaffen.
-
so version 1.1 ist draussen,
und ich habe ein paar Vorschläge beherzigtweiter gehts...