Sorry das der Thread so verwahrlost ist.
Jetzt hab ich aber wieder Zeit hier zu schreiben und mir euer feedback durchzulesen.
Das Leck befindet sich u.A. im Copy C'tor. Fehlerchen gibts viele. Einige Beispiele:
FastStream.cpp
|
C-/C++-Quelltext
|
1
2
3
4
5
|
// Die Schnittstelle erzeugen
pDevice = new IFastStreamDevice;
if(!pDevice)
return 0;
|
Was ist falsch?
Seit der Operator
new nie einen Nullpointer liefert (das war mal früher so) ist diese Abfrage total sinn- und zwecklos. Der Operator new wirfst eine Exception vom Typ std::bad_alloc wenn der Speicher nicht reserviert werden konnte.
Lösung:
|
|
C-/C++-Quelltext
|
1
2
3
4
|
pDevice = new ( std::nothrow ) IFastStreamDevice;
if ( !pDevice )
return 0;
|
Das wusste ich net. in meinem buch stand dass new im falle eines fehlers 0 zurückgibt. Hab das auch erst vor kurzem in einem anderen buch gelesen, dass es so ist, wie du sagst. Danke!
fsBuffer.h
|
|
C-/C++-Quelltext
|
1
|
template<typename T>class FASTSTREAM_API CBuffer : public CString
|
Was ist falsch?
Da CString ein Klassentemplate ist muss zwangsläufig ein Typ angegeben werden, es sei denn irgendwo wird CString als vollständige Klasse definiert oder Typendefiniert. Aber CString ist ja sowiso mysteriös.
Lösung:
Typ angeben.
Wie du vllt gemerkt hast ist die fsBuffer.h in der FastStream.h nicht mehr includiert und die fsBuffer.cpp auskommentiert.(Keine Ahnung, warum ich das noch mit ins archiv gepackt hab)
Überall wo Templates Exportiert werden
|
|
C-/C++-Quelltext
|
1
|
template< typename T > class FASTSTREAM_API XYZ ...
|
Was ist falsch?
Templates können nicht in die DLL exportiert werden. Siehe Erklärung oben.
Lösung:
Einfach nicht exportieren und den gesamten Quellcode bereitstellen.
hmm....
fsFile.h
|
|
C-/C++-Quelltext
|
1
|
template<typename T> void CloseHandleT(T **pValue)
|
Was ist falsch?
Nichts direkt, allerdings wäre ein Referenz auf einen Zeiger wesentlich schöner.
Lösung:
|
|
C-/C++-Quelltext
|
1
2
3
4
5
6
7
8
|
template< typename T > void CloseHandleT( T*& pValue )
{
if(!(pValue))
return;
::CloseHandle(pValue);
(pValue) = NULL;
}
|
Was soll ich sagen... geschmaksache...
Nahezu überall
|
|
C-/C++-Quelltext
|
1
2
3
4
5
|
irgendeinzeiger = NULL;
if ( irgendeinzeiger == NULL )
...
|
Was ist falsch?
Auch nichts direkt, aber ein Zeiger kann in C++ auf '0' getestet werden. NULL ist ein unnötiges Fragment aus C Zeiten und gehört nichtmal zum C++ Standard.
Lösung:
Statt NULL einfach 0 verwenden. Ist mehr C++! ;-)
Ich schreibe NULL nur der übersichtlichkeit halber.
fsFile.h und überall sonst
|
|
C-/C++-Quelltext
|
1
|
CFile(char *pcFileName, EFileEncoding Encoding = ANSI);
|
Was ist falsch?
Die Parameter mit dem Typ char* sollten egtl immer const char* sein.
Lösung:
|
|
C-/C++-Quelltext
|
1
|
CFile( const char* pcFileName, ... )
|
Warum denn eigentlich const char*?
An vielen, vielen Stellen
|
|
C-/C++-Quelltext
|
1
|
foo xyz() { return bar; }
|
Was ist falsch?
An vielen Stellen hält der Code die const correctness nicht ein.
Lösung:
Const Correctness einfach 100% einhalten. Dann wird evtl auch jemand diese Bibliothek verwenden. Code der sich
nicht an die Const Correctness hält landet im Mülleimer.
Was meinst du damit?
fsString.h
|
|
C-/C++-Quelltext
|
1
2
3
4
5
6
7
8
|
template<typename T>void CString<T>::InitPtrs()
{
// Alle Zeiger auf NULL setzen
m_pcString = NULL;
m_pcOldString = NULL;
ClearMem();
}
|
Was ist falsch?
Memoryleak: ClearMem LÖSCHT beim Aufrufen von InitPtrs Nullpointer. Das macht zwar rein garnichts, aber der Speicher wird dennoch nicht freigegeben.
Lösung:
Erst speicher freigeben, dann Zeiger auf 0 setzen.
InitPtrs wird nur vom Konsturktor aufgerufen. Ist also egal, ob die Zeiger auf 0 sind oder net.(Ist noch ein überbleibsel aus schlechten Zeiten.
fsString.h
|
|
C-/C++-Quelltext
|
1
|
template<typename T>const void CString<T>::operator += (T *pcText)
|
Was ist falsch?
Der Operator += hat typischerweise eine vollkommen andere Signatur.
Lösung:
|
|
C-/C++-Quelltext
|
1
2
3
4
5
6
|
template< typename T >
CString< T >& operator+=( CString& str, T* pcText )
{
str.AddString( pcText );
return str;
}
|
Hmm er funktionier aber trotzdem
Danke, dass du mir so sehr gehlfen hast, und dir die mühe gemacht hast, nahezu den ganzen quellcode durchzulesen, es ist inzwischen ja schon nicht mehr wenig.
Leider habe ich die anderen beiträge noch net gelesen und konnte deshalb auch den anderen noch kein feedback geben.
Socke
spieleprogrammierer.de »
Spieleentwicklung und Programmierung »
C, C++, C#, Java und andere Programmiersprachen »
Zitat von »"David_pb"«
Doppelpointer sind weniger Sicher als Referenz auf Pointer. Drum ist das nicht nur Geschmackssache.
30.04.2024, 20:39
Zum Seitenanfang
