Infos über neuen C++-Standard? Thread Nr.2

[rüdiger]

@Marc++us
ich wollte das nur zum Thema "da blutet dem ISOisten doch das Herz" abgegebn. Besonderes wollte ich nichts damit sagen. (OT. Wenn ich einen Compiler für irgend welche Embeded Systeme schreiben würde, dann würde ich einfach ein neues GCC Backend entwerfen, dann kann ich nämlich die tollen C++ Kentnisse des GCCs nehmen und hab gleichzeitig noch zich andere Sprachen, wie C, ADA ... portiert ;))

@Lars
würde sagen comp.std.c++

[Helium]

Oder diskutier das ganze mit Leuten die sich wirklich damit auskennen (z.B. in comp.std.c++)

Aber wartet bitte noch einen Moment. Ich hab grade keinen Newsreader drauf. Oder ich machs per google?

in comp.std.c++ gabs auch mal ne Phase (Moment hat jemand einen Duden da? wird das so geschreiben?), in der Leute vorschläge für C++0x gepostet haben. Die meisten wurden aber zunichte gemacht. Das ist jetzt aber schon über ein Jahr her.

[Gerard]

Original erstellt von Helium:
in comp.std.c++ gabs auch mal ne Phase (Moment hat jemand einen Duden da? wird das so geschreiben?), in der Leute vorschläge für C++0x gepostet haben. Die meisten wurden aber zunichte gemacht. Das ist jetzt aber schon über ein Jahr her.

ich machs per google, reicht mir vollkomen und das mit den fertig machen das ist kein Phase sondern ein zustand
meistens ist es aber berechtigt, aber oft kommt es mir vor wie ein verein von haar spaltern und erbsen zählern

[Shade Of Mine]

Original erstellt von Dimah:
**mit

std::vector<int> v;
v::iterator i = v.begin();

werde ich wohl nicht durch kommen, weil man in c++ Instanzen die gleichen Namen wie Typen geben darf, hier könnte es auch eine v klasse geben, d.h. alter Code könnte Probleme bekommen und nur für etwas mehr Komfort werden sie das nicht ändern.
**

Jep, zurecht wirst du damit nicht durchkommen.
warum soll eine klasse nicht type anbieten dürfen, zB als typedef auf T?

typeof() ist die bessere Lösung, glaub mir.
ausserdem liest sich
typeof(v)::iterator
besser als
v::iterator

woher soll man denn auf die schnell wissen, das v eine instanz ist und keine klasse?

das mit dem length_of(void*) wäre aber durchaus praktisch... müsste man mal näher die pros und cons beachten...

[HumeSikkins]

aber oft kommt es mir vor wie ein verein von haar spaltern und erbsen zählern

Das habe ich schon oft gehört. Meine Meinung zu diesem Vorwurf: Wenn das kein Verein von Haar spaltern und Erbsen zählern wäre (sehe ich übrigens nicht so. Eher ein Verein von Gut-Auskennern und Language-Lawyern), dann gäbe es keinen vernünftigen Standard sondern nur ein einziges riesiges Chaos wo jeder macht was er will.

[Jester]

Original erstellt von Shade Of Mine:
**typeof() ist die bessere Lösung, glaub mir.
**

Ohja, das ist eine tolle Begründung!
(Ein typeof fände ich aber auch gut)

Gegen das length_of spricht in meinen Augen folgendes:

Angenommen, ich hole mir ein 27 Bytes großes Array. Dann könnte dem Compiler (dem ich gesagt hab optimier bitte auf speed) auf die Idee kommen vielleicht 32 Byte zu reservieren. Das heißt, die Größe, die delete kennt stimmt nicht mit der tatsächlichen Array-Größe überein. Ähnlich wäre es bei Klassen,wenn Alignment-Bytes eingefügt werden. Also müßte man die Länge noch mit abspeichern.
Der Verwaltungsaufwand steigt also. Wie war das nochmal mit dem Zero-Cost-Principle?

MfG Jester

[HumeSikkins]

Wie war das nochmal mit dem Zero-Cost-Principle?

In einem Satz?

You don't have to pay for what you don't use.

[Gerard]

ich ziehe meine length_of antrag zurück

[Bashar]

Jester: Ich seh nicht zu was für Problemen das führen soll, wenn length_of dann 32 zurückliefert.

[Gerard]

Original erstellt von Bashar:
Jester: Ich seh nicht zu was für Problemen das führen soll, wenn length_of dann 32 zurückliefert.

wenn es aber nur 17 objekte geben soll, außerdem müssten dan 15 unötige ctor aufrufe getragen werden

[Bashar]

wenn delete weiß, wieviele dtors aufgerufen werden müssen, kann length_of doch genau die Zahl zurückliefern ...

ich denke es geht um POD Objekte ... bei denen isses dann IMO unerheblich, ob ich nur die ansprechen darf, die ich tatsächlich alloziert hab, oder auch die, die mir der Compiler als alloziert zusichern will (in die Richtung müßte dann auch die Semantik von length_of definiert werden).

[volkard]

Original erstellt von HumeSikkins:
[quote] was ich mir noch wünche ist das nan die grösse eines dynamischen arrays rausbekommen kann

**
Und wozu soll das gut sein? Erstens habe ich die größe sowieso, da ich sie ja angeben muss. Und zweitens gibt's da ja auch noch sowas schönes wie Container.
**[/QUOTE]
performance. nullkosten sind toll.
wenn new[] die größe speichert, dann will ich sie auch auslesen können. new[] muß die größe dann speichern, wenn die elemente nen nichttrivialen dtor haben. und genau dann wäre es nicht schrecklich, man würde mir die freiheit geben, nen schnellen vector mit _begin und _end oder nen lahmeren mit _begin und end() zu basteln.

ps: kann ich auch so. ich bastel mir in wenigen wochen arbeit nen allokator, der so gut wie ::new ist, aber zusätzlich dieses feature hat.

pps: kann ich doch nicht. man überlege sich nen compiler, der ein register reserviert hält für topOfHeap, meiner müßte das mit Speicher erledigen. außerdem kann der compiler sich manchmal merken, ob der user überhaupt angefragt hat und wenn nicht, das speichern sein lassen. oder sich merken, wie groß das ding war und stat abzuspeichern der anfrage hart reincompilieren.

[ Dieser Beitrag wurde am 22.01.2003 um 04:20 Uhr von volkard editiert. ]

[volkard]

Original erstellt von Bashar:
wenn delete weiß, wieviele dtors aufgerufen werden müssen, kann length_of doch genau die Zahl zurückliefern ...
ich denke es geht um POD Objekte ... bei denen isses dann IMO unerheblich, ob ich nur die ansprechen darf, die ich tatsächlich alloziert hab, oder auch die, die mir der Compiler als alloziert zusichern will (in die Richtung müßte dann auch die Semantik von length_of definiert werden).

man könnte sich evtl gut absichern, wenns noch ein neues schlüsselwort bool ispod(Type) gäbe. würde ich mir eh manchmal wünschen, um fix ein memcpy statt ner schleife zu nehmen.

[Shade Of Mine]

Original erstellt von volkard:
man könnte sich evtl gut absichern, wenns noch ein neues schlüsselwort bool ispod(Type) gäbe. würde ich mir eh manchmal wünschen, um fix ein memcpy statt ner schleife zu nehmen.

was hältst du von dem Ansatz std::copy zu auf POD-Typen zu spezialisieren und dann nur auch memcpy weiterzuleiten...

das gefällt mir recht gut, da ich mich nicht darum kümmern muss, sondern copy die aufgabe übernimmt sich selbst möglich effizient zu implementieren.

[volkard]

Original erstellt von Shade Of Mine:
was hältst du von dem Ansatz std::copy zu auf POD-Typen zu spezialisieren und dann nur auch memcpy weiterzuleiten...
das gefällt mir recht gut, da ich mich nicht darum kümmern muss, sondern copy die aufgabe übernimmt sich selbst möglich effizient zu implementieren.

klar, der ist ganz gut. hab ich auch schon verwendet.
nur leider kann ich nicht alle pod-typen auflisten.

[Gerard]

Original erstellt von volkard:
klar, der ist ganz gut. hab ich auch schon verwendet.
nur leider kann ich nicht alle pod-typen auflisten.

etwas loki::int2type<>, std::iterator_traits<Iterator>::value_type und boost::is_POD<T>::value und dan geht das schon

[ Dieser Beitrag wurde am 22.01.2003 um 11:10 Uhr von Dimah editiert. ]

[HumeSikkins]

man könnte sich evtl gut absichern, wenns noch ein neues schlüsselwort bool ispod(Type) gäbe. würde ich mir eh manchmal wünschen, um fix ein memcpy statt ner schleife zu nehmen.

Ich denke die generische Programmierung schreit sowieso noch nach ein paar Schlüsselwörtern. Klar kann man fast alles mit krassen traits und co. erledigen. Das ist aber immer super aufwendig und eigentlich soll eine Sprache einen ja auch unterstützen. OOP geht ja auch in C. In C++ geht es halt nur leichter. Ähnlich sehe ich das mit der generischen Programmierung im Zusammenhang mit dem ganzen Template-Gedöns. Ich denke, wenn sich in C++ da nicht einiges ändert, werden manche Templatetechniken nie wirklich aus ihrem Nischendasein rauskommen.

Wenn's nicht über Schlüsselwörter passiert, dann muss es halt über viele Zugaben in der Standardlib erfolgen. Aber das ich mir immer erst boost runterladen und installieren muss, nur damit ich ein paar coole Dinge machen kann, halte ich persönlich nicht für so prickelnd.

[ Dieser Beitrag wurde am 22.01.2003 um 11:18 Uhr von HumeSikkins editiert. ]

[Knuddlbaer]

aber oft kommt es mir vor wie ein verein von haar spaltern und erbsen zählern dann gäbe es keinen vernünftigen Standard sondern nur ein einziges riesiges Chaos wo jeder macht was er will.

Das nennt man heutzutage kurz "Microsoft" *sfg

[Gerard]

Original erstellt von HumeSikkins:
Ich denke die generische Programmierung schreit sowieso noch nach ein paar Schlüsselwörtern.

du kennst ja die Standard Komite Politik was neue Schlüsselwörtern angeht, ich frage mich, wieso bei den compilern nicht gleich boost & ACE und co. mitgeliefert werden

[volkard]

Original erstellt von Dimah:
etwas loki::int2type<>, std::iterator_traits<Iterator>::value_type und boost::is_POD<T>::value und dan geht das schon
[ Dieser Beitrag wurde am 22.01.2003 um 11:10 Uhr von [qb]Dimah editiert. ][/QB]

also ich nehme immer
struct foo
{
int x;
};
und mein kollege nimmt nur
struct bar
{
signed x;
};
wie macht boost::is_POD es, foo und bar zu erkennen?