Die Funktion tolower aus der Bibliothek ctype.h gibt mir einige Rätsel auf. Die Funktion soll ja bei einem eingegeben großem "T" ein kleines "t" zurückliefern. Komischerweise tut es das aber bei mir nicht. Ich gebe ein "T" (also, 084 in ASCII) ein, zurück bekomme ich aber ein "'". Ich weiß nicht was ich falsch mache.

Könnt ihr mir helfen?

#include<iostream>
#include<ctype.h>
using namespace std;

char func()
{
char tolower(char c);
}

int main()
{
 char c;

 cin >> c;

 cout << func();

system("pause");
return 0;
}

Das ist eine Funktionsdeklaration. Schau in deinem C++-Buch am besten nochmals genau nach, wie eine Funktion aufgerufen wird. Und wie das mit den Scopes funktioniert, könntest du auch gleich nachlesen

#include<iostream>
#include<ctype.h>
using namespace std;

char func(char c)
{
return tolower(c);
}

int main()
{
 char c;

 cin >> c;

 cout << func(c);

system("pause");
return 0;
}

Eventuell hilft dir das ja.
MfG, Jochen

#include <locale>

template <class charT>
charT func(charT c)
{
  static std::locale loc;
  return std::tolower(c, loc);
}

Ich hab mir Funktionenaufruf angesehen. Ich kann's ja eigentlich auch. Hier ein kleines Beispiel. Ich weiß nur nicht warum das mit der tolower-Funktion nicht geht...

Mein Beispiel:

#include<iostream>
#include<ctype.h>
using namespace std;

int func(int x, int y)
{
    int ergebnis;
    ergebnis = x+y;
}

int main()
{
 int a, b;

 cin >> a >> b;

 cout << func(a, b);

system("pause");
return 0;
}

#include<iostream>
#include<ctype.h>
using namespace std;

char func(char c)
{
return tolower(c);
}

int main()
{
 char c;

 cin >> c;

 cout << func(c);

system("pause");
return 0;
}

Warum darf ich an der Stelle "return tolower(c);" nicht "return tolower(char c);" schreiben? Ist das dann an der Stelle wie eine Doppeldeklaration?

Ich hab mir Funktionenaufruf angesehen. Ich kann's ja eigentlich auch. Hier ein kleines Beispiel. Ich weiß nur nicht warum das mit der tolower-Funktion nicht geht...

Nochmals: Weil du eine Funktionsdeklaration statt eines Funktionsaufrufs hingeschrieben hast.

bandchef schrieb:

Warum darf ich an der Stelle "return tolower(c);" nicht "return tolower(char c);" schreiben? Ist das dann an der Stelle wie eine Doppeldeklaration?

Gesteh dir doch ein, dass dir hier noch einige Kenntnisse fehlen. Lies das Kapitel nochmals nach, das beschreibt, wie Funktionen deklariert, definiert und aufgerufen werden. Du verwechselst hier einiges.

Rochen schrieb:

Der Vollständigkeit halber: so macht man es in C++

Das Template finde ich etwas übertrieben.

Mein Beispiel:

#include<iostream>
#include<ctype.h>
using namespace std;

int func(int x, int y)
{
    int ergebnis;
    ergebnis = x+y;
}

int main()
{
 int a, b;
 
 cin >> a >> b;
 
 cout << func(a, b);
 
system("pause");
return 0;
}

Das funktioniert doch auch nicht!

Das funktioniert doch auch nicht!

Vielleicht zufällig doch, undefiniertes Verhalten. Es ist hier durchaus denkbar, dass das berechnete Ergebnis in dem Register liegt, in dem auch die Rückgabe stehen würde, wenn es sie gäbe.

Ein moderner Compiler würde sowas nicht mal kompilieren.

Ja, aber nur weil system nicht deklariert ist.
Nimmt man diese Zeile raus, kommen Warnungen erst bei -Wall, kompillieren tut er es erst nicht mehr bei einem zusätzlichen -Werror. Mein Compiler ist `gcc version 4.4.5 (Debian 4.4.5-10)', ich sehe ihn als sehr modern an.

Mein Compiler ist `gcc version 4.4.5 (Debian 4.4.5-10)', ich sehe ihn als sehr modern an.

Ich hingegen sehe es als Bug an, wenn man in einer Funktion mit Rückgabewert int kein return -Statement haben muss.

Ein moderner Compiler würde sowas nicht mal kompilieren.

Du meinst, ein buggy Compiler? Was für einen Grund sollte ein Compiler sonst haben, sich mutwillig über den Standard hinwegzusetzen?

Bashar schrieb:

Du meinst, ein buggy Compiler? Was für einen Grund sollte ein Compiler sonst haben, sich mutwillig über den Standard hinwegzusetzen?

Weil er auf diese Weise offensichtliche Fehler vermeidet, auch ohne dass dies im Standard explizit steht. Ich sehe nicht, wieso du das so dramatisch als "mutwillig darüber hinweggesetzt" bezeichnest. Ich bin sehr froh über gemeldete Fehler zur Kompilierzeit, hier schadet die Meldung wirklich nichts.

Oder hast du etwa einen sinnvollen Anwendungsfall?

int f1()
{
	_asm
	{
		mov eax, 20; <- Edit: Gewohnheitssemikolon
	}
}

Einen anderen Fall kenne ich aber nicht.

Da ich davon ausgehe, dass du als errorphiler (fehlerliebender) Programmierer eh unter -pedantic -Wall -Wextra -Werror kompillierst

Nein, ich benutze Visual Studio.

ModernerKompailerNutzer schrieb:

hast du das Problem gar nicht und kannst den nicht ganz so radiklen Programmierern die Freiheiten lassen, die C++ einem gewährt. Jedem das Seine.

Ja. Nur schade, dass diese Regel eine weitere unnötige Fehlerquelle in C++ ist, die Anfängern, welche standardmässig nicht 4 Spezialflags an g++ übergeben, Sorgen bereitet. Ich war jedenfalls schon ab und zu froh um diese Fehlermeldung.

Vicious Falcon schrieb:

Sinnvoll kann es dann sein, wenn der Programmier weiß, was er macht.

int f1()
{
	_asm
	{
		mov eax, 20; <- Edit: Gewohnheitssemikolon
	}
}

Einen anderen Fall kenne ich aber nicht.

Lustig ist, dass VS genug intelligent ist, diesen Fall zu erkennen und keinen Fehler zu verursachen. Also genau wie es sein sollte

Nicht immer ist alles schlecht, was sich nicht an den Standard hält. Es wäre zum Beispiel von Vorteil gewesen, hätten einige Standardbibliotheken den Bug von std::bind1st und std::bind2nd nicht implementiert. Naja, mit std::bind ist das Thema eh vom Tisch.

Ich dachte, das würde so im C++-Standard stehen, aber es ist tatsächlich "nur" undefiniertes Verhalten.

Aber auch nur, wenn die Ausführung tatsächlich das Ende der Funktion erreicht. In dem Beispiel mag das ja so sein, aber im Allgemeinen ist das gar nicht möglich, das zu erkennen.

Einfaches Beispiel, um das zu verdeutlichen:

bool p();
void g();
int f() {
  if (p())
    return 0;
  else
    g(); // kein return? ja, aber ... s.u.
}

void g() {
  throw 1;
}

Man kann also nicht in den Standard reinschreiben, dass der Compiler sowas erkennen muss. Und wenn man es auf die Fälle beschränkt, wo es möglich ist (geht das?), kann man es auch gleich sein lassen.

Oder hast du etwa einen sinnvollen Anwendungsfall?

Nö, aber darum geht es ja auch nicht.

Lustig ist, dass VS genug intelligent ist, diesen Fall zu erkennen und keinen Fehler zu verursachen.

Ja, der VC 6 hat immer noch eine Warnung ausgespuckt, die neueren MS-Compiler sind wirklich verdammt gut .

Aber auch nur, wenn die Ausführung tatsächlich das Ende der Funktion erreicht. In dem Beispiel mag das ja so sein, aber im Allgemeinen ist das gar nicht möglich, das zu erkennen.

Da sind wir uns völlig einig. Aber ich sagte ja: "Ich hingegen sehe es als Bug an, wenn man in einer Funktion mit Rückgabewert int kein return -Statement haben muss." Und da hat es ein return . Sobald ein return oder throw in der Funktion vorkommt, kompiliert der Code auch unter VS. Hingegen kann eine Funktion, die immer eine Exception wirft, ruhig void als Rückgabetyp haben.

Falls man doch dem Fall begegnet, in dem man unbedingt einen Rückgabetyp ohne Rückgabewert haben muss, kann man den Fehler immer noch zu einer Warnung umwandeln. Das finde ich um einiges sinnvoller, als in 99% der Fälle Programmfehler kompilieren zu lassen.

Aber ich sagte ja: "Ich hingegen sehe es als Bug an, wenn man in einer Funktion mit Rückgabewert int kein return -Statement haben muss." Und da hat es ein return .

In einer Verzweigung ja, in der anderen nicht. Wenn dich stört, dass g immer wirft, kannst du das Beispiel beliebig komplizierter machen, z. B. als nächste Stufe

bool p();  // gibt abwechelnd true und false zurück
void g();
int f() {
  if (p())
    return 0;
  else
    g(); // kein return? ja, aber ... s.u.
}

void g() {
  if(p())
    throw 1;
}