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

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

  • B

    Ein schnelles Googeln ergab nix. Gibts einen Grund warum es (anscheinend?) kein restrict im neuen Standard gibt?

    0
  • J

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

    0
  • ?

    Jockelx schrieb:

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

    Sind constexpr, decltype und nullptr nicht mehr vorhanden?

    Lars

    0
  • N

    Jockelx schrieb:

    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?

    0
  • J

    Ups, sry, hab ich Mist geschrieben?
    Ich hatte das so in Erinnerung, dass man extra so Keywords wie 'auto' mit neuer Bedeutung belegt, um Abwärtskompatibel zu bleiben.

    0
  • A

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

    0
  • N

    Ich verstehe nicht, inwiefern man bessere Kompatibilität erreicht, indem man zwar keine Schlüsselwörter, aber dennoch neue Sprachmittel einführt. C++0x wird ohnehin nicht mit einem C++98-Compiler kompilierbar sein, umgekehrt jedoch zum grössten Teil (ausser export etc.)

    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.

    0
  • U

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

    0
  • R

    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

    0
  • N

    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.

    0
  • J

    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.

    0
  • B

    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 😞

    0
  • ?

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

    0
  • N

    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?

    0
  • A

    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?)

    0
  • L

    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 😉

    0
  • V

    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.

    0
  • ?

    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.

    0
  • ?

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

    0
  • A

    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 😉

    0
Anmelden zum Antworten