@Columbo sagte in Standardkonstrukor: @john-0 Tatsaechlich habe ich mich gerade mit einem Arbeitskollegen unterhalten, der mir erklaert hat, dass in Fortran die Etiquette besteht, dass man nie einen Parameter aendern sollte, gerade weil dies zu boesen Fehlern fuehrt, wenn man Konstanten etc. als Argumente hat (und ganz frueher, aber das war in den 90ern schon folklore, konnte man auf bestimmten Maschinen sogar die integer literals aendern, weil sie im Datensegment gespeichert waren). Das stimmt eher nicht. Beispiel finden sich etwa in der offiziellen BLAS Referenzimplementation z.B. DGEMM. Es war usus im Kopf der Routine das zu dokumentieren, so dass man wusste wie ein Parameter genutzt werden darf. Aber da reden wir über Fortran77 und älter, und bei so altem Fortran wurden meistens COMMON Blöcke genutzt, bei denen das Problem ohnehin nicht existiert. Ab Fortran90 gibt es das Intent Statement, mit dem man das auch durch den Compiler prüfen lassen kann. Das sah dann ungefähr so aus. C OLD FORTRAN STYLE C THIS SHORT PROGRAM DEMONSTRATE PARAMETER HANDLING WITHIN FORTRAN C SUBROUTINES AND FUNCTIONS COMMON/FOOCOM/ MODE,RCUT COMPLEX Z DATA Z /(1.0,3.141592654)/ CALL FOO(Z) WRITE(*,*) MODE,RCUT,Z END PROGRAM SUBROUTINE FOO(Z) C IN OUT: Z, /FOOCOM/ RCUT C IN: /FOOCOM/ MODE COMPLEX Z C Die Definition des COMMON Blocks und der Konstante würde man bei größeren Programmen in eine Include datei auslagern. PARAMETER (PI=3.141592654) COMMON/FOOCOM/ MODE,RCUT IF(MODE.EQ.1)THEN RCUT=RCUT*PI Z=Z**2 ELSE RCUT=RCUT*2*PI Z=Z**0.5 ENDIF END SUBROUTINE BLOCK DATA COMMON/FOOCOM/ MODE,RCUT DATA MODE,RCUT /1,3.0/ END Im aktuellen Fortran wurde man das Programm eher im folgenden Stil formulieren. program param_new use iso_fortran_env implicit none real(kind=real64), parameter :: PI = 3.141592654 real(kind=real64) :: rcut = 3.0 integer :: mode = 1 complex(kind=real64) :: z = (1.0,PI) call foo(mode, rcut, z) WRITE(*,*) MODE,RCUT,Z contains subroutine foo(mode,rcut,z) integer, intent(in) :: mode real(kind=real64), intent(in out) :: rcut complex(kind=real64), intent(in out) :: z if (mode == 1) then rcut = rcut * PI z = z ** 2 else rcut = rcut * 2 * PI z = z ** 0.5 end if end subroutine foo end program param_new Ein Fortran Fanatiker wuerde also das const sehen Nein, da man das in der Regel so nicht gemacht hat. Es gibt genügend Beispiel im Netz wie man das früher gemacht hat, die Variante, die dein Kollege ansprach, ist eher ungewöhnlich.

@Johnny01 Die meisten Programme lassen sich grob in 4 Richtungen unterscheiden: 1.) Schulprogramme Schulprogramme sind Programme, welche an der Schule gelehrt werden und welche fast immer hoffnungslos veraltet sind. Da werden Pointer, verkettete Listen,... benutzt. Möchte man hier helfen, so muss man erst einmal schauen was der Lehrer haben möchte und eine entsprechende Lösung zeigen. Egal wie veraltet, fehleranfällig die Lösung sein mag. 2.) Uniprogramme Uniprogramme sind relativ ähnlich zu Schulprogrammen. Jedoch hat man mehr Freiheiten beim programmiern, hauptsache das Ergebnis stimmt. Und an meiner Uni wurde immer gesagt, man lehre keine Programmierung, das darf man schön selbst machen. Also bekam man öfters eine sehr kurze Einführung in Java, C,... und durfte dann direkt ein Problem nachprogrammieren. 3.) Programmiersprache als MIttel zum Zweck Beispiel: "Hmm, der angebotene Kredit hat einen Zinssatz von 2% und eine Laufzeit von 8 Jahren. Der zweite angebotene Kredit hat einen Zinssatz von 4% und eine Laufzeit von 4 Jahren. Welcher Kredit ist günstiger?" In diesem Beispiel schnappt man sich eine Programmiersprache, rotzt den Programmcode herunter und schaut sich das Ergebnis an. Hierunter könnte dein Programm fallen. Du möchtest Koperkonstruktor verstehen, also schreibst du ein Programm und schaust dir das Verhalten an. 4.) Produktiver/professionieller EInsatz Im produktiven Einsatz versucht man Programme zu schreiben, welche möglichst wenig fehleranfällig, robust gegenüber Fehler (Eingabefehler), schnell, einfach, sauber, lesbar, dokumentiert, leicht erweiterbar, einfach zu bedienen,... ist. Und genau das ist der Unterschied zu den 3 vorherigen Richtungen. Auf einmal spielen Dinge wie fehleranfälligkeit eine Rolle. Betrachtet man dein Programm nun aus Sicht des produktiven Einsatzes, so stellt man sich halt die Frage warum du Pointer und Allokationen (new) nutzt. Beide Sachen erweisen sich nämlich als fehleranfällig. Wer gibt beispielsweise den allokierten Speicher in int* coordinates; frei? Warum erzwingt man hier ein new(), wenn man die Koordinaten doch direkt definieren kann ("int coordinates[2];")? Das macht das Programm doch unnötig langsamer. Deine Funktion make_pair hat eine gewisse Ähnlichkeit zu std::make_pair. Deine Funktion kann aber im Gegensatz zu der std::make_pair Variante ein Speicherloch erzeugen. Nicht gut. usw.

Hier sind zwei Varianten die funktionieren. #include <type_traits> template <typename T> concept Addable = requires (T a, T b) {a + b;}; auto double_up (const auto& value) requires Addable<decltype(value)> { return value + value; } // alternativ auto double_up (const Addable auto& value) { return value + value; } int main() { double_up (2.0); }

@Finnegan Danke für die netten Worte und das Verständnis. Der ESP32 ist echt toll 520KB Ram - echt viel für ein so kleines Ding. Da kratze ich mit meinen Programmteilen irgendwo im % Bereich herum. Richtig rauf geht es mit diversen Libraries. Aber da ist noch viel Luft: RAM: [== ] 15.7% (used 83392 bytes from 532480 bytes). Enger wird es da schon beim Flahs (4MB), da ich 2 gleich große Partitionen und noch weitere kleine brauche: Flash: [========= ] 85.4% (used 1566759 bytes from 1835008 bytes). Aber notfalls habe ich noch die 16MB Version... Vielen Dank Leute, dass Ihr euer Wissen mit mir teilt. Ich wünsche euch ein schönes Weihnachtsfest!!! PS: Ein "kleines" Weihnachtsgeschenk hatte ich auch schon: 200KB Flash: Der ESP war noch auf 320KB eingestellt!

Herzlichen Dank liebe Leute! Ihr habt mir sehr gute Denkanstösse gegeben

@Bashar Danke!

vieleicht mal hier nachlesen: https://www.c-plusplus.net/forum/topic/39489/dynamische-mehrdimensionale-arrays