bool isInRange(int zahl, int untereGrenze, int obereGrenze);

unskilled

ich würds sorum machen:

bool isEven(int zahl) 
{    
    if (zahl%2)
    {
        return false;
    }
    else
    {
        return true;
    }
}

und mich dann fragen: warum englischer bezeichner und deutscher variablenname?
und dann würd ichs einfach so machen:

bool isEven(int number)
{
  return number%2 == 0;
}

bb

kung

da volkard vergessen hat dir 'ne andere Möglichkeit zu zeigen, hole ich das mal nach

#define ERR_UNGERADE "Die Zahl ist ungerade" 
#define ERR_GRENZE  "Die Zahl ist ausserhalb der Grenze" 
//KEINE MAKROS NEHMEN! 

#define OBEREGRENZE (100) 
#define UNTEREGRENZE (50) 
//KEINE MAKROS NEHMEN! Wozu die nutzlosen Klammern?

const std::string ERR_UNGERADE = "Die Zahl ist ungerade";
const std::string ERR_GRENZE = "Die Zahl ist ausserhalb der Grenze";
const int OBEREGRENZE=100;
const int UNTEREGRENZE=50;

1. wegen der Typensicherheit
2. die Variablen können nicht mal ebent durch unachtsam magisch verändert werden.

Predeklarationen sind nur bei soetwas notwendig (oder wenn der Compiler jammert):

void foo();
void bar(){foo();}
void foo(){bar();}

Nexus

Makros haben auch oft die Probleme, die die dumme Textersetzung mit sich bringt (bei einfachen Konstanen vielleicht weniger). Aber es fehlen zum Beispiel auch Debugsymbole.

Ich würde dennoch const char* statt const std::string nehmen , dieser ist nämlich für Stringliterale stark übertrieben.

const char* ERR_UNGERADE = "Die Zahl ist ungerade";
const char* ERR_GRENZE = "Die Zahl ist ausserhalb der Grenze";

nurf

Nexus schrieb:

Ich würde dennoch const char* statt const std::string nehmen , dieser ist nämlich für Stringliterale stark übertrieben.

Hahahahahahahaha ....

Wir wollten ihm doch modernes C++ beibringen. Da nimmt man den std::string!
Genauso wie man std::cout verwendet statt printf.

Nexus

nurf schrieb:

Hahahahahahahaha ....

Wir wollten ihm doch modernes C++ beibringen. Da nimmt man den std::string!
Genauso wie man std::cout verwendet statt printf.

Schade, dass du keine Argumente hast, aber zu den Leuten gehörst, die C++-Mittel prinzipiell besser finden, egal um welches Problem es geht.

Sieh es ein, es gibt an dieser Stelle keinen Grund für std::string , aber eine Menge Gründe dagegen. Benutzt du auch kein <cmath> , weil es das in C schon gab?

Badestrand

Als Pendant zu const std::string würde ich hier const char* const (statt const char* ) nehmen, wegen unveränderbar und so. Und std::string hat hier auch Vorteile, z.B. string.length, rbegin/rend, die find-Methoden usw. Muss man natürlich schauen, wenn man's nicht braucht (was ja meistens der Fall ist), reicht auch der Zeiger.
Oh, und vorteilhaft ist es auch bei der Übergabe an Funktionen, die const std::string& nehmen, damit nicht jedesmal eine Kopie erzeugt wird.

nurf

Nexus schrieb:

Sieh es ein, es gibt an dieser Stelle keinen Grund für std::string , aber eine Menge Gründe dagegen. Benutzt du auch kein <cmath> , weil es das in C schon gab?

Ja dann mal her mit den Gründen, scheint mir eher tief verwurzelter Aberglaube zu sein.

nurf schrieb:

Nexus schrieb:

Sieh es ein, es gibt an dieser Stelle keinen Grund für std::string , aber eine Menge Gründe dagegen. Benutzt du auch kein <cmath> , weil es das in C schon gab?

Ja dann mal her mit den Gründen, scheint mir eher tief verwurzelter Aberglaube zu sein.

Hmm, das ist ne fixe Meldung, du wirst die jetzt nicht nach irgendwlchen Zeichen durchsuchen wollen, oder sonst was damit anstellen, wofür du die ganze Macht der string-Klasse benötigst. Du willst einfach einen unveränderlichen Text, dafür ist das minimale Mittel ein "const char*". Deshalb spricht einiges dafür. Und das sollte auch reichen.

Oder hast du jetzt deine "Aussage" auf den Teil mit cmath bezogen? Ich hoffe zutiefst dass du einfach zu faul warst den quote zu bearbeiten...

Nexus

@ Badestrand:
Hm ja. std::string hat schon an manchen Orten Vorteile, aber ihn grundsätzlich immer zu empfehlen, nur weil er C++ ist, finde ich nicht gut.

Schlimm finde ich sowas:

void MyClass::OpenFile(const std::string& FileName)
{
    FileStream.open(FileName.c_str());
}

int main()
{
    MyClass x;
    x.OpenFile("file.txt");
}

Je nachdem wäre es sogar eine Überlegung wert, eine eigene Klasse für solche unveränderlichen Strings zu erstellen. Geht zwar auch ohne, aber wenns um Optimierung geht, könnte sowas schon praktisch sein.

nurf schrieb:

Ja dann mal her mit den Gründen, scheint mir eher tief verwurzelter Aberglaube zu sein.

Okay, da du scheinbar immer noch keine Argumente dafür hast: Du brauchst die String-Funktionalität in vielen Fällen gar nicht! Ein std::string hat eine dynamische Speicherverwaltung, Wachstumssemantik mit Grösse und Kapazität, oft auch gespeicherte Iteratoren, also einen rechten Overhead. sizeof(std::string) ist bei mir im Release-Modus 28, das ist nicht selten mehr als überhaupt als Text gespeichert wird (in Anwendungsfällen von Stringliteralen).

Natürlich kann man sich auch grundsätzlich nicht um solche Überlegungen kümmern und alles als Premature Optimization abtun. Am besten dabei ständig nach dem Dogma "C ist grundsätzlich schlecht, man muss in jedem Fall C++ nutzen" handeln und gleichzeitig anderen Aberglaube unterstellen. Naja...

hustbaer

C++ Strings sind grundsätzlich "broken". Man sollte sie trotzdem vielerorts verwenden, weil sie halt Standard sind, und ein schlechter Standard immer noch besser ist als 100 String-Klassen von 100 Libraries in einem Projekt (*kotz*).

Für Fehlermeldungs-Konstanten finde ich std::string aber auch nicht gerade "nötig".

const char* const hat sogar einen wichtigen Vorteil, wenn es um statische String Konstanten geht: es benötigt keine Konstruktoren -> kein "static initialization order fiasco".

nurf schrieb:

Hahahahahahahaha ....

Wir wollten ihm doch modernes C++ beibringen. Da nimmt man den std::string!
Genauso wie man std::cout verwendet statt printf.

Lachst du dich hier selbst aus, weil du weisst was du gleich für Unsinn ablassen wirst?