Themen-Überblick
(Aktualisieren)
| Autor |
Nachricht |
fr33g
|
Sehr guter Artikel, dickes Dankeschön auch von mir 
Lg freeG |
|
|
 |
tomislaw
|
Super Artikel, danke auch von meiner Seite! |
|
|
|
phcn.fraggle
|
Super Artikel, genau danach habe ich gesucht und auf anhieb gefunden  |
|
|
|
bEKAR
|
| 21:44:16 29.11.2009 Titel: |
kleiner Rechtschreibfehler |
Zitieren |
also erstmal Danke für diesen Artikel! Habe dadurch endlich nach 2 Tagen eine funktionierende Observer Subject Struktur hinbekommen. Es gibt noch einen kleinen Fehler
class ConcrecteSubject : public Subject
da hast du ein c zu viel. Ansonst Danke für diesen Artikel ich teste jetzt mal das Strategie Pattern!
| C++: | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17 | // ConcreteSubject.h //
#include <string>
#include "Subject.h"
using namespace std;
class ConcrecteSubject : public Subject
{
private:
string data;
public:
void setData(string _data) { data = _data; }
string getData() { return data; }
ConcreteSubject() : Subject() {}
}; | |
Gruß bEKAR |
|
|
|
RAII ist der einzige Weg
|
| Sovok schrieb: | ich bin auch gegen smart pointer aus ähnlichem grund wie nep
einfach weil die meißten c++ mit rohen pointern gelernt haben und
die beispiele mit rohen pointern verständlich und durchsichtig sind
dass smart pointer in realer umgebung sinnvoller sind ist richtig aber
ein ganz anderes thema |
Tut mir leid aber das ist großer Mist.
Zum einen würde es sicher ausreichen kurz zu erläutern, was ein smart pointer ist.
Beu Tutorials ist es wichtig immer den richtigen und sichersten weg zu wählen, damit andere davon lernen können. Warum also nicht smart pointer benutzen. An der Verständnis kann es sicherlich nicht liegen, denn:
Foo *bar = new Foo();
bar->blub()
oder
auto_ptr<Foo>bar(new Foo());
bar->blub();
ist alles andere als ein riesiger schwer zu verstehende Unterschied.
Das einzige was nötig wäre, ist dem Leser kurz zu vermitteln was so ein Zeiger Container macht. Also bei zerstörung des containers automatisch den Inhalt freigeben und somit Speicherlecks zu verhindern und ansonsten die Nutzung des Objektes wie immer von statten geht.
Das ist ebenso verständlich wie mit rohen pointern plus zusätzlicher Sicherheit. Solche Grundlegenden Dinge sollten auch in so einem Tut genutzt und wenn nötig kurz erklärt werden.
Wenn etwas beibringen, dann auch richtig.
Schöne Grüße |
|
|
|
Sovok
|
ich bin auch gegen smart pointer aus ähnlichem grund wie nep
einfach weil die meißten c++ mit rohen pointern gelernt haben und
die beispiele mit rohen pointern verständlich und durchsichtig sind
dass smart pointer in realer umgebung sinnvoller sind ist richtig aber
ein ganz anderes thema |
|
|
|
Mr. N
|
| nep schrieb: | Aha...
Nun ja, warum soll ich da Smart Pointer reinbringen? Das verwirrt viele Leute eher, da eher wenige Leute mit SmartPointer arbeiten, und ich mich auch nicht zu sehr auf C++ fokussieren wollte.
Und wenn man mit Polymorphie arbeitet, dann muss das Zeugs nun mal dynamisch allokiert werden |
Smart-Pointer wären IMHO besser, ja. Dieses schreckliche übermäßige Verwenden von rohen Pointern, obwohls in C++ nicht nötig ist, sorgt in meiner Erfahrung für enorm viele Fehler.
Zum Thema "nicht auf C++ fokussieren"... wenn du C++ nicht nutzen willst, nimm ne andere Sprache, aber bitte kein verkrüppeltes C++. |
|
|
|
nep
|
Aha...
Nun ja, warum soll ich da Smart Pointer reinbringen? Das verwirrt viele Leute eher, da eher wenige Leute mit SmartPointer arbeiten, und ich mich auch nicht zu sehr auf C++ fokussieren wollte.
Und wenn man mit Polymorphie arbeitet, dann muss das Zeugs nun mal dynamisch allokiert werden |
|
|
|
Don06
|
Vielleicht hat er früher mal Java/C# oder ähnliches programmiert. Sowas sieht man oft, das solche Leute dann mit Value-Semantik und RAII Probleme haben.
Gruß
Don06 |
|
|
|
Mr. N
|
Wieso ist eigentlich alles auf dem Heap? Und dann auch noch ohne Smart-Pointer?
Das ist doch ein sicheres Rezept für unnötige Fehler! |
|
|
|
|
|
|
|
|
Twitter
Facebook