Das ist das Ende von C++!

[Simon2]

Phoemuex schrieb:

...Es ist zwar auf einer "freestanding"-Implementierung nicht vorhanden, ...

und selbst das ist IIRC nicht der Fall: Es ist nur erlaubt, sie da wegzulassen.
Ich bin ja mal gespannt, welchen Komfort D auf solchen Systemen bieten wird....

Gruß,

Simon2.

[Gast]

Simon2 schrieb:

Phoemuex schrieb:

...Es ist zwar auf einer "freestanding"-Implementierung nicht vorhanden, ...

und selbst das ist IIRC nicht der Fall: Es ist nur erlaubt, sie da wegzulassen.

Genau so isses.

Simon2 schrieb:

Ich bin ja mal gespannt, welchen Komfort D auf solchen Systemen bieten wird....

*g*

[Artchi]

Es ist zwar auf einer "freestanding"-Implementierung nicht vorhanden,

Was soll das heißen?

[Gast]

Dass gewisse Teile des C++ Standards für eine "freestanding implementation" optional sind. Dazu gehört z.B. std::string und std::vector.

Two kinds of implementations are defined: hosted and freestanding. For a hosted implementation, this International Standard defines the set of available libraries. A freestanding implementation is one in which execution may take place without the benefit of an operating system, and has an implementationdefined set of libraries that includes certain languagesupport
libraries (17.4.1.3).

[Artchi]

Hem... also wenn ich mir so den zweiten Satz durchlese, passt das mit deinem "Optional" nicht. Oder ich verstehe unter Optional was anderes? Optional heißt für mich, das ich es ab- und anwählen kann und somit nicht vorhanden sein kann. (z.B. ich bestlle eine Ausstattung bei einem Auto, lasse aber die Klimaanlage weg, halt Option)

Aber der zweite Satz über freestanding sagt das doch garnicht aus? Er besagt (wenn ich es richtig interpretiere) das die Implementierung auf einer anderen Bibliothek bzw. anderen Code basieren kann. Z.B. kann ich mir vorstellen, das std::basic_string mittels der ganzen C-Style-Stringfunktionen implementiert wird. Und das z.B. einige Funktionen selbst programmiert werden, ohne z.B. direkt die OS-API zu nutzen. Also das jemand freie Hand über die Implementierung hat.

freestanding heißt ja "freistehend", also dem Implementierer ist es frei über die Implementierung zu bestimmen.

Aber das z.B. string und vector einfach nicht mitgeliefert werden können, das kann ich daraus nicht lesen.

[Gast]

Optional im Sinne von "muss nicht aber kann".

Aber mal etwas mehr quoten um sicher zu gehen:

A freestanding implementation has an implementationdefined set of headers. This set shall include at least the following headers, as shown in Table 13:

Table 13 listet das auf:

<cstddef>
<limits>
<cstdlib>
<new>
<typeinfo>
<exception>
<cstdarg>

Und noch einen Zusatz:

The supplied version of the header <cstdlib> shall declare at least the functions abort(), atexit(), and exit() (18.3).

(wobei ich die Forderung von <new> eigentlich schon albern finde. Eine freestanding implementation in C fordert nichtmal malloc und co. Vielleicht kann mir das ein C++ler erklären)

[rüdiger]

TactX schrieb:

(wobei ich die Forderung von <new> eigentlich schon albern finde. Eine freestanding implementation in C fordert nichtmal malloc und co. Vielleicht kann mir das ein C++ler erklären)

Geht wohl eher um Placement-New. Sprich das man Objekte in Speicher konstruieren kann, weniger um Speicherallokierung.

[Gast]

Klingt interessant. Magst das mal einem Cler genauer erklären?

[rüdiger]

TactX schrieb:

Klingt interessant. Magst das mal einem Cler genauer erklären?

Ist ganz simpel

class Foo {
public:
  Foo() { std::cout << "Foo()\n"; }
};

int main() {
  char buffer[sizeof(Foo)];
  Foo *ptr = new (buffer) Foo;
}

Damit erstellt man ein Objekt in einem beliebigen Speicher-Block (der natürlich eine entsprechende Größe haben sollte :))

http://www.parashift.com/c++-faq-lite/dtors.html#faq-11.10

[Gast]

Ah, ok. Dann macht das natürlich Sinn. Danke dir

[ten]

rüdiger schrieb:

int main() {
  char buffer[sizeof(Foo)];
  Foo *ptr = new (buffer) Foo;
}

in C würde das so aussehen:

int main() 
{
  char buffer[sizeof(struct Foo)];
  struct Foo *ptr = (struct Foo*)buffer;
}

:xmas2:

[Phoemuex]

ten schrieb:

rüdiger schrieb:

int main() {
  char buffer[sizeof(Foo)];
  Foo *ptr = new (buffer) Foo;
}

in C würde das so aussehen:

int main() 
{
  char buffer[sizeof(struct Foo)];
  struct Foo *ptr = (struct Foo*)buffer;
}

:xmas2:

Dabei wird dann aber kein Konstruktor aufgerufen - ok, den gibts in C ja sowieso nicht, aber das ist halt der Sinn des placement-news, oder?

Felix :xmas2:

[LordJaxom]

Eher so die Richtung, wenn man die Abläufe originalgetreu übertragen will

int main() 
{
  char buffer[sizeof(struct Foo)];
  struct Foo *ptr = (struct Foo*)buffer;
  init_Foo(ptr);
}

:xmas2:

[WilliWollo]

Sagt mal, ist das jetzt das Ende von C++? Ich will jetzt nicht alles lesen.

[Gast]

Nein. Es ist vielmehr das Ende von D *duck*

[Julian__]

hat D jemals richtig angefangen? was willst du da beenden?

mfg,
julian

[Gast]

So in etwa war das auch gemeint

[Simon2]

quote experte schrieb:

Michael E. schrieb:

Optimizer: Wieso gehst du nicht auf den eigentlichen Inhalt von Simon2s Beitrag ein?

...Sich darüber aufzuregen, dass sich das Verhalten beim Wechsel zwischen primitiven Datentypen und allen anderen ändert, ist, als würde ich mich beschweren, dass sich das Verhalten ändert wenn ich in C++ beim Rückgabetyp ein & hinzufüge bzw. entferne....

Sorry, aber das ist eine etwas schräge Analogie (* s.u.).
Wenn ich ein template instantiiere, ändere ich die Semantik seiner Schnittstelle (also die Erwartung an ihr Verhalten) nicht (im Gegensatz dazu, wenn ich beim Returnwert eine Referenz statt einer Kopie zurückgebe - ja, ich weiß, dass C++ den Returntyp nicht zur "Signatur" zählt; IMO auch nicht ganz konsistent, aber vielleicht nicht Anders zu machen).

Worauf ich hinaus wollte: Welchen Sinn macht es, ein template zu schreiben, wenn sich die Semantik dieses templates durch den instantiierenden Typ grundlegend ändert ?

Beispiel: Wenn ich in D ein template analog Folgendem schreibe ...

template <typename T>
class A {
private:
    T d;
public:
    T getD() { return d; }
};

... und die Behandlung primitiver und Klassentypen (bzgl. Kopie vs Referenz) analog zu Java funktioniert, dann verhalten sich:

A<myString> a1;
A<string> a2;

a1.getD() = "Test";
a2.getD() = "Test";

unterschiedlich.

... und das finde ich schon (vorsichtig gesagt) "unerwartet".
Solange man ein keine "primitive Typen-Kopie-sonst-Referenz-Verhalten" hat, ist das unproblematisch; solange nicht generisch programmiert, ist es nur unschön.
Wenn aber beides zusammenkommt, sehe ich das schon als Inkonsistenz, denn wie sollte sich der Programmierer von A oder der von myString dagegen wehren ?

(*) Natürlich kann ich das Ganze damit verknüpfen, dass ich das template auch mit string& instantiieren kann, aber einerseits sehe ich den Einsatz von & und * als bewusste Semantikänderung durch den Nutzer (und nicht nur durch die Hintertür) und andererseits ist fraglich, ob der D-User überhaupt die Wahl hat (der Javaist hat sie halt nicht, weil "alles ein Pointer" ist). Außerdem ist die Chance relativ hoch, dass templates wie das Obige insgesamt mit "Kopiersemantik" arbeitet und Dir deswegen ziemlich schnell um die Ohren knallen, dass eine Referenz nicht kopierbar ist.

Gruß,

Simon2.

P.S.: Damit nicht wieder der falsche Eindruck der "Javahetze" entsteht: In C++ ist das auch nicht so günstig geregelt, weil in meinem template der RV von getD() für primitive Typen keine l-value ist und dementsprechen die Zuweisung nicht funktioniert.

[nep]

Gibt es in D eigentlich auch sowas wie Reflection?

[ten]

nep schrieb:

Gibt es in D eigentlich auch sowas wie Reflection?

nö, D läuft ja nicht inner VM
:xmas2: