Enums wie unter Visual Basic benutzen?

Hallo Forum,

würde sich C++ wie VB verhalten ginge das:

enum CryptMethod {
	Encrypt,
	Decrypt
};

void Xcrypt(char *Key, char *BufferIn, char *BufferOut, CryptMethod Method) {
...
}

int main(void) {
Xcrypt("key", "ToEncrypt", "     ", Encrypt);
}

Das dieses kein vernünftiger C++ Code ist, ist mir klar. Warum kann ich bei der Definition von Funktion Xcrypt() nicht als Variablentyp den Enum eingeben? Der Kompiler braucht/kann die Eingabewerte nicht einengen, weil der Enum vermutlich ein int ist, aber so wäre dem Benutzer klar welchen Parameter ich als letztes erwarte und welche Eingaben gültig sind.
Wird das unter C++ anders geregelt?

Ben04

Entweder ich übersehe etwas ganz blödes oder das ist gültiger C++ Code.

Braunstein

Was für ein Fehler kommt denn?

Simon2

Ben04 schrieb:

Entweder ich übersehe etwas ganz blödes oder das ist gültiger C++ Code.

... oder gültiger C-Code.

Gruß,

Simon2.

Oh, dann geht das doch so. Ich kann meinen Source momentan nicht kompilieren. Wenn ich das Beispiel aber in ein neues Projekt einfüge funktioniert es. Mein Fehler...

CStoll

Der Code ist in C und C++ vollkommen korrekt, dürfte dir allerdings zur Laufzeit um die Ohren fliegen. Aber das liegt nicht an dem enum, sondern daran, daß du String-Literale als char* übergeben willst.

Simon2

Hups - stimmt !
Ich hatte mich auf den "enum-Teil" gestürzt und das ganz übersehen.
Bei "Key" und "BufferIn" kann es noch klappen (obwohl ich dringenst jeweils ein "const" anraten würde), aber spätestens beim "BufferOut" geht's in die Hose...

Zum 100stedn Mal (nicht für martin_salo, aber für das Forum ;)): Nimm erstmal string statt char* !

Gruß,

Simon2.

pumuckl

Simon2 schrieb:

Zum 100stedn Mal (nicht für martin_salo, aber für das Forum ;)): Nimm erstmal string statt char*

Das liegt vermutlich an den (bestimmt ueber 100) Buechern, die C++ ueber C einfuehren und strings erst so spaet drannehmen, dass auch die C++-Beispiele noch mit const char*, sprintf und anderem Kram arbeiten, der in C++ fast ausschliesslich aus Kompatibilitaetsgruenden vorhanden ist.

Simon2

Weiß ich wohl .. ist aber traurig genug.

Gruß,

Simon2.

Ich weiß gar nicht wo dabei das problem ist.
Mir z.B. ist es viel lieber einen wchar_t pointer zu benutzen und dann
wcscat und so weiter zu benutzen, da weiß man was man hat.
(n büsken paranoid, wa)
Und sicherheitstechnisch gibt es da auch keine probleme, da ich da die
microsoft _s version verwende(wer will schon einen anderen compiler mit ner anderen lib benutzen?)

Simon2

Dennis123_ schrieb:

Ich weiß gar nicht wo dabei das problem ist....

- (portabler) Schutz gegen Bufferüberschreitungen ?
- lesbarere Syntax ?
- mitgelieferte Speicherverwaltung ?
- direkte Unterstützung aller anderer StdLib-Features ?
- ...

Um nur mal die ersten 4 Vorteile von std::string zu nennen, die mir einfallen.

Gruß

Simon2.

LordJaxom

Dennis123_ schrieb:

Ich weiß gar nicht wo dabei das problem ist.
Mir z.B. ist es viel lieber einen wchar_t pointer zu benutzen und dann
wcscat und so weiter zu benutzen, da weiß man was man hat.
(n büsken paranoid, wa)

Da weiß man auch, dass man immer wieder dieselben Probleme (Exceptionsafety, um eins zu nennen) auf dieselbe Weise umschiffen muss. Eine String-Klasse muss das genau einmal und wird dann nur noch verwendet.

Also manchmal verstehe ich echt nicht warum Leute immer wieder absichtlich auf Hilfe verzichten.

Und sicherheitstechnisch gibt es da auch keine probleme, da ich da die
microsoft _s version verwende(wer will schon einen anderen compiler mit ner anderen lib benutzen?)

D.h. Du programmierst nicht wirklich C++, Du programmierst noch nichtmal wirklich C, sondern einen MS-Pseudostandard. Wenn Du meinst, dass dies gute Attribute für Deine Programmierkünste sind, bitte :p

Simon2

LordJaxom schrieb:

...
Also manchmal verstehe ich echt nicht warum Leute immer wieder absichtlich auf Hilfe verzichten....

Ich glaube, "viele Leute" (mich eingeschlossen) befinden sich zwischendurch immer wieder mal auf "Lernplateus": Man hat einen Satz an Standardtechniken/-vorgehen, mit dem man alle seine derzeitigen Aufgaben bewältigen kann .... und ist nicht ständig auf der Suche (und am Experimentieren/Lernen) nach neuen Techniken.
Idealerweise geht's möglichst bald "weiter" und so ein Post hier kann ein Anstoß dazu sein....

Ic muss immer an meine Mutter denken: Als ich ca. 17 war, "wusste" ich eine Menge besser als sie (dachte ich) und ich erklärte ihr, wie sie effizienter den Abwasch erledigen könnte. Sie sagte mit milder Stimme (eher untypisch für sie ;)): "Weißt du: Du hast bestimmt recht ! Es ginge bestimmt ein wenig schneller ... aber es ist für mich viel umständlicher, meine Routine zu ändern als die paar Minuten am Tag es wert sind." (und dabei hatte meine Mutter durchaus Freude am "Neulernen" ... aber eben nicht auf dem Gebiet des Abwaschens)....

Gruß,

Simon2.

Nunja lernressistent bin ich eigentlich nicht

Also die std::string s habe ich ja auch schon bei projekten eingesetzt, wo es einfach ein zu großer aufwand ist die strings zu verwalten, d.h., dass es viele referenzen von weißgottwoher auf die strings gibt, dabei nehme ich naürlich die hilfe gern an.

Bei sachen wie der WinAPI oder anderen C APIs, die nunmal einen C-string erwarten, oder sogar einen solchen zurückgeben(WCHAR[MAX_PATH]...) ist es halt komfortabler mit dem C-String zu arbeiten, da ich bei std::string s entweder c_str() machen müsste, oder bei funktionen, die einen buffer erwarten die sache doppel gemoppelt ausführen müsste.

Simon2

Hi,

also wenn Du std::strings kennst/verwendest und nur in begründeten Ausnahmefällen auf C-Strings zurückgreifst, bist Du gar nicht Zielgruppe dieses Appells.
Hier tauchen leider haufenweise Leute auf, auf die das nicht zutrifft und die (tw. mit den skurrilsten Begründungen) C-Strings verwenden.

Leider können wir das bei unregistrierten oder neuen Usern noch nicht unterscheiden.

Gruß,

Simon2.