Problem mit Visitor pattern

ACnut

Habe wieder einmal Pobleme mit den Design Patterns:
Hier ist mal das Klassendiagramm:
http://www.imagenetz.de/fde86af86/img.php.png.html

Hier mal der Auszug aus der Aufgabenstellung für die Visitmethoden:

Implementieren Sie einen Visitor (FilterFiles) der alle Dateien herausfiltert deren aktuelle Größe
innerhalb eines vorgegebenen minimalen und maximalen Wertes liegt. Ein zusätzlicher Filter
soll alle Verweise herausfiltern. Die Filter sollen in der Lage sein, alle gefilterten Dateien mit ihrem
vollständigen Pfadnamen auszugeben! Bei der Filterung von Verweisen muss zusätzlich auch der
Name des Elementes auf das verwiesen wird ausgegeben werden.

ich habe in FilterFiles eine Liste von Files.
In der Visitmethode für File, mit folgender Schnittstelle:

std::list<File*> filelist;
  typedef std::list<File*>::const_iterator TConstFileItor;  

void FilterFiles::Visitor(File* mfile) const
{
//Hier hätte ich ja normalerweise einfach z.b.
//mfile->GetName(); oder sowas aufgerufen
}

allerdings wie soll ich das jetzt mit der Liste verstehen(der Lehrer hat gemeint, dass da eine Liste bzw. ein Vektor sein soll)? bzw. wo verwende ich dann mfile?

ich würde danndie liste dann ja so durchwandern

TConstFileItor it;
	for(it=filelist.begin();it!=filelist.end();it++)
	{
if(xxx)
		*it.GetName();
else
blabla
	}

ACnut

hat sich schon wieder gelöst

kamelkacke

Wie lange lernst du c++

Skym0sh0

ACnut schrieb:

std::list<File*> filelist; 
void FilterFiles::Visitor(File* mfile) const

Dabei werd ich immer misstrauich in C++, das geht besser.

ACnut

kamelkacke schrieb:

Wie lange lernst du c++

weshalb willst du das wissen?

Skym0sh0 schrieb:

ACnut schrieb:
std::list<File*> filelist; 
void FilterFiles::Visitor(File* mfile) const
Dabei werd ich immer misstrauich in C++, das geht besser.

was meinst du damit? bzw. ich verstehe deine aussage nicht

Skym0sh0

Wenn du mit rohen Zeigern rummachst wirst du früher oder später auf die Nase fallen. Die Frage ist wann und ob du/man das überhaupt mitbekommt.

Oft treten Fehler mit rohen Zeigern auf, werden aber nicht gesehen/erkannt, weil auf den ersten Blick/zufällig alles funktioniert.

Nimm Smart-Pointer, die sind sicher. Denn wenn du Fehler machst, dann crashen die gewöhnlich.

In deiner Liste musst du für alle Zeiger erstmal gucken, ob sie null bzw. eben nicht null sind.

Ausserdem erinnere ich an DAS Paradigma von C++: RAII !
Dein File wird irgendwo geöffnet. Wann wird es denn geschlossen?

File * f = openFile();
// ...
closeFile(f);

Aber was ist wenn Programmverzweigungen auftreten?

File * f = openFile();
// ...
if ( x == 0 )
{
    closeFile(f); // so etwa?
    return y;
}
// ...
throw xyz; // und wann wie wo wird hier das File geschlossen?
// ...
closeFile(f);

Das passiert dir mit Smart-Pointer nicht.

Gleichzeitig merkst du denen auch an, wenn dein Design komisch ist.
Z.B. nutzt du std::shared_ptr, aber trotzdem hast du Memory-Leaks. Ok, dann hast du wahrscheinlich zyklische Abhängigkeiten, die allein vom Design nicht so pralle sind. Und du bist so gezwungen, alles zu überdenken und zu verbessern.

ACnut

hast wohl Recht
allerdings haben wir bis jetzt noch nichts von den boost libraries an der uni gehört. Nachdem ich den lehrer darau angesprochen habe, hat er gemeint, dass wenn es möglich ist, diese "smart-pointer" nicht zu benützen? allerdings wurde weiters gesagt, dass es auch keine probleme mit der boost-libray und dem tutor geben sollte

ACnut schrieb:

hast wohl Recht
allerdings haben wir bis jetzt noch nichts von den boost libraries an der uni gehört. Nachdem ich den lehrer darau angesprochen habe, hat er gemeint, dass wenn es möglich ist, diese "smart-pointer" nicht zu benützen? allerdings wurde weiters gesagt, dass es auch keine probleme mit der boost-libray und dem tutor geben sollte

lol das fällt mir nun sehr schwer zu glauben, dass man euch explizit vor smart-pointern warnt. sollte er es wirklich so gesagt und gemeint haben, dann hast du mein beileid. besitzende rohe zeiger sind der letzte schrott und wer freiwillig auf unterstürtzung von raii verzichtet hat sie meiner meinung nach nicht mehr alle.

Skym0sh0

Moment, von Boost sprachen wir hier doch gar nicht, oder?!

Standard-C++ hat in seienr STL schon einige Smart-Pointer:
- std::auto_ptr (alt, schlecht und deprecated)
- std::shared_ptr (auf den ersten Blick das NonPlusUltra)
- std::weak_ptr (eine Erweiterung für std::shared_ptr)
- std::unique_ptr (der eigentliche Soll-Standard!)

Wenn du einen älteren Compiler hast, dann kennt der die wahrscheinlich noch nicht. Dann kannst du auf Boost zurückgreifen.

Aber normalerweise werden an der Uni zwar Programme gefordert, aber die sind normalerweise nicht an spezielle Compilerversionen gebunden. Du kannst daher ruhig das aktuellste nehmen.

ACnut

Skym0sh0 schrieb:

Moment, von Boost sprachen wir hier doch gar nicht, oder?!

Standard-C++ hat in seienr STL schon einige Smart-Pointer:
- std::auto_ptr (alt, schlecht und deprecated)
- std::shared_ptr (auf den ersten Blick das NonPlusUltra)
- std::weak_ptr (eine Erweiterung für std::shared_ptr)
- std::unique_ptr (der eigentliche Soll-Standard!)

Wenn du einen älteren Compiler hast, dann kennt der die wahrscheinlich noch nicht. Dann kannst du auf Boost zurückgreifen.

Aber normalerweise werden an der Uni zwar Programme gefordert, aber die sind normalerweise nicht an spezielle Compilerversionen gebunden. Du kannst daher ruhig das aktuellste nehmen.

wusste nicht, dass im stl auch smartpointer gibt

c++11 wurde uns nicht direkt gelehrt, daher dürfen bzw. können wir nur die schon im VS10 implementierten benutzen. weiters wurde uns mittgeteilt, dass der umstieg auf VS11 sich noch nicht lohnt, da

noch nicht genug viele erneureungen gibt
2)auf hardwarebasis noch sehr lange VS10 benutzt werden soll(technische informatik)
3)der tutor benützt VS10

Fytch

std::auto_ptr gibt es auch schon vor c++11. die anderen smart-pointer lassen sich btw auch alle ohne c++11-sprachmittel implementieren. und nutz besser einen schlechten smartpointer (std::auto_ptr), statt gar keinen.

verstehe ich nicht, msvc 2013 hat doch viele neue sprachmittel implementiert, meinem wissen nach fast alle.
verstehe ich auch nicht.
verstehe ich auch nicht, er kann doch auch umsteigen.

Nexus

VS 2010 enthält alle Smart-Pointer aus C++11. Und ja, VS 2013 hat enorm viele C++11-Features umgesetzt, ein Umstieg könnte sich durchaus lohnen.

P.S. Bitte sprecht nicht von VS10 und VS11, das verwirrt die Leute nur. Bei Visual Studio gibts separate Versionsnummern für Compiler und IDE (und noch eine 3. in _MSC_VER ). Die IDE-Nummer entspricht dem Jahr, die Compiler-Nummer ist eine inkrementelle Versionsnummer.

Visual Studio 2010 = Visual C++ 10
Visual Studio 2012 = Visual C++ 11
Visual Studio 2013 = Visual C++ 12

ACnut

korreliert vllt Visual Studio 2013 mit dem Atmel Studio(basiert so wie ich es sehe (bzw. jedesmal öffne) auf Visual Studio 2010)?
die lehrkräfte haben uns die obengenanten gründe gegeben, aber wieso weshalb weiß ich auch nicht

ich könnte jetzt mal hineininterpretieren (auf grund 2):
in der hardwarenhaen programmierung braucht man nicht wirklich c++11. wir selber programmieren da in C und auf dem Arduino gibts auch nur einen abgespeckten C++-Compiler, der noch halbwegs OOP unterstützt.

@Nexus gut zu wissen. dann muss mich nur selber autodidaktisch mit diesem Thema befassen den lernen werden wir es zumindest in diesem semester sicher nicht mehr
ok,werde diesbezüglich beim nächsten mal mehr aufpassen (aber MS schreibts ja selber mit VS10,...?)