mikrocontroller.net

Forum: PC-Programmierung Erste Pläne für C++20 veröffentlicht


Autor: cpp (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Programmiersprachen: Erste Pläne für C++20 veröffentlicht
https://www.heise.de/developer/meldung/Programmier...

Autor: Da Dieter (dieter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die sollen mal aufhören alle paar Jahre die Sprache komplett 
umzukrempeln. Wer soll denn da hinterher kommen, den Kram zu lernen... 
;-)

Autor: nicht"Gast" (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Was heißt hier komplett umkrempeln. Es ist schön das C++ sich nach all 
den Jahren wieder ein wenig bewegt.

Viele Sachen waren einfach nicht mehr Zeitgemäß. Kein Wunder, der 
Standard von 1989 war ja ewig Stand der Dinge. So wichtige Sachen wie 
Threads, Lambdas etc. gehören einfach in eine moderne Sprache.

Autor: Dussel (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Ich freue mich erstmal auf C++17. Ich denke, dahin werde ich dann mein 
Wissen mal erweitern. Ich stehe ehrlich gesagt noch auf C++98…
Wie lange dauert es eigentlich, bis Compiler neue Standards 
unterstützen? Ab wann ist zum Beispiel damit zu rechnen, dass g++ oder 
Clang C++17 unterstützen? Oder tun sie das schon?

Autor: Carl Drexler (jcw2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nicht"Gast" schrieb:
> Was heißt hier komplett umkrempeln. Es ist schön das C++ sich nach all
> den Jahren wieder ein wenig bewegt.
>
> Viele Sachen waren einfach nicht mehr Zeitgemäß. Kein Wunder, der
> Standard von 1989 war ja ewig Stand der Dinge. So wichtige Sachen wie
> Threads, Lambdas etc. gehören einfach in eine moderne Sprache.

Huhu, wir haben 2017!
Und C++17, was soll sich nach all den Tagen dringend ändern?

Autor: Flip (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert

Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dussel schrieb:
> Ab wann ist zum Beispiel damit zu rechnen, dass g++ oder
> Clang C++17 unterstützen? Oder tun sie das schon?
Klar, schon lange.

Beitrag #5080576 wurde vom Autor gelöscht.
Autor: Dussel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke. Ich dachte, das würde einige Zeit dauern.

Autor: Mod (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Hi, die sollten lieber mal veraltete Dinge über Bord werfen, um den 
Sprachumfang, und somit nicht zuletzt die Komplexität etwas in Zaun zu 
Halten.
Gruß

Autor: opravo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mod schrieb:
> Hi, die sollten lieber mal veraltete Dinge über Bord werfen, um
> den
> Sprachumfang, und somit nicht zuletzt die Komplexität etwas in Zaun zu
> Halten.
> Gruß

C++ aktualisieren ohne Abwärtskompatibilität? Dann kann man es sich auch 
gleich sparen, da steigt keiner um.
Es zwingt einen ja keiner die "veralteten Dinge" zu verwenden, oder?

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Da D. schrieb:
> Die sollen mal aufhören alle paar Jahre die Sprache komplett
> umzukrempeln. Wer soll denn da hinterher kommen, den Kram zu lernen...
> ;-)

Die Weiterentwicklung von C++ geschieht ja noch relativ langsam. Schau
dir mal an, mit welcher Frequenz neue C#-Versionen hinausgeballert
werden :)

Mod schrieb:
> Hi, die sollten lieber mal veraltete Dinge über Bord werfen, um den
> Sprachumfang, und somit nicht zuletzt die Komplexität etwas in Zaun zu
> Halten.

Mal angenommen, Abwärtskompatibilität wäre kein Kriterium: Welche alten
Features sollte man deiner Ansicht weglassen, so dass

1. der Sprache keine wesentliche Funktionalität genommen wird und

2. tatsächlich eine deutliche Verschlankung der Sprache erreicht wird?

So arg viel gibt es da nicht.

Ich mag C++ auch nicht besonders, aber es ist eine der ganz wenigen
Sprachen, in der man einserseits so maschinennah und performant wie in C
programmieren kann, auf der anderen Seite aber auch eine ganze Menge
High-Level-Features geboten bekommt. Das macht es für mich trotz vieler
Holprigkeiten interessant.

Die seit C++11 neu eingeführten Sprachelemente betreffen vor allem die
High-Level-Programmierung und die Reduktion der stellenweise durch die
Verwendung von High-Level-Features bedingten Performanceverluste. Das
stellt IMHO einen deutlichen Fortschritt dar und macht für mich C++
zunehmend attraktiv.

Leider sind meine C++-Kenntnisse recht bruchstückhaft, und die neuen
Features wollen z.T. richtig gelernt werden (in Python fällt es mir
bspw. viel leichter, Schritt mit der aktuellen Entwicklung zu halten).
Mein letztes C++-Buch ist von 1998, darüber hinausgehendes Wissen habe
ich stückweise (und damit unvollständig) aus dem Internet erlangt.

Deswegen werde ich meine Vorbehalte etwas zurückstellen und mir
demnächst nach einem guten Lehrbuch umsehen und dieses systematisch
durcharbeiten. Selbst wenn mir dann C++ immer nocht nicht gefällt, kann
ich wenigstens fundiert darüber meckern ;-)

Autor: Timm Reinisch (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Mod schrieb:
> Hi, die sollten lieber mal veraltete Dinge über Bord werfen, um
> den
> Sprachumfang, und somit nicht zuletzt die Komplexität etwas in Zaun zu
> Halten.

das ist so ein Barnum-Satz wie in Horoskopen. Kann man auf einen 
Großteil aller Änderungen / Neuerungen antworten.

Was konkret wären denn solche veralteten Dinge, die über Bord gehören?

Ich arbeite mich seit kurzem in C++14 ein (früher viel mit c++98 
gemacht) und bin bisher extremst begeistert und habe bisher eigentlich 
den Eindruck, dass der Großteil recht übersichtlich, im Sinne von 
logisch konsistent, ist.

Vor allem nach aktuell wirklich frustrierenden Erfahrungen mit den 
dauernden alles umstürzenden Swift Releases.

vlg

 Timm


Edit: Ja gut, man könnte zum Beispiel argumentieren, dass std::bind weg 
kann.

Ich denke aber, man müsste da schon zwischen Sprachfeatures im engeren 
Sinne und unter Benutzung der Sprachfeatures zur Verfügung gestellten 
Funktionen in der Standardbibliothek unterscheiden.

Abgesehen davon schafft das Beibehalten von std::bind keine Komplexität. 
Wenn ich es nicht benutzen will, muss ich mich 0.00 damit beschäftigen, 
es entgeht einem absolut gar nichts, weil die c++14 Lambdas ein 
vollwertiger Ersatz sind. Das einzige Ergebnis wäre, dass alter Code 
nicht mehr funktionieren würde.

Anders sieht es mit der type deduction aus, die ist so allgegenwärtig, 
dass man sich damit beschäftigen muss, ob man will oder nicht. Die 
schafft etwas Komplexität, ist aber keine Altlast.

Also: Wo ist die Altlast, die Komplexität schafft?

: Bearbeitet durch User
Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Timm R. schrieb:

> ...
> Ich denke aber, man müsste da schon zwischen Sprachfeatures im engeren
> Sinne und unter Benutzung der Sprachfeatures zur Verfügung gestellten
> Funktionen in der Standardbibliothek unterscheiden.
>
> Abgesehen davon schafft das Beibehalten von std::bind keine Komplexität.
> Wenn ich es nicht benutzen will, muss ich mich 0.00 damit beschäftigen,
> es entgeht einem absolut gar nichts, weil die c++14 Lambdas ein
> vollwertiger Ersatz sind. Das einzige Ergebnis wäre, dass alter Code
> nicht mehr funktionieren würde.
>
> Anders sieht es mit der type deduction aus, die ist so allgegenwärtig,
> dass man sich damit beschäftigen muss, ob man will oder nicht. Die
> schafft etwas Komplexität, ist aber keine Altlast.
>
> Also: Wo ist die Altlast, die Komplexität schafft?

Da C++17, ff. immer noch abwärtskompatibel sind, muss(!) man sich mit 
type-deduction nicht beschäftigen.

Setzt man aber type-deduction richtig ein, wird der Code leichter 
verständlich. Und das ist ein wesentliches Feature. Vor allem bei 
automatischer Typinferenz von class-template Parametern.

Dasselbe gilt für concepts/constraints (mein persönliches highlight 
zusammen mit modules). Wobei concepts/constraints wirklich Möglichkeiten 
schaffen, die es in der Form vorher nicht gab (man kann nicht alles mit 
SFINAE erschlagen). Hier also ein Feature, das neue Möglichkeiten 
schafft (zusammen mit constexpr-if) und gleichzeitig Altlasten / Hacks 
wie SFINAE entsorgt.

Autor: lalala (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kaj G. schrieb:
> Dussel schrieb:
>> Ab wann ist zum Beispiel damit zu rechnen, dass g++ oder
>> Clang C++17 unterstützen? Oder tun sie das schon?
> Klar, schon lange.

Laut dieser Seite: http://en.cppreference.com/w/cpp/compiler_support
unterstützen sie C++17 zu 99%. P0067R5 scheint noch zu fehlen.

Autor: ui (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir fallen schon ein paar Dinge ein, die man weglassen kann. Was mich an 
C++ am meisten stört (und es wird ja auch so kommuniziert): Es wird 
immer gesagt, dieses und jenes könne man in C++ besser lösen 
(einfachstes Beispiel: ptr vs. smart_ptr). Nur richtig umgesetzt wirds 
nicht. Es ist zwar vorhanden (smart_ptr) aber der Programmierer wird 
nicht dazu gezwungen. Und das ist für mich ein gewaltiger Nachteil. Und 
es gibt viele Dinge wo es so umgesetzt wird.

Das ist ein gewisser Grad von Inkonsistenz. Jeder weiß, dass C gewisse 
Nachteile hat. Diese Nachteile will man mit C++ abfangen bzw. 
verbessern. Aber um die Abwärtskompatibilität unbedingt aufrecht zu 
erhalten zieht man es doch nicht richtig durch. Das heißt für mich, man 
kombiniert die negativen Eigenschaften von C mit neuen negativen 
Eigenschaften (z.B. Ellenlange Definitionen).Warum nicht
uint8_t *ptr
per default zu einem smart_ptr machen? Was spricht denn dagegen?
Die Macher von C++ müssen sich IMHO entscheiden was sie wollen: Entweder 
eine moderne, typsichere Sprache die C# und Java Konkurrenz machen kann, 
oder sie bleibt halt immer C mit Erweiterung.

Ein ähnlicher harter Schritt wie in python würde dem Standard denke ich 
gut tun.

Autor: Timm Reinisch (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Wilhelm,

Wilhelm M. schrieb:

> Da C++17, ff. immer noch abwärtskompatibel sind, muss(!) man sich mit
> type-deduction nicht beschäftigen.

Klar. Man muss sich nicht damit beschäftigen. Was ich meinte ist, dass 
einem wesentliches entgeht, wenn an es nicht tut. Anders als (soweit ich 
erkennen kann), wenn man sich nicht mit std::bind beschäftigt. Da 
entgeht einem praktisch gar nichts.

imho.


vlg

 Timm

Edit: Vielen Dank übrigens für die extrem interessanten Stichworte!

: Bearbeitet durch User
Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
ui schrieb:
> Mir fallen schon ein paar Dinge ein, die man weglassen kann. Was mich an
> C++ am meisten stört (und es wird ja auch so kommuniziert): Es wird
> immer gesagt, dieses und jenes könne man in C++ besser lösen
> (einfachstes Beispiel: ptr vs. smart_ptr). Nur richtig umgesetzt wirds
> nicht. Es ist zwar vorhanden (smart_ptr) aber der Programmierer wird
> nicht dazu gezwungen. Und das ist für mich ein gewaltiger Nachteil. Und
> es gibt viele Dinge wo es so umgesetzt wird.

Das ist Aufgabe desjenigen, der er Interface schreibt. Und da es noch 
reine C-Bibliotheken und auch alte C++ Bibliotheken gibt, wird das so 
bleiben.

Im Übrigen ist daran auch wenig Schlimmes. Man muss sich eben nur über 
die unterschiedlichen Zeigertypen und ihre Semantik im klaren sein. Es 
gibt eben Zeiger mit Eigentümerschaft und solche ohne (reine 
Benutzungsrelation).

> Das ist ein gewisser Grad von Inkonsistenz. Jeder weiß, dass C gewisse
> Nachteile hat. Diese Nachteile will man mit C++ abfangen bzw.
> verbessern. Aber um die Abwärtskompatibilität unbedingt aufrecht zu
> erhalten zieht man es doch nicht richtig durch. Das heißt für mich, man
> kombiniert die negativen Eigenschaften von C mit neuen negativen
> Eigenschaften (z.B. Ellenlange Definitionen).

Sehe ich nicht.

> Warum nicht
>
> uint8_t *ptr
> 
> per default zu einem smart_ptr machen?

Weil das nicht sinnvoll ist (s.o.).

Autor: Timm Reinisch (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ehrlich gesagt frage ich mich, ob Du nicht eventuell „keinen Durchblick 
haben" mit Komplexität verwechselst?

Dein Ansatz Implentierungsentscheidungen des Entwicklers durch 
Eingleisigkeit der Sprachumgebung zu ersetzen ist, soweit ich das 
erkennen kann, ziemlich genau das Gegenteil der Philosophie von C++.

ui schrieb:
Warum nicht
>
> uint8_t *ptr
> 
> per default zu einem smart_ptr machen? Was spricht denn dagegen?

Na dann mal Butter bei die Fische, wie das hier bei uns heißt, welcher 
Smart Pointer solls denn sein? Dann wirst Du auch sehen warum das eine 
schlechte Idee ist.

smart_ptr gibt es nicht.

vlg

Timm

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ui schrieb:
> Warum nicht
> uint8_t *ptr
> per default zu einem smart_ptr machen?

Die verschiedenen Typen von Smart Pointern in C++ sind nur sinnvoll und
überhaupt verwendbar in Verbindung mit dynamisch allozierten Objekten.
Solange nicht alle Objekte in einem Programm dynamisch alloziert werden,
braucht man auch klassische Pointer bzw. Referenzen.

: Bearbeitet durch Moderator
Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:

> Die verschiedenen Typen von Smart Pointern in C++ sind nur sinnvoll und
> überhaupt verwendbar in Verbindung mit dynamisch allozierten Objekten.
> Solange nicht alle Objekte in einem Programm dynamisch alloziert werden,
> braucht man auch klassische Pointer bzw. Referenzen.

Nein (also: ... nicht alle ...): wenn mindestens ein Objekt dynamisch 
allokiert wird (und dies sollte man in MCPP mit std::make_shared<>() 
bzw. std::make_unique<>() machen), verwendet man Intelligente Zeiger.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> Nein (also: ... nicht alle ...): wenn mindestens ein Objekt dynamisch
> allokiert wird (und dies sollte man in MCPP mit std::make_shared<>()
> bzw. std::make_unique<>() machen), verwendet man Intelligente Zeiger.

Ja, aber eben nur für die dynamischen Objekte. Ein shared_ptr oder
unique_ptr auf andere Variablen führt i.Allg. zu einem fehlerhaften
Verhalten zur Laufzeit. Wenn man einen Pointer auf eine dieser anderen
Variablen zeigen lassen möchte, kommt man um einen klassischen Pointer
(oder alternativ eine Referenz) nicht herum.

Autor: Torsten Robitzki (Firma: robitzki.de) (torstenrobitzki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ui schrieb:
> Warum nicht
>
> uint8_t *ptr
> 
> per default zu einem smart_ptr machen? Was spricht denn dagegen?

1) ist `std::uint8_t *ptr` einfach eine Referenz auf ein std::uint8_t. 
Smart Pointer verwendet man aber nur da, wo es um die Verwaltung von 
dynamischen Speicher und dessen Besitz geht.
2) Welchen smart pointer möchtest Du den haben? shared_ptr<> wäre wohl 
in den meisten Fällen nicht falsch. unique_ptr<> aber wohl in den 
allermeisten Fällen richtig (Vorraussetzung).

Wenn Du in C++ einfach blind jeden Zeiger durch einen smart pointer 
ersetzt, dann wirst Du sehr wahrscheinlich jede Menge Fehler in Deine 
Applikation bauen. Vorallem, wenn man denkt, sich dann keine Gedanken 
mehr um Design machen zu müssen. Die meisten Probleme mit 
Memory-Problemen, die ich bis jetzt gesehen haben, waren in Java und C# 
Applikationen, weil die Kollegen erst am Ende der Entwicklung gemerkt 
haben, dass Garbage-Collection halt nicht alles heil macht.

> Die Macher von C++ müssen sich IMHO entscheiden was sie wollen: Entweder
> eine moderne, typsichere Sprache die C# und Java Konkurrenz machen kann,
> oder sie bleibt halt immer C mit Erweiterung.

Worin glaubst Du, sind die VMs von C# und Java geschrieben?

Autor: Timm Reinisch (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Yalu X. schrieb:
> Ja, aber eben nur für die dynamischen Objekte. Ein shared_ptr oder
> unique_ptr auf andere Variablen führt i.Allg. zu einem fehlerhaften
> Verhalten zur Laufzeit. Wenn man einen Pointer auf eine dieser anderen
> Variablen zeigen lassen möchte, kommt man um einen klassischen Pointer
> (oder alternativ eine Referenz) nicht herum.

warum gibt das denn eine Abwertung? Auf einen einfachen Datentyp wie zB 
float, als normale Variable kann man doch keinen Smart Pointer setzen? 
Stimmt doch? Will man auch gar nicht, aber das ist eine andere Frage.


Ich habe noch zwei Fragen / Anmerkungen.

1)
Ein shared_ptr und ein unique_ptr haben doch einen memory overhead? Das 
könnte doch unter Umständen auch ein Grund für einen raw pointer sein?

2)
Bei einer cyclischen Referenz wie dieser (oder so ähnlich):
class X
{
public:
    std::shared_ptr<X> sibling;
}

int main()
{
    std::shared_ptr a = make_shared<X>();
    std::shared_ptr b = make_shared<X>();
    a->sibling = b;
    b->sibling = a;
}

ist doch mit shared_ptr Schicht im Schacht, während es sich in diesem 
Fall mit raw Pointern, auch wenn X einen speziellen dtor hätte, einfach 
in Wohlgefallen auflösen würde?

Jeder Pointer hat halt so seine Funktionalität und danach muss man sie 
eben auswählen, auch der raw-Pointer?


Zurück zum ursprünglichen Thema: Der auto_ptr ist doch mittlerweile tot, 
oder? Das wäre doch ein Beispiel für eine beerdigte Altlast?

vlg
 Timm

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Timm R. schrieb:

> 1)
> Ein shared_ptr und ein unique_ptr haben doch einen memory overhead? Das
> könnte doch unter Umständen auch ein Grund für einen raw pointer sein?

Eigentlich hat nur der std::shared_ptr<>() einen memory-overhead. 
(Solange beim std::unique_ptr<> kein spezieller deleter eingesetzt 
wird).

Der Indirektionsnachteil sollte bei beiden null sein.

>
> 2)
> Bei einer cyclischen Referenz wie dieser (oder so ähnlich):
...
> ist doch mit shared_ptr Schicht im Schacht, während es sich in diesem
> Fall mit raw Pointern, auch wenn X einen speziellen dtor hätte, einfach
> in Wohlgefallen auflösen würde?

Dafür haben wir std::weak_ptr.

> Jeder Pointer hat halt so seine Funktionalität und danach muss man sie
> eben auswählen, auch der raw-Pointer?

Ja, wie schon (so oft) geschrieben: non-owning-pointer bzw. Zeiger, die 
nur
eine Benutzungsrelation ausdrücken.

>
> Zurück zum ursprünglichen Thema: Der auto_ptr ist doch mittlerweile tot,
> oder? Das wäre doch ein Beispiel für eine beerdigte Altlast?

Ja, wobei er von Anfang an tot war und deswegen so gut wie nie verwendet 
wurde (ist ein Spezialfall mit Verschiebungssemantik).

: Bearbeitet durch User
Autor: Pragmatiker (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
cpp schrieb:
> Programmiersprachen: Erste Pläne für C++20 veröffentlicht
> 
https://www.heise.de/developer/meldung/Programmier...

Das einzige was man muss, ist das #pragma/compilerschalter um den Code 
genauso wie bewährt schreiben und übersetzen zu können.

Autor: interrupt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Deswegen werde ich meine Vorbehalte etwas zurückstellen und mir
> demnächst nach einem guten Lehrbuch umsehen und dieses systematisch
> durcharbeiten.

Was für ein Buch wäre für C++17 denn zu empfehlen ?

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
interrupt schrieb:
> Yalu X. schrieb:
>> Deswegen werde ich meine Vorbehalte etwas zurückstellen und mir
>> demnächst nach einem guten Lehrbuch umsehen und dieses systematisch
>> durcharbeiten.
>
> Was für ein Buch wäre für C++17 denn zu empfehlen ?

Derzeit gibt es eigentlich nur Bücher zu c++11/14. Aber das reicht 
eigentlich auch, die wesentlichen Dingen sind schon im Übergang 
c++98->c++11 gewesen. Den Rest kann man sich eigentlich aus

http://en.cppreference.com/w/

erlesen und den einschlägigen Blogs wie

https://isocpp.org/blog

oder C++Weekly von Jason, bzw. auch den guten Beiträgen von

https://herbsutter.com/

http://foonathan.net/

https://akrzemi1.wordpress.com/

http://www.fluentcpp.com/

u.dgl.m.

Wobei die Themen concepts/constraints (nur im gcc) und modules (nur im 
clang) naturgemäß schwer zu finden sind.

Autor: Nop (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
ui schrieb:

> Warum nicht uint8_t *ptr
> per default zu einem smart_ptr machen?

Wäre das nicht problematisch an Stellen, wo man Pointer nutzt, ohne in 
irgendeiner Weise (auch nicht indirekt) malloc/free zu verwenden? Vor 
allem in bestehendem Code, den man nicht extra umschreiben will?

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Nop schrieb:
> ui schrieb:
>
>> Warum nicht uint8_t *ptr
>> per default zu einem smart_ptr machen?
>
> Wäre das nicht problematisch an Stellen, wo man Pointer nutzt, ohne in
> irgendeiner Weise (auch nicht indirekt) malloc/free zu verwenden?

Selbstverständlich!!! Das darf nicht sein! Aber das ist auch alles schon 
oben geschrieben worden.

Nochmal: es gibt Zeiger mit Eigentümerschaft (typischerweise als 
SmartPointer bezeichnet) wie std::unique_ptr<> und std::shared_ptr<> und 
solche ohne Eigentümerschaft wie std::observer_ptr<> oder 
std::weak_ptr<> und natürlich auch Rohe Zeiger. Und natürlich darf man 
Zeiger mit Eigentümerschaft auch nur dort einsetzen, wo man ein Objekt 
erzeugt hat, dessen Lebensdauer nicht-automatisch geregelt wird, also 
typischerweise Objekte auf der Halde. Und damit man dabei so wenig 
Fehler wie möglich machen kann, ist in MCPP die Erzeugung von Objekten 
mit dyn. storage durch die Hilfsfunktionstemplates std::make_unique<> 
und std::make_shared<> bevorzugt (nie mehr ein explizites new/delete). 
Damit wäre dann auch obiges Konstrukt ersetzt durch einen SmartPointer 
zwar nicht unmöglich, jedoch sofort durch statische Code-Analyse 
aufzudecken.

Die rohen Zeiger bleiben damit für die Modellierung einer reinen 
Benutzungsrelation ohne Eigentümerschaft. Dies können auch Zeiger auf 
statische oder lokale Objekte sein. Im allg. sollte man Referenzen 
vorziehen, wenn man kann, und rohe Zeiger benutzen, wenn man muss, bspw. 
wenn man auch ausdrücken können muss, dass man kein Objekt referenziert 
(nullptr).

Autor: interrupt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> Derzeit gibt es eigentlich nur Bücher zu c++11/14.

Und welches wäre da zu empfehlen ?

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
interrupt schrieb:
> Wilhelm M. schrieb:
>> Derzeit gibt es eigentlich nur Bücher zu c++11/14.
>
> Und welches wäre da zu empfehlen ?

m.E.

Breymann; "Der C++Programmierer", neue Auflage!

Grimm, "C++11"

Meyers, "Effective modern C++"

Josuttis, "The C++ Standard Library"

Bancila, "Modern C++ Programming Cookbook"

Autor: Timm Reinisch (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Wilhelm M. schrieb:

> oder C++Weekly von Jason, bzw. auch den guten Beiträgen von
>
> https://herbsutter.com/
>
> http://foonathan.net/
>
> https://akrzemi1.wordpress.com/
>
> http://www.fluentcpp.com/

Hammer! Wer noch nicht reingeschaut hat und 98er ist, wie ich, sollte 
unbedingt mal reinstöbern. Fluentcpp zum Beispiel schreibt wirklich 
locker und auch didaktisch sehr sehr gut.

Danke!

Vlg
 Timm

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Timm R. schrieb:
> Hallo,
>
> Wilhelm M. schrieb:
>
>> oder C++Weekly von Jason, bzw. auch den guten Beiträgen von
>>
>> https://herbsutter.com/
>>
>> http://foonathan.net/
>>
>> https://akrzemi1.wordpress.com/
>>
>> http://www.fluentcpp.com/
>
> Hammer! Wer noch nicht reingeschaut hat und 98er ist, wie ich, sollte
> unbedingt mal reinstöbern. Fluentcpp zum Beispiel schreibt wirklich
> locker und auch didaktisch sehr sehr gut.
>
> Danke!
>
> Vlg
>  Timm

Hatte vergessen

https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines

explizit zu erwähnen (oh, ich höre schon den Aufschrei: eine Sprache, 
die so
etwas braucht, ist nicht zu gebrauchen ...)

Ich finde diese Guidelines und die GSL aus zwei Aspekten interessant:

1) Wie die C++-SuperFAQ ein gut strukturiertes Nachschlagewerk, das 
speziell auf MCPP ausgerichtet ist (beantwortet damit auch die Frage 
nach den Altlasten (s.o.).

2) Es sind schon viele Hinweise auf die künftigen Änderungen / Planungen 
eingebaut (z.B. uniform-function-call Syntax und Concepts / 
Constraints).

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> 1) Wie die C++-SuperFAQ ein gut strukturiertes Nachschlagewerk, das
> speziell auf MCPP ausgerichtet ist (beantwortet damit auch die Frage
> nach den Altlasten (s.o.).

Du benutzt immer wieder den Begriff MCPP, von dem ich noch nie gehört
habe. Eine Web-Suche liefert im Wesentlichen drei Bedeutungen:

Eine psychoaktive Substanz:

  https://en.wikipedia.org/wiki/Meta-Chlorophenylpiperazine

Ein C/C++-Präprozessor:

  http://mcpp.sourceforge.net/

bzw. dessen Nachfolger:

  https://github.com/zeroc-ice/mcpp

Managed C++, der Vorgänger von C++/CLI für .NET von Microsoft:

  https://www.it-visions.de/glossar/alle/600/Managed_C.aspx

Falls du keine dieser drei Bedeutungen meinst (was ich fast vermute),
welche dann? Und wo kann man mehr darüber lesen?

Edit:

Wilhelm M. schrieb:
> Breymann; "Der C++Programmierer", neue Auflage!

Gestern war ich in einem Buchladen, habe mir dieses Buch (aktuelle
Auflage von 2016) angeschaut. Einen Stroustrup (2013) zum direkten
Vergleich war leider nicht vorrätig. Da ich nicht mit leeren Händen
nach Hause gehen wollte, habe ich mich kurzerhand für den Breymann
entschieden.

Nach den ersten ca. 100 Seiten bin ich mit dem Buch trotz des leicht
unsystematischen Aufbaus und einiger kleiner Fehler ganz zufrieden.
Wenn ich durch bin, werde ich evtl. einen kleinen Erfahrungsbericht
schreiben.

: Bearbeitet durch Moderator
Autor: Timm Reinisch (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Yalu,

naja, wohl

using MCPP = Modern CPP, also post-C++98.

vlg
 Timm

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Timm R. schrieb:
> using MCPP = Modern CPP, also post-C++98.

Ah, jetzt ja, vielen Dank fürs Augenöffen :)

Da muss man erst einmal draufkommen. Aber du hast natürlich recht, so
ergibt das einen Sinn.

Trotzdem scheint die Abkürzung MCPP nicht sehr gebräuchlich zu sein.
Auch dürfte der Begriff "Modern C++ Programming" einem ständigen
Bedeutungswandel unterworfen sein. Heute ist MCPP = Post-C++98, in ein
paar Jahren wird MCPP = Post-C++17 sein ;-)

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Timm R. schrieb:
>> using MCPP = Modern CPP, also post-C++98.
>
> Ah, jetzt ja, vielen Dank fürs Augenöffen :)

Ja, so war es gedacht.

> Da muss man erst einmal draufkommen. Aber du hast natürlich recht, so
> ergibt das einen Sinn.

Dachte, dass das "selbsterklärend" wäre. Man schreibt ja auch nicht 
immer Konstruktor oder Destruktor, sondern kürzt das oft mit ctor und 
dtor ab. Und das ist auch kein Akronym, was in Wikipedia steht ...

> Trotzdem scheint die Abkürzung MCPP nicht sehr gebräuchlich zu sein.

Wird aber mehr: das erste Mal habe ich das glaube im Vortrag von Scotty 
gesehen, weil sein letztes Buch ja auch "Effective MODERN C++" heißt.

> Auch dürfte der Begriff "Modern C++ Programming" einem ständigen
> Bedeutungswandel unterworfen sein.

Selbstverständlich, weil er ja ein moving-target ist.

> Heute ist MCPP = Post-C++98, in ein
> paar Jahren wird MCPP = Post-C++17 sein ;-)

Da wird er hoffentlich obsolet sein, denn im Moment befindet sich die 
überwiegende Mehrzahl der CPP-Programmierer in einer Situation, wo sie 
entweder selbst noch den Umstieg machen oder eben mit altem Code zu tun 
haben.

Das Kommittee will ja auch, dass die Sprache sich bewegt durch den 
3-jährigen Zyklus und durch die Arbeitsweise über die TS-Prozedur.

Autor: Timm Reinisch (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hallo,

Wilhelm M. schrieb:

> https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines

na, das kommt doch einem C++14 Lehrbuch durchaus recht nahe?

Sehr cool finde ich den Abschnitt N: Non-Rules :-) Endlich mal!


Eine Sache beschäftigt mich allerdings: eine ganze Reihe von Vorschlägen 
sowohl aus diesen Guidelines, als auch in anderen Quellen, zB fluentcpp 
würden IMHO nahelegen, dass es nett wäre benannte Parameter zu haben. 
Für Compiler / Präprozessor sollte das nur eine entspannte Fingerübung 
sein, dennoch scheinen benannte Parameter (also beim Aufruf mit Namen 
versehen) absolut niemanden besonders zu bewegen?

vlg
 Timm

Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Benannte Funktionsparameter in der Sprache wären sicher eine praktische 
Sache und vermutlich kein Problem für den Compiler. Aber wie könnte das 
in C++ aussehen? Die Vorschläge, die ich bis jetzt gesehen habe, hatten 
entweder offensichtliche Problme, waren unleserlich oder viel zu 
kompliziert.
Wenn du nen praktikable Lösung kennst würde mich das sehr interessieren.

Autor: Timm Reinisch (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

mh schrieb:
> Benannte Funktionsparameter in der Sprache wären sicher eine praktische
> Sache und vermutlich kein Problem für den Compiler. Aber wie könnte das
> in C++ aussehen? Die Vorschläge, die ich bis jetzt gesehen habe, hatten
> entweder offensichtliche Problme, waren unleserlich oder viel zu
> kompliziert.
> Wenn du nen praktikable Lösung kennst würde mich das sehr interessieren.

vielleicht gibts da ein Missverständnis. Ich meinte als syntaktische 
Neuerung. Nicht als Lösung mit bestehenden Sprachmitteln.

Die Lösungen mit bestehenden Sprachmitteln finde ich alle grauenhaft. 
Strong Types zähle ich mal nicht dazu, die finde ich schon sehr nett und 
auch logisch zusätzlich können ja auch noch sehr viel mehr, Überladungen 
auflösen zum Beispiel. Aber wenn man für jeden benannten Parameter einen 
starken Typen einführt ...

Wahrscheinlich sind andere Dinge im Moment erstmal wichtiger ...

vlg
 Timm

Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kein Missverständnis, ich hab auch von einer Erweiterung der Sprache 
gesprochen. Wie kann C++ um benannte Funktionsparameter Erweitert 
werden?

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Timm R. schrieb:
> Hallo,
>
> Wilhelm M. schrieb:
>
>> https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
>
> na, das kommt doch einem C++14 Lehrbuch durchaus recht nahe?
>
> Sehr cool finde ich den Abschnitt N: Non-Rules :-) Endlich mal!
>
>
> Eine Sache beschäftigt mich allerdings: eine ganze Reihe von Vorschlägen
> sowohl aus diesen Guidelines, als auch in anderen Quellen, zB fluentcpp
> würden IMHO nahelegen, dass es nett wäre benannte Parameter zu haben.
> Für Compiler / Präprozessor sollte das nur eine entspannte Fingerübung
> sein, dennoch scheinen benannte Parameter (also beim Aufruf mit Namen
> versehen) absolut niemanden besonders zu bewegen?

Dafür gibt es Vorschläge:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers...

Doch gibt es eben auch schon immer einige Alternativen und es sind auch 
noch einige dazu gekommen:

1) strong-types und parameter-permutation
2) named-parameter idiom

In C++20 kommen dann designated-initializers hinzu. Auf dem Weg dahin 
kann man die durch IIFE ersetzen.

Es gibt auch Möglichkeiten über Proxy-Templates zu gehen oder auch 
std::tuple einzusetzen. Aber das ist alles mit viel boilerplate 
verbunden.

In meinen Augen sind 1) und 2) absolut ausreichend und 
designated-initializers wären eine tolle Ergänzung.

Leider sehe ich in der Praxis immer noch sehr viel Code, der DIE 
wichtigste Schnittstellenregel nicht beachtet:

Eine Schnittstelle sollte leicht richtig und schwer falsch zu benutzen 
sein!

Und das erreicht man m.E. sehr gut mit 1) und / oder 2).

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.