Fun-Soft - Programmierforum

Autor

Thread - Seiten: > 1 <

000
20.09.2006, 16:56 Uhr
gipfelstuermer

Hallo,
ich habe in meiner Header-Datei folgende Sachen drin.

C++:

struct Daten{
int eins;
int zwei;
};

struct Daten getText(string )

Wie sieht denn die Rückgabe von Strukturen aus? Habe auch

C++:

Daten getText(string)

versucht, aber hat nicht geklappt. Kann man überhaupt Strukturen zurückgeben? Habe nichts gefunden in Büchern und Internet.

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

001
20.09.2006, 17:23 Uhr
0xdeadbeef
Gott
(Operator)

Gib genauen Code und Fehlermeldungen.
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

002
21.09.2006, 10:40 Uhr
mmc20
puss in boots

hi, einfach so

C++:

// irgendwo im header
typedef struct {
    double x, y;
} tdsDoublePoint;

// dann deine definition
    tdsDoublePoint GetCenter();

// und die implementation
tdsDoublePoint CYourSomething::GetCenter()
{
    tagDoublePoint tmp;
    tmp.x = 0.815;
    tmp.y = 4.711;
    return tmp;
}

structs werden in c++ wie klassen gehandled (wenn ich mich nicht irre)

Dieser Post wurde am 21.09.2006 um 10:44 Uhr von mmc20 editiert.

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

003
21.09.2006, 10:48 Uhr
0xdeadbeef
Gott
(Operator)

Das typedef ist in C++ ziemlich unnötig, und wenns in C ist, wird das nichts mit Klassenmethoden. Also, entweder C++:

C++:

// daten.hh
#include <string> // weil getText einen String erwartet

struct Daten{
  int eins;
  int zwei;
};

Daten getText(std::string const &); // Semikolon nicht vergessen, den string besser als const-Referenz übergeben, das spart Rechenzeit

// daten.cc

#include "daten.hh"

Daten getText(std::string const &s) { // spätestens hier braucht der Parameter einen Namen
  // TODO: Code einfügen
}

Oder, in C:

C++:

//daten.h

struct Daten {
  int eins, zwei;
};

struct Daten getText(char const *); // die Klasse string gibts in C natürlich nicht

// daten.c

#include "daten.h"

struct Daten getText(char const *string) {  // siehe oben
  // TODO: code
}

Nachtrag: Oh, und ein kleiner, subjektiver Tip von mir: Fang bloß nicht mit der ungarischen Notation an, der Code wird sonst verteufelt schnell völlig unüberschaubar.
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra

Dieser Post wurde am 21.09.2006 um 10:49 Uhr von 0xdeadbeef editiert.

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

004
21.09.2006, 12:02 Uhr
stephanw
localhorst

Zitat von 0xdeadbeef:

Nachtrag: Oh, und ein kleiner, subjektiver Tip von mir: Fang bloß nicht mit der ungarischen Notation an, der Code wird sonst verteufelt schnell völlig unüberschaubar.

Ich habe mir gerade nochmal bei Wikipedia die ungarische Notation angesehen. Ich muss sagen, dass die (eigentlich falsch verstandene) von Microsoft angewendete gar nicht so übel ist. Zumindest grob benutzen wir die hier auch für Variablen-Namen. Es ist z.B. praktisch, eine Unterscheidung zwischen Membern und lokalen Variablen zu haben. Ein member erkenne ich sofort an "m_"-Präfix. Auch "n" für ganzzahlige oder "d" für double-Werte lassen schneller erkennen, was es eigentlich ist. Und das trifft nicht nur auf zu große Monster-Klassen oder -Methoden zu. Auch wenn man (wie ich) ein Fan von kleinen Funktionen und Klassen ist und die meisten Funktionen auf einer Bildschirmseite Platz finden, hat man schneller den Überblick. Klar unterstützt mich die IDE, indem sie den Typ anzeigt, wenn der Mauszeiger auf der Variable steht. Aber noch schneller sieht man es eben mit einer Konvention.
Ob die Member nun das Präfix "m_" oder nur "_" haben... darüber kann man sich streiten. Prinzipiell finde ich es aber ganz gut, den Scope sofort zu erkennen. Und Typen zu kennzeichnen, geht ja im Grunde auch nur für Grundsorten der eingebauten Typen, z.B. "n" für ganzzahl, "d" für double, "b" für bool, "s" für Strings.
Oft liest man, dass dies in Sprachen wie Java oder C++ vollkommen überflüssig ist ohne eine echte Begründung dahinter.
Was habt ihr so für Konventionen ? Gar keine ? Andere ?
--
Reden ist Schweigen und Silber ist Gold.

Dieser Post wurde am 21.09.2006 um 12:05 Uhr von stephanw editiert.

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

005
21.09.2006, 12:22 Uhr
J-jayz-Z
Perl Crack ala Carte
(Operator)

Ich mache es prinzipiell so: Klassennamen werden groß geschrieben. Objekte der Klasse haben den selben Namen wie die Klasse nur kleingeschrieben mit evtl. logischen Postfix.
Variablen sehen sonst so aus:

C++:

std::string sName
int iName
double dName
float fName
MyClass myClass
char cName
const char ccName
const int ciName
...

--
perl -Mstrict -Mwarnings -e 'package blub; sub new { bless {} } sub bar {my $self=shift; $self->{bla}="66756e2d736f66742e6465"; return $self->{bla};} my $foo=blub->new();print "Hallo ";print pack("H*",$foo->bar()); print "\n"'

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

006
21.09.2006, 12:33 Uhr
0xdeadbeef
Gott
(Operator)

Was ich einsehe, ist die Kennzeichung von Member-Variablen - das mache ich auch (auch wenn ich in GNU-Manier ein _ hinter den Namen statt ein m_ davor setze) - aber Typpräfixe machen den Code unlesbar und lassen ihn auf Dauer verfilzen. Das Problem mit der ungarischen Notation ist, dass sie den Code sehr unflexibel macht. Nur sehr wenige Leute machen sich die Mühe, jedes mal, wenn sich ein Typ ändert, die Präfixe auszutauschen - und ja, sowas kommt tatsächlich vor. Stell dir zum Beispiel vor, du rechnest mit Datumsangaben herum - zwischen gegorianischem und julianischem Datum hin- und her. Zunächst legst dus so an, dass du taggenau rechnest, irgendwann später kommt aber die Anforderung, auch Tagesteile zu rechnen. Schwupps wird aus m_nDays m_dDays - nur dass du das natürlich nicht an den 500 Stellen des Codes, wo es benutzt wird, änderst. Und was aus lpszString wird, wenn du auf einmal anfängst, mit BSTR zu arbeiten - oder gar mit den T-Makros, die Microsoft zur Unicode-Behandlung eingeführt hat, daran möchte ich nicht mal denken.

Siehe dazu auch: http://thc.segfault.net/root/phun/unmaintain.html
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

007
21.09.2006, 12:54 Uhr
ao

(Operator)

Zitat von stephanw:

Oft liest man, dass dies in Sprachen wie Java oder C++ vollkommen überflüssig ist ohne eine echte Begründung dahinter.

Mit der Sprache hat das m.E. wenig zu tun, aber die Leistungsfähigkeit des verwendeten Editors (Sourcecode Highlighting, Code Completion, Intellisense & Co.) kann die Konventionen ersetzen.

Wobei natürlich klar sein muss, dass man sich von der IDE abhängig macht, wenn man so kodiert, dass nur eine Hochleistungs-IDE das noch "lesbar" darstellen kann. Andererseits wer einmal eine richtig gute moderne IDE eingesetzt hat, z.B. eclipse oder VS 2005, der begibt sich gerne in diese Abhängigkeit, der will gar nichts anderes mehr.

Und die Gefahr besteht, dass wenn die Konventionen fallen, jeder so kodiert, wie er Lust hat. Da muss man aufpassen und eingreifen, bevor das Team-Kuddelmuddel Auswüchse annimmt.

Zitat:

Was habt ihr so für Konventionen ? Gar keine ? Andere ?

In C++ und VB eine vereinfachte Ungarische Notation. In C# orientieren wir uns an den ".NET Guidelines for Names": http://msdn2.microsoft.com/en-us/library/ms229002.aspx

ao

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

008
21.09.2006, 13:02 Uhr
Guybrush Threepwood
Gefürchteter Pirat
(Operator)

Zitat von 0xdeadbeef:

Nur sehr wenige Leute machen sich die Mühe, jedes mal, wenn sich ein Typ ändert, die Präfixe auszutauschen - und ja, sowas kommt tatsächlich vor.

Aber Faulheit ist ja kein wikliches Argument das dagegen spricht.
Ich selbst schreibe auch meisten ein Typenpräfix vor den Variablennamen, weil ich es so einfach übersichtlicher finde. Wenn sich der Typ mal ändern sollte und es wirklich so viele Stellen sind das man das nicht per Hand ersetzten will dann gibt es ja auch Suchen+Ersetzen Funktionen.

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

009
21.09.2006, 13:22 Uhr
stephanw
localhorst

@beefy: ich bin auch kein Verfechter von solchen Sachen, finde es aber (z.B. für Member) sinnvoll. Wenn ich dagegn lpszString lese, drehen sich mir die Fußnägel hoch.

PS: sehr geiler Link :-)
--
Reden ist Schweigen und Silber ist Gold.

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

Seiten: > 1 < [ C / C++ (ANSI-Standard) ]

ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: