wird C++0x ein 'restrict' keyword haben?

unskilled

asc schrieb:

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.. ^^

rüdiger

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

Nexus

unskilled schrieb:

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.

Jockelx

Nexus schrieb:

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.

Blue-Tiger

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.

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

Sehr schade

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.

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...

Nukularfüsiker

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?

audacia

Es würde mich gar nicht wundern, wenn inline mal "deprecated"* wird; die Compiler sind schließlich ohnehin recht gut in der Lage, die Sinnhaftigkeit einer Inline-Expansion abzuschätzen. Und sicherlich fällt irgendjemandem eine kreative Überladung dafür ein, die etwa so viel mit Inlining zu tun hat wie delete mit Standardkonstruktoren oder enum mit class .

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

LordJaxom

Nukularfüsiker schrieb:

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

volkard

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.

Für überflüssig halte ich "inline" nicht. Denn die "one definition rule" enthält ja auch Sonderregeln für inline-Funktionen. ZB dürfen diese mehrfach definiert werden, solange das in verschiedenen Übersetzungseinheiten passiert. Das ist natürlich praktisch, da der Compiler es einfacher hat, zu "inlinen", wenn die Definition bekannt ist. Bei Compilern/Linkern, die keine "link time optimization" durchführen (was praktisch die Regel ist) müsste man sich sonst mit static behelfen, wenn das inline-Schlüsselwort abgeschaft werden würde. In C wär das kein großer Verlust, da es in C keine Sonderregeln für inline gibt. Aber in C++ würde ich es vermissen, inline-Funktionen mit externer Bindung in mehreren ÜEs definieren zu können.

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

audacia

LordJaxom schrieb:

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

Dravere

volkard schrieb:

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

Nexus

Optimizer schrieb:

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.

volkard

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.

unskilled

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ß".

bb

rüdiger

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. 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);

volkard

rüdiger schrieb:

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?

Bashar

volkard schrieb:

Würde restricted auch ausdrücken, da0 p+17 != q+29?

Wenn das in der Funktion relevant ist, ja.