C++ (alle ISO-Standards)

• 

  C zu C++ Projektmigration
  • 5cript  

  12
  0
  Stimmen
  12
  Beiträge
  354
  Aufrufe

  

  Ein grosses Problem bei der schrittweisen Umstellung auf C++ ist, dass der bestehende C-Code nicht mit Exceptions klarkommt. D.h. du musst aufpassen dass sich nicht Situationen ergeben wo eine noch nicht angepasste Funktion foo eine angepasste Funktion bar aufruft. Wenn bar dann eine Exception wirft, dann ist foo nicht darauf vorbereitet beim Stack-Unwinding alles rückgängig zu machen was rückgängig zu machen ist. Und gerade wenn es dein Ziel ist viel (oder alles) auf RAII umzustellen, kann es dazu sehr schnell kommen.
• 

  sanitizer::address unlogik?
  • EL europ  

  32
  0
  Stimmen
  32
  Beiträge
  785
  Aufrufe

  F

  @Schlangenmensch sagte in sanitizer::address unlogik?: Es kann nämlich der Pointer konstant sein, und er kann auf eine Konstante zeigen, und jeweils auch nur eins von beiden. Nur am Rande: Ein konstanter Pointer auf ein konstantes Objekt ist nicht so abwegig und könnte z.B. für konstante Zeichenketten durchaus Sinn machen, wenn man versehentliche Veränderungen des Pointers vermeiden will. Z.B. weil es sich um sowas wie eine Globale handelt, auf die auch der Anwender direkten Zugriff hat: const char* const s = "abc". Aber, in dem Projekt an dem ich gerade arbeite, haben wir überall die "const west" Schreibweise, und ich bin da irgendwie Gewohnheitstier. Ich will da nichts lostreten, aber ich habe da wegen der Reihenfolge unserer natürlichen Sprache* "das ist ein konstanter Integer" weniger ein Problem mit const int. Einen Vorteil sehe ich auch nur, wenn man mehrere Pointer-Variablen in einer Zeile deklariert. Wenn man wegen Lesbarkeit aber ohnehin "eine Variable, eine Zeile" bevozugt, relativiert sich das wieder. * Ich glaub es gibt aber auch natürliche Sprachen in denen das andersrum ist. Ich frage mich, ob die Programmierer mit so einer Muttersprache vielleicht eher zu East Const neigen
• C

  "cout" Text zu Variable hinzufügen
  • C91  

  37
  0
  Stimmen
  37
  Beiträge
  750
  Aufrufe

  O

  Schon gut, Thema gelöst... @C91 scheint auch schon das Interesse verloren zu haben.^^
• 

  Klassenfrage :)
  klassen schnittstellen funktionszeiger • • EL europ  

  137
  0
  Stimmen
  137
  Beiträge
  4287
  Aufrufe

  

  Ich hab die unnötoge Speicherallocierung für **matrix und **colormatrix erkannt und die Sanitizermeldungen dieser arrays weg bekommen Jetzt hab ich noch welche durch **iterMembers in Apple->sort(). Könnt ihr mir bitte helfen die noch weg zu bekommen?
• Z

  ofstream: mode nachträglich ändern (setf(ios::app))
  • znieh99  

  7
  0
  Stimmen
  7
  Beiträge
  135
  Aufrufe

  Z

  @SeppJ Danke für die Antwort und die Anregung. Jetzt funktioniert es, lg heinz
• 

  shared_ptr - use_count nutzen zum Feintuning.
  • It0101  

  21
  0
  Stimmen
  21
  Beiträge
  589
  Aufrufe

  F

  @john-0 sagte in shared_ptr - use_count nutzen zum Feintuning.: @Finnegan sagte in shared_ptr - use_count nutzen zum Feintuning.: Auch brauchst wohl du nicht unbedingt einen polymorphen Allocator wie die in std::pmr (der Hauptgrund für die ist, dass sie zustandsbehaftet sind und pro Instanz eigenen Speicher verwalten können, während die klassischen Allokatoren "global" arbeiten und nur "pro Allocator-Typ" individuellen Speicher haben können). Ein nicht-pmr-Allocator tuts denke ich genau so und käme ohne den (winzigen) Overhead einer polymorphen Klasse aus. Da bin ich jetzt nicht bei Dir. Auch die „klassischen“ nicht polymorphen Allocatoren können einen Zustand haben und eigenen Speicher pro Instanz verwalten. Der Punkt ist, dass man das über die entsprechenden alloc_traits vorher testen muss, wie sich ein Allokator verhält. Ein polymorpher Allokator verhält sich pro Instanz unterschiedlich, d.h. er kann nicht nur unterschiedliche Speicherpools verwalten, er kann für jede Instanz eine eigene Strategie verwenden. Ja, das stimmt. Mein Gedanke war, dass die klassischen Allokatoren keine memory_resource haben, Kopien des Allocator untereinander austauschbar sein müssen (Speicher, der mit einem Allocator geholt wird, muss mit der Kopie freigebbar sein) und das wegen allocator<T>::typename rebind<U>::other auch noch über Typgrenzen hinweg funktionieren muss. Ich hatte das mental so abgespeichert, dass das nur sinnvoll mit einer gobalen Speicher-Ressource geht (wie malloc/free für den Default-Allocator). Aber natürlich kann man auch einen eigenen Allocator implementieren, der ebenfalls so eine Abstraktion wie memory_resource verwendet, die dann zwischen den Kopien weitergereicht wird. Allerdings ist das mit den pmr-Allokatoren deutlich einfacher, weil die diese Funktionalität bereits haben und man nur die memory_resource implementieren muss. Daher dachte ich fälschlicherweise dass das nur mit denen ginge, aber die Motivation für pmr war wohl vornehmlich sowas hier zu vereinfachen: std::vector<int, A1> v1; std::vector<int, A2> v2; v1 = v2; // Inkompatible Typen Habe ich das richtig verstanden? Die pmr-Allokatoren und Container lösen eigentlich 2 Probleme? Einmal die Kompatibilität von Datenstrukturen, die unterschiedliche Allokatoren verwenden und zum anderen die der gemeinsamen Speicher-Ressource die auch beim Kopieren und bei rebind weitergereicht wird (und die man mit entsprechendem Aufwand auch mit klassichen Allokatoren implementieren kann)?
• M

  ESP8266 geht in endlos rebootSchleife
  • muekno  

  5
  0
  Stimmen
  5
  Beiträge
  187
  Aufrufe

  

  @Schlangenmensch Danke für den Hinweis, habe ich übersehen.
• M

  std::function mit Funktionszeiger vergleichen?
  • Miq  

  22
  0
  Stimmen
  22
  Beiträge
  801
  Aufrufe

  F

  @hustbaer Oh Mann! Danke für die hartnäckige Nachhilfe. Jetzt ist bei mir endlich der Groschen gefallen, dass std::function zwar die Funktionssignatur in ihrem Typ speichert, aber dennoch eine Type Erasure macht und zur Laufzeit an verschiedene Typen binden kann, welche die selbe Signatur unterstützen. Ich hätte mich ja auch fragen können, warum überhaupt mit typeid() gearbeitet wird. Sorry, manchmal bin ich echt ein Holzkopf ... ich dachte echt die kennt ihre statischen Typen und könnte einfach zur Compile-Zeit schauen, ob ein operator==(T_LHS, T_RHS) existiert.
• Z

  Wo werden die Daten gespeichert (heap, stack)?
  • znieh99  

  13
  0
  Stimmen
  13
  Beiträge
  317
  Aufrufe

  Z

  @SeppJ Ok, danke!
• G

  QT Projekt mit qmake zu kompilieren.
  • Guryeche  

  3
  0
  Stimmen
  3
  Beiträge
  104
  Aufrufe

  

  @Guryeche sagte in QT Projekt mit qmake zu kompilieren.: "qmake meinfenster.pro" erzeugt meines Wissens nach erst mal das Makefile, das Du mit einem einfachen "make" kompilieren kannst. die *.pro Datei dient qmake nur dazu, die nötigen Ziele in der Makefile zu notieren, die von der Qt-Lib benötigt werden. Das "make" ist ein Standard in Deiner Tool-Chain.
• K

  Statische Member vs statische Variablen im anonymen Namespace
  • KK27  

  6
  0
  Stimmen
  6
  Beiträge
  226
  Aufrufe

  K

  Danke für die Antworten. @Finnegan sagte in Statische Member vs statische Variablen im anonymen Namespace: Ansonsten meine (subjektive) Meinung zur eigentlichen Frage: Wenn die Variablen logisch eindeutig zu der Klasse gehören, dann bevorzuge ich statische Member. Ich habe alles was zusammen gehört immer gerne möglichst kompakt in einem "Paket", die Klasse und alle "Globalen" auf denen sie eventuell arbeitet. Wenn ich beim refaktorisieren die Klasse irgendwann in eine andere Quellcodedatei verschiebe, will ich nicht die zugehörige Globale vergessen und mich dann irgendwann wundern, wofür die überhaupt da war, wenn sie allein zurückgeblieben ist So mache ich das meistens auch. Wenn etwas definitiv zur Klasse gehört dann als Member(funktion). Andernfalls als freie Konstante/Funktion im Cpp, sofern sich dafür eine eigene Klasse (noch nicht) lohnt.
• 

  Best practice Default Constructors / operators
  • It0101  

  5
  0
  Stimmen
  5
  Beiträge
  172
  Aufrufe

  F

  @It0101 sagte in Best practice Default Constructors / operators: MyClass() = default; Zu dem Default-Konstruktor sollte man natürlich noch anmerken, dass der auch häufiger abseits von Ressourcenverwaltung Sinn macht, wenn es sowohl einen benutzterdefinierten Konstruktor gibt und gleichzeitig ein trivialer Default-Konstruktor gewünscht ist: struct Integer { Integer() = default; Integer(int value) : value{ value } {} int value; }; Ansonsten kann ich deine Sorgen gut verstehen, es kann natürlich immer einen obskuren Grund* geben, weshalb die Funktionen explizit default sind. Genau so gut kann das aber auch jemand geschrieben haben, der nicht genau wusste, was er tat. Gerade bei sowas sind gute Kommentare wichtig - nicht jeder Code ist intuitiv selbsterklärend. Schau dir auf jeden Fall mal genau an, wie die Klassen im restlichen Code verwendet werden, vielleicht hilft das ja deine Zweifel zu zerstreuen oder mögliche Gründe zu finden, weshalb man die Defaults haben wollte. * Hier wurde mal so was "obskures" diskutiert. Ein deleted Move-Konstrukor wurde für Overload Resolution herangezogen, obwohl ein Copy-Kostruktor existierte, was zu einem Fehler führte. Eine mögliche Lösung war einen default Move-Konstruktor zu deklarieren und diesen dann implizit zu löschen. Das dürfte aber ebenfalls unter den Themenkomplex "Ressourcenverwaltung" fallen.
• 

  Bibliotheken für CNC Steuerung ...
  • Muecke82  

  3
  0
  Stimmen
  3
  Beiträge
  171
  Aufrufe

  

  @Cardiac, anfangs hielt ich Linux für eine gute Wahl, da es so angepasst werden kann, wie es benötigt wird. Man könnte es so konfigurieren, dass beim Starten der Anlage nur die benötigte Software sichtbar ist und man nicht direkt auf das Betriebssystem zugreifen kann. Dabei hatte ich den Gedanken, für die Hardwaresteuerung LinuxCNC (Schnittstelle C++ / Python) zu verwenden. Als Anwender würde man nichts von LinuxCNC mitbekommen, da es in das Programm eingebettet ist (so habe ich es zumindest verstanden). Das Linux-System müsste dann nur aktualisiert werden, wenn wirklich gravierende Änderungen vorgenommen werden, da das Betriebssystem nicht für weitere Programme genutzt werden müsste, mit Ausnahme von Datenpaketen, die regelmäßig an einen externen Server über das Internet gesendet werden. Persönlich habe ich grundsätzlich Schwierigkeiten mit PCs, wenn nicht alles per Klick funktioniert, was meine Liebe zu Linux wirklich erschwert, da man dort alles selbst machen muss. Im Gegensatz dazu ist Windows natürlich praktisch, da es unzählige Dinge gibt, die man tun kann und es extrem verbreitet ist. Ich bin mir nicht sicher, inwieweit eine Echtzeit-Steuerung von CNC-Maschinen über Windows gut realisierbar ist. Alles, was ich über CNC-Fräsen gefunden habe, verwendet im Hintergrund Linux, wenn es schnell und genau sein soll. Dies mag jedoch mit einer FPGA-Chip-Steuerung weniger relevant sein, da bereits viel auf der Steuerkarte und nicht mehr vom PC selbst überwacht wird. Da ich selbst noch nicht vollständig entschlossen bin, dachte ich, ich schaue über meinen eigenen Tellerrand hinaus und versuche, einige Informationen zu erhalten. Aus diesem Grund auch die Frage nach "Bibliotheken für CNC-Steuerung", die möglicherweise einen Vorteil bieten würden, nicht LinuxCNC zu verwenden, aber dennoch bei Linux zu bleiben oder doch für Windows zu sprechen. Da ich ein kommerzielles Projekt plane, habe ich auch überhaupt keine Abneigung gegen kostenpflichtige Bibliotheken oder Schnittstellen. Ich habe dies übrigens unter Betriebssysteme veröffentlicht: https://www.c-plusplus.net/forum/topic/354546/beratung-bezüglich-betriebssystemwahl-und-programmiersprache-für-geplante-softwareentwicklung/7
• T

  Aufgabe Ticketverkauf txt ausgaben wiederholen sich
  • TiltSchweiger  

  11
  0
  Stimmen
  11
  Beiträge
  369
  Aufrufe

  O

  @wob Ich wollte mit meinen Beispielen auch nur andeuten, wie es funktionieren könnte. Es ist richtig, das Ganze modular zu gestalten, und auf eine vernünftige Datenstruktur zu stellen.
• K

  Pointer wegen möglichen Stackoverflow?
  • KK27  

  36
  0
  Stimmen
  36
  Beiträge
  761
  Aufrufe

  K

  @Helmut-Jakoby sagte in Pointer wegen möglichen Stackoverflow?: Hi @KK27 , wir haben unsere "Programmier-Richtlinien" des Öfteren mal angepasst. Zudem musste jeder Programmcode durch eine "Software-Qualitätssicherung". Verstöße gegen die Richtlinien führten zur Ablehnung . Darf bei euch jeder programmieren wie er will? Grob gesagt ja. Wir haben zwar Richtlinien, aber die sind total veraltet und führen zu mehr Problemen als Lösungen. Ein jüngerer Kollege hat mal neue und modernere Richtlinien vorgeschlagen, aber man wollte darüber nachdenken und das wars. Außerdem ist das meiste nirgends dokumentiert und wird mündlich übertragen. Dokumentation sei nicht notwendig. Man fragt oder sagt es einmal und dann weiß man es. Zum Beispiel eine der alten Richtlinien: In h. alle Defines und Konstanten reinpacken. Das hpp inkludet das h und das cpp immer das hpp. Das hpp inkludet alle Klassen die im hpp und cpp benötigt werden. Das cpp inkludet nur das hpp. Das war ein Beispiel der alten Richtlinie. Der Kollege hat vorgeschlagen das man für jede Klasse ein hpp hat, forward declarations, eums über defines. Aber naja. Wurde nichts. Eine Software-Qualitätssicherung wurde auch vom jüngeren Kollegen vorgeschlagen, aber es kam nie dazu. Ich und der jüngere Kollege programmieren "moderner". Teilweise sogar mein Chef und Entwicklungsleiter. Aber alte Angewohnheiten lassen sich schlecht ablegen und manche Kollegen wollen unbedingt an der alten Art und Weise festhalten, weil es funktioniert hat. Unsere Firma gibt es schon sehr lange. Seit über 50 Jahren und unser Hauptprodukt ist auch so alt. Klar gibt es deswegen viele technischen Schulden, aber...
• J

  Weiteren namespace bei ADL hinzufügen
  • Jockelx  

  8
  0
  Stimmen
  8
  Beiträge
  146
  Aufrufe

  

  @Th69 sagte in Weiteren namespace bei ADL hinzufügen: Sorry, meinte natürlich using namespace NS;. Sogar das geht auch nicht - zumindest nicht gut. So, in dieser Reihenfolge geht es: #include <iostream> struct Foo{}; namespace NS { std::ostream& operator<<(std::ostream& os, Foo const& foo) { return os << "meh"; } } // namespace NS template <typename T> void g(const T& a) { using namespace NS; std::cout << a; } int main() { Foo f; g(f); } Aber so geht es schon nicht mehr: #include <iostream> namespace NS {} template <typename T> void g(const T& a) { using namespace NS; std::cout << a; } // Später, z.B. weil in anderem Header File definiert: struct Foo{}; namespace NS { std::ostream& operator<<(std::ostream& os, Foo const& foo) { return os << "meh"; } } // namespace NS int main() { Foo f; g(f); } Der Grund ist, dass bereits beim Parsen von g die Liste der in Frage kommenden Funktionen für operator<< erstellt wird. Und diese wird später, bei der Instanzierung, nur mehr um per ADL gefundene Funktionen erweitert. In anderen Namespaces wie hier z.B. NS wird nicht nochmal nachgesehen. p.S.: Es hilft nichtmal den operator<< im globalen Namespace zu definieren -- ausser in dem Spezialfall dass der auszugebende Typ im globalen Namespace lebt. Gleicher Grund: es wird nur in Namespaces nachgesehen die per ADL gefunden werden, und wenn der globale Namespace halt nicht per ADL gefunden wird, dann guckt der Compiler dort auch nicht nochmal nach.
• _

  CGI, OOP, C++ und der Stack
  • _ro_ro  

  4
  0
  Stimmen
  4
  Beiträge
  151
  Aufrufe

  _

  @Th69 Ok, das klingt schonmal gut Grundsätzlich bewegt ein CGI Programm große Datenmengen. Allein zum Erzeugen einer HTML-Response lädt mein Responseobjekt 4 Templates (Header, Navigationsmenu/Breadcrumb, Body und Footer) und eine 1.5 MB große Binary für die statischen Routen auch dann wenn keine Parameter zu erwarten sind. Für Uploads bis 1 GB via HTTP nutze ich ohnehin kein C++ sondern ein spezielles Verfahren mit dem ein Gateway-Timeout umgangen wird. MFG
• A

  DHTML InnertText readout
  • Achromat  

  21
  0
  Stimmen
  21
  Beiträge
  565
  Aufrufe

  O

  @Achromat Am besten, oxide ganz in Ruhe lassen/ignorieren. Wahrscheinlich hat der (genau wie Konrad im anderen Forum) hier einen Freibrief zum Trollen.
• 

  Parameterpack im Konstruktor von template
  • It0101  

  4
  0
  Stimmen
  4
  Beiträge
  166
  Aufrufe

  

  Ich kann nur zwei nicht besonders hübsche Workarounds anbieten. 1: template <class T> struct FooBar { template <class... Args> class Impl { }; }; FooBar<int>::Impl f("x", 1, 1, "x"); 2: template <class T> struct Type {}; template <class T, class... Args> class FooBar { public: FooBar(Type<T>, const std::string &, Args ... a_ ) : a(std::forward<Args>( a_ )...) {} virtual ~FooBar() = default; private: std::tuple<Args...> a; }; FooBar f{Type<int>{}, "a", 1, 2, 3, 4};
• _

  Bitte um Kritik zu einer meiner C++ Library
  • _ro_ro  

  53
  0
  Stimmen
  53
  Beiträge
  1407
  Aufrufe

  _

  @Finnegan Danke Dir. Nun, die Prüfung soll schon serverseitig erfolgen. Ich habe mich jetzt dazu entschlossen, anstatt wieder extern was zu bauen, meine Klasse um einen Konstruktor zu erweitern so daß bei der Objekterstellung direkt das Datum aus dem Eingebefeld übergeben wird: Scaliger sca1( cgi.param("date1") ); also als String und alle Püfungen in der Klasse selbst erfolgen. Den Browser könnte man für eine Vorab-Prüfung heranziehen, aber <input type="date"> erfordert wieder eine zusätzliche Formatumwandlung und das ist unschön, es rechtfertigt den Aufwand nicht. Viele Grüße!!