Es wird überhaupt keine neuen Schlüsselwörter geben, wegen der Abwärtskompabilität.

Sind constexpr, decltype und nullptr nicht mehr vorhanden?

Lars

Es wird überhaupt keine neuen Schlüsselwörter geben, wegen der Abwärtskompabilität.

Aber sonstige neue Sprachmittel wird es trotz der Abwärtskompabilität geben?

Es wird überhaupt keine neuen Schlüsselwörter geben, wegen der Abwärtskompabilität.

Die Aussage ist Unsinn, denn auch die Änderung (was sogar noch viel extremer ist) von bestehenden Schlüsselwörtern wird durchgeführt: z.B. auto.

Ja, auto wird von kaum einen Verwendet, aber wehe wenn doch - der wird sich wundern...

Neue Schlüsselwörter wären z.B. auch static_assert oder noexcept . Soweit ich weiss, ist constexpr rausgefallen, weil es einige Probleme mit momentanen Sprachkonzepten verursacht.

Jockelx schrieb:

Es wird überhaupt keine neuen Schlüsselwörter geben, wegen der Abwärtskompabilität.

Die Aussage ist Unsinn, denn auch die Änderung (was sogar noch viel extremer ist) von bestehenden Schlüsselwörtern wird durchgeführt: z.B. auto.

Ja, auto wird von kaum einen Verwendet, aber wehe wenn doch - der wird sich wundern...

was macht auto denn bisher?
iwie bin ich zu doof zum googlen.. ^^

edit: http://groups.google.com/group/comp.std.c++/browse_thread/thread/bd0d091ff854e6fc/260de565404c79df

was macht auto denn bisher?

Es bezeichnet die automatische Speicherklasse (neben den Speicherklassen extern , static und register ).

int main()
{
    auto int i;
}

Nur schreibt es niemand, weil man es gerade so gut weglassen kann.

Ich verstehe nicht, inwiefern man bessere Kompatibilität erreicht, indem man zwar keine Schlüsselwörter, aber dennoch neue Sprachmittel einführt.

Damit man halt noch alten Code wie

int restrict = 0;
long newkeyword = 42;

kompilieren kann.
Aber ich hab meinen Fehler ja längst eingeräumt.

Nein, restrict wird es leider nicht geben. Ich weiß auch nicht warum. Vorallem wird es ja bereits von vielen Compilern unterstützt und ist imho ein sehr sinnvolles Feature.

edit: http://groups.google.com/group/comp.std.c++/browse_thread/thread/bd0d091ff854e6fc/260de565404c79df

Sehr schade

Nein, restrict wird es leider nicht geben. Ich weiß auch nicht warum. Vorallem wird es ja bereits von vielen Compilern unterstützt und ist imho ein sehr sinnvolles Feature.

Dazu hat der liebe Gott #ifdef erfunden

Ansonsten finde ich die Begründung

Having a feature in the standard that can't be tested for conformance and that has no semantics associated with it (a compiler can ignore restrict without changing the behavior of a valid program) seemed inappropriate.

etwas albern...

Having a feature in the standard that can't be tested for conformance and that has no semantics associated with it (a compiler can ignore restrict without changing the behavior of a valid program) seemed inappropriate.

Das trifft doch genauso auf inline zu, nicht wahr?

(*: Hat jemand eine brauchbare Idee, wie man "to deprecate" ohne Klimmzüge wie "für veraltet erklären" im Deutschen ausdrücken könnte?)

Tim schrieb:

Having a feature in the standard that can't be tested for conformance and that has no semantics associated with it (a compiler can ignore restrict without changing the behavior of a valid program) seemed inappropriate.

Das trifft doch genauso auf inline zu, nicht wahr?

Nicht ganz. Inline ermöglicht, Funktionen in Headern zu definieren und dennoch die ODR einzuhalten. Das darf der Compiler auch nicht ignorieren. Er darf allerdings entscheiden, diese Funktionen nicht zu inlinen.

audacia schrieb:

(*: Hat jemand eine brauchbare Idee, wie man "to deprecate" ohne Klimmzüge wie "für veraltet erklären" im Deutschen ausdrücken könnte?)

Wörtlich: missbilligen

Nein, restrict wird es leider nicht geben. Ich weiß auch nicht warum. Vorallem wird es ja bereits von vielen Compilern unterstützt und ist imho ein sehr sinnvolles Feature.

Das sehe ich anders. Aber sowas von.

audacia schrieb:

(*: Hat jemand eine brauchbare Idee, wie man "to deprecate" ohne Klimmzüge wie "für veraltet erklären" im Deutschen ausdrücken könnte?)

Wörtlich: missbilligen

Ja, bei LEO kann ich auch selbst nachschlagen

rüdiger schrieb:

Nein, restrict wird es leider nicht geben. Ich weiß auch nicht warum. Vorallem wird es ja bereits von vielen Compilern unterstützt und ist imho ein sehr sinnvolles Feature.

Das sehe ich anders. Aber sowas von.

Könntest du das etwas näher ausführen? Wieso erachtest du es nicht als sinnvolles Feature?

@audacia,
"deprecaten"
Aber wenn du schon auf LEO schauen gehen kannst, dann schau doch auch im Forum nach. Hat da zum Teil ganz interessante Diskussionen zu solchen Wörtern. Zum Beispiel auch für deprecated.

Grüssli

Interessant wär's doch sicher auch mal, register zu kicken, oder? Auf sowas hat die Welt glaub ich damals schon nicht gewartet.

Es wäre auch weniger hart für auto , wenn gleich zwei Speicherklassenschlüsselworte in den Ruhestand träten.

Könntest du das etwas näher ausführen? Wieso erachtest du es nicht als sinnvolles Feature?

Weil ich das prinzipiell nur dem Compiler aufhalsen will. Ok, geht nur oft, aber nicht immer. Naja, dann soll es gerne Compilerlokal sein. MS wird vielleicht mit #pragma machen und GCC vielleicht mit __restricted__ oder doch andersrum. Das hat man ja schnell weggemakrot, falls man zufällig für beide entwickelt.

Dravere schrieb:

Könntest du das etwas näher ausführen? Wieso erachtest du es nicht als sinnvolles Feature?

Weil ich das prinzipiell nur dem Compiler aufhalsen will.

Was spricht denn überhaupt für das Nutzen des keywords, so fern es es denn geben würde? Mir würde gerade keine Situation einfallen, wo der Compiler das nicht von alleine schon "weiß".

bb

Dravere schrieb:

Könntest du das etwas näher ausführen? Wieso erachtest du es nicht als sinnvolles Feature?

Weil ich das prinzipiell nur dem Compiler aufhalsen will. Ok, geht nur oft, aber nicht immer. Naja, dann soll es gerne Compilerlokal sein. MS wird vielleicht mit #pragma machen und GCC vielleicht mit __restricted__ oder doch andersrum. Das hat man ja schnell weggemakrot, falls man zufällig für beide entwickelt.

Der Compiler kann Aliasing höchstens erkennen, wenn er Funkionen inlined. Das C99 restrict eingeführt hat, kommt ja aus der Praxis. Vorallem weil die Scientificcomputing-Leute sich darüber geärgert haben, dass die Fortran-Compiler teilweise besseren Code generieren konnten (Fortran hat kein Aliasing-Problem). Mittlerweile gehen einige Compiler so weit und generieren Code der Aliasing berücksichtigt und Code der davon ausgeht, dass kein Aliasing auftritt und fügen dann eine Laufzeitüberprüfung ein, welcher Code genommen werden soll. Dies ist natürlich alles andere als optimal, da es den Code aufbläht und man eine Laufzeitüberprüfung braucht. Und warum sollte restrict nicht einfach standardisiert sein? Dann spart man sich die Macrofrickeleien und den Kampf mit kleinen Unterschieden.

unskilled schrieb:

volkard schrieb:

Dravere schrieb:

Könntest du das etwas näher ausführen? Wieso erachtest du es nicht als sinnvolles Feature?

Weil ich das prinzipiell nur dem Compiler aufhalsen will.

Was spricht denn überhaupt für das Nutzen des keywords, so fern es es denn geben würde? Mir würde gerade keine Situation einfallen, wo der Compiler das nicht von alleine schon "weiß".

void a(int *p, int *q);

void a(int *p, int *q);

Ausdrücken, daß p!=q?
Kein Problem!

void a(int *p, int *q)
{
   ASSERT(p!=q);
}

Hier kommt erstmal nur raus, daß dem GCC das __assume fehlt. Keine Ahnung, warum es fehlt. Ich vermute religiöse Gründe.
Würde restricted auch ausdrücken, da0 p+17 != q+29?