Hat jemand einen aktuellen gcc und kann bestätigen daß das dort immer
noch auftritt? Meiner ist die letzte Version die das offizielle ARM ppa
ausspuckt, auf der ARM Webseite gibts aber schon neuere zum direkten
Download.
Bernd K. schrieb:> kompiliert es ohne Fehler!
Naja, ohne Fehler compiliert es auch so schon, und das Ergebnis ist
korrekt. Es gibt ja keinen Fehler, sondern eine Warnung.
Selbst die Warnung ist für sich genommen nicht falsch: der shift count
an dieser Stelle wäre ja tatsächlich negativ – nur dass die Stelle eben
aufgrund der äußeren Umstände garantiert nicht erreicht wird (was sich
ja auch im generierten Code reflektiert). Insofern ist die Warnung
verwirrend, aber eher eine Unschönheit denn ein tatsächlicher Bug.
Aber wenn du es reportest, vielleicht ließe es sich ja einfach beheben,
und jemand erbarmt sich. Hab's gerade auf einem (AVR-)GCC 9.1.0
probiert, gleiches Verhalten. Reporte es daher gegen diese Version, das
erhöht die Chance, dass es jemanden bei GCC interessiert. ;-)
Das tritt auch auf nem 9.2er x86 gcc auf. Der passende Check für die
Warnung wird wohl einfach keine branches und keine nicht-konstanten
shift offsets prüfen. Ist jetzt wirklich nichts weltbewegendes.
Das ganze gibt nur nen Fehler weil du die Warnung per Compileroption zum
Fehler machst.
Bernd K. schrieb:> Hat jemand einen aktuellen gcc und kann bestätigen daß das dort immer> noch auftritt?
Nein, aber es ist nicht auf den ARM-GCC beschränkt. Mit MinGW32 5.1.0
läßt sich die Meldung reproduzieren.
Jörg W. schrieb:> Es gibt ja keinen Fehler, sondern eine Warnung.
Oh, da ist mir mein allgegenwärtiges -Werror auf die Füße gefallen. Aber
auch eine Warnung ist natürlich unschön.
Zum Glück wirft der Optimizer auch dann das if und den unzutreffenden
Branch wenn shift nicht als const deklariert ist solange der Ausdruck 6
- 13 zur Kompilezeit konstant ist (was bei mir der Fall ist weil das aus
Makroauflösungen mit literalen Konstanten kommt).
Hab mir jetzt sowas gebaut:
Jörg W. schrieb:> Selbst die Warnung ist für sich genommen nicht falsch: der shift count> an dieser Stelle wäre ja tatsächlich negativ – nur dass die Stelle eben> aufgrund der äußeren Umstände garantiert nicht erreicht wird (was sich> ja auch im generierten Code reflektiert). Insofern ist die Warnung> verwirrend, aber eher eine Unschönheit denn ein tatsächlicher Bug.
Das ist ganz klar und eindeutig ein Bug.
Die Begründung, warum das ein Bug sein muss, ist überaus simpel: Es gibt
keine Möglichkeit, die Warnung zu verhindern, ohne den KORREKTEN Code
substantiell zu ändern.
Das sollte NIEMALS passieren. Das konterkariert den Sinn der
statischen Codeanalyse und unterminiert ihre praktische Nutzbarkeit als
Sicherungsmechanismus.
c-hater schrieb:> Die Begründung, warum das ein Bug sein muss, ist überaus simpel: Es gibt> keine Möglichkeit, die Warnung zu verhindern, ohne den KORREKTEN Code> substantiell zu ändern.
Doch, natürlich gibt es die.
Aber das wissen C-Hasser natürlich nicht, müssen sie auch nicht.
Johann J. schrieb:> Bernd K. schrieb:>> Hab mir jetzt sowas gebaut:#define SHIFT_LEFT(x, y) ((y) > 0 ? (x)>> << (y) : (x) >> -(y))>> #define SHIFT_RIGHT(x, y) ((y) > 0 ? (x) >> (y) : (x) << -(y))>> das schluckt er überall ohne zu meckern.>> Hast Du sonst nichts zu tun?
Das Freihalten der Buildkonsole von jeglichen Warnungen gehört zu meinen
Top-Prioritäten. Die Komplexität mehrere Projekte gleichzeitig die ich
jederzeit (oder auf Zuruf kurzfristig wieder) vollständig überblicken
muß erlaubt nicht das allergeringste Einfallstor für mögliches Chaos,
ich dulde nicht das geringste inhaltsleere Rauschen das zusätzlich in
meinem Informationszugang hineindrängt und ihn verstopft! Das Forum hier
ist übrigens eine der wenigen Ausnahmen von dieser Regel die ich
erlaube!
Mit den beiden obigen Zeilen wird der Code aus Post #1 auch klarer und
kleiner da ich jetzt nicht mehr für jeden shift umständlich 2 if-Zweige
hinschreiben muß. Meine Haupsorge bei irgendeinem Kompromiss wär die
Optimierbarkeit gewesen, aber wie sich gezeigt hat hat die
Constant-Propagation genug Macht um das auch so zu schaffen.
c-hater schrieb:> Jörg W. schrieb:>>> Doch, natürlich gibt es die.>> Zeigen!
Warnung -Wshift-count-negative, option zum ausschalten folglich
-Wno-shift-count-negative. Ich kompiliere meine Programme immer mit
-Werror, einzelne Warnungen ausschalten mach ich nur wenn wirklich nötig
wegen so einem Compiler Bug. Das finde ich auch sehr ärgerlich, wenn es
mal nötig wird. Bei späteren Versionen sollte man das dann nicht
vergessen, wieder zu entfernen, wenn es mal behoben wurde.
nicht"Gast" schrieb:> Das ist kein Bug
Doch, die betroffene stelle kann nie erreicht werden, wenn kein
undefinierter Code ausgeführt werden kann, ist es in Ordnung. Es ist
egal, ob der Compiler den Code weglasst, oder dort sonst was hinpflanzt,
aber falsch ist es nicht. Das er warnt ist aber klar falsch. Ein false
positive.
nicht"Gast" schrieb:> Das ist kein Bug>> Aus dem freien Draft:> [...]
Andere Baustelle. Ich hab nämlich gar keine negativen shifts, das kann
ich sogar zur Compilezeit schon beweisen, der Compiler ist aber leider
anderer Meinung.
A. K. schrieb:> nicht"Gast" schrieb:>> Das ist kein Bug>> In obigem Code ist die Shiftcount garantiert nicht negativ.
Doch, ist er.
Bernd K. schrieb:> src/cap_measure.c:24:18: error: left shift count is negative> [-Werror=shift-count-negative]> return x << shift;
Die Zeile wird zwar niemals ausgeführt, aber der Code ist trotzdem UB.
Oliver
Bernd K. schrieb:> Das Freihalten der Buildkonsole von jeglichen Warnungen gehört zu meinen> Top-Prioritäten.
Das ist lobenswert, aber hier zu spaet. Wenn ein Leftshift ploetzlich in
die andere Richtung losgeht, ist schon voher was faul. Ein assert(3) ist
die bessere Loesung und zeigt direkt das Problem auf anstatt es zu
verstecken.
leo
Oliver S. schrieb:> Die Zeile wird zwar niemals ausgeführt, aber der Code ist trotzdem UB.
Dieser Logik folgend wäre auch
return p ? *p : 0;
für p==NULL undefiniert.
Nope: Erst die ausgeführte Operation "negative shift" ist undefiniert.
Ebenso wie es erst der Zugriff über einen NULL Pointer ist. Werden sie
nicht ausgeführt, ist nichts undefiniert.
A. K. schrieb:> In obigem Code ist die Shiftcount garantiert nicht negativ.
Durch das Entfernen des "const" ist es aber nur noch eine Optimierung,
den Codepfad nicht zu betrachten.
Mir sieht das so aus, als ob der gcc da auf sein eigenes Hütchenspiel
hereinfällt: An einer Stelle weiß er, dass die Zahl negativ ist, an der
anderen nicht.
leo schrieb:> Wenn ein Leftshift ploetzlich in> die andere Richtung losgeht, ist schon voher was faul.
Nein, der geht nicht "plötzlich" in die andere Richtung. Die Shiftweite
in meinem Beispiel war schon immer eine literale Konstante irgendwo mit
zwei simplen #define festgenagelt und war immer positiv und zur
Kompilezeit bekannt.
Jetzt hab ich den Code an einigen Stellen erweitert um später auch
negative shifts dort haben zu können weil sich ein neuer Anwendungsfall
ergab. Die Absicht ist daß der Optimizer je nachdem in welchem Projekt
ich den Code da oben¹ verwende beim Kompilieren entweder nur den if oder
nur den else Zweig stehen lässt.
Wenn ich das if/else durch dem ternären Operator ersetze klappts und er
meckert nicht, obwohl die Logik beim Prüfen der Plausibilität die selbe
sein müsste.
---
¹ Der Code ist Teil eines makrobasierten Templates das ich sehr häufig
brauche, mehrere Varianten der selben Funktion werden zur Kompilezeit
generiert mit unterschiedlichen konstanten Parametern und
unterschiedlichen Datentypen. Zum Beispiel ein Moving Average der Länge
n von int16_t Werten. Oder uint8_t oder double. Oder ein Gauss-Filter
für int32_t. Solche Sachen lass ich dann mit einer einzigen Zeile Code
generieren wo immer ich schnell mal einen brauche.
Bernd K. schrieb:> Jetzt hab ich den Code an einigen Stellen erweitert um später auch> negative shifts dort haben zu können
Das wird ja immer schlimmer ...
Du schreibst also nicht sauberen Code sondern sauber obfuscated Code.
leo
Daniel A. schrieb:> Ich kompiliere meine Programme immer mit -Werror,
Was durchaus vernünftig ist, machen wir in der Firma auch so.
> einzelne Warnungen> ausschalten mach ich nur wenn wirklich nötig
Schalt sie doch für genau die eine Funktion aus.
leo schrieb:> Du schreibst also nicht sauberen Code sondern sauber obfuscated Code
Deine Aussage ergibt keinen Sinn. Du weißt nicht welchem Zweck mein Code
dienen soll, das oben gepostete ist ein Minimalbeispiel das den selben
Fehler demonstriert über den ich bei mir gestolpert bin, den echten Code
kennst Du gar nicht, deshalb kannst Du auch nicht darüber urteilen.
Und jetzt unterlasse bitte diese an mich gerichteten niederen Attacken,
hier gehts um eine klar abgegrenzte technische Fragestellung bezüglich
des Compilers, nicht um meinen Kodierstil, der stand gar nicht zur
Debatte! Also Bitte!
Jörg W. schrieb:> Daniel A. schrieb:>> Ich kompiliere meine Programme immer mit -Werror,>> Was durchaus vernünftig ist, machen wir in der Firma auch so.
Wirklich immer? Oder nur wenn es darum geht den Quelltext zu commiten?
Ich würd irre werden, wenn ich beim entwickeln Fehler der Form
mh schrieb:> Ich würd irre werden, wenn ich beim entwickeln Fehler der Formerror:> unused parameter 'foo' [-Werror=unused-parameter]> oder ähnlich belommen würde.
Einige harmlose oder bedeutungslose Warnungen wie diese werden global
deaktiviert. Alles andere verdient es unverzüglich behandelt zu werden,
das stört auch nicht bei der Arbeit, nach einiger Zeit spürt mans schon
beim Schreiben, noch lange bevor einem der Compiler auf die Finger
klopft.
mh schrieb:>>> Ich kompiliere meine Programme immer mit -Werror,>> Was durchaus vernünftig ist, machen wir in der Firma auch so.>> Wirklich immer?
Ja, immer.
Eine Ausnahme wäre maximal, dass man es während einer größeren
Entwicklung vielleicht temporär abschaltet, dann typischerweise auf
einem Branch, und es würde vor dem Merge back wieder aktiviert.
Committet wird bei DVCSen sowieso laufend, ggf. halt (lokaler Branch)
auch mal "unfertiger" Code. Einfach, damit man bei Bedarf einen
"Checkpoint" hat, zu dem man wieder zurück kehren kann.
Daniel A. schrieb:> nicht"Gast" schrieb:>> Das ist kein Bug>> Doch, die betroffene stelle kann nie erreicht werden, wenn kein> undefinierter Code ausgeführt werden kann, ist es in Ordnung.
Das kann der Compiler nicht immer 100% genau erkennen. Dazu ist schon
etwas Code-Analyse notwendig. Deshalb ist es auch nur eine Warnung und
kein Fehler. Wenn du per -Werror dann einen Fehler draus machst, ist das
nicht die Schuld des Compilers.
In dem Fall ist es ja noch relativ einfach, aber das kann man beliebig
verkomplizieren. Generell immer kann der Compiler das nicht
sicherstellen.
Ggf hängt das übrigens auch noch von den Optimierungs-Einstellungen ab.
Da er bei hohen Optimierungsstufen mehr Code-Analyse machen muss,
erkennt er dann manche Fälle etwas präziser.
> Es ist egal, ob der Compiler den Code weglasst, oder dort sonst was> hinpflanzt, aber falsch ist es nicht. Das er warnt ist aber klar falsch.
Er warnt, weil es falsch sein könnte.
Wenn ich sowas schreibe wie:
[C]
int ret;
if (ret = myFunction())
[C]
warnt er auch, weil er glaubt, das müsse bestimmt keine Zuweisung,
sondern ein Vergleich sein.
Generell bin ich auch dafür, alle Warnungen aus dem Code zu entfernen.
Nur warnt gcc heute an so vielen Stellen, wo eigentlich kein Problem
ist, dass es schon langsam nervt, dauernd im Code irgendwas umschreiben
oder hinzufügen zu müssen, nicht weil dadurch der Code besser würde,
sondern nur um die an einigen Stellen eigentlich unnötigen Warnungen
wegzubekommen.
Bernd K. schrieb:> mh schrieb:>> Ich würd irre werden, wenn ich beim entwickeln Fehler der Formerror:>> unused parameter 'foo' [-Werror=unused-parameter]>> oder ähnlich belommen würde.>> Einige harmlose oder bedeutungslose Warnungen wie diese werden global> deaktiviert.
Ich sage dem Kompiler bei der Meldung statdessen explizit, dass das OK
ist. Ganz oben in den Funktionsrump kommt: "(void)foo;", und dann ist
dem Compiler klar, der Parameter ist absichtlich ungenutzt. Aber nicht
vergessen, die wieder raus zu nehmen, wenn der Parameter später doch mal
gebraucht wird.
Bernd K. schrieb:> Hat jemand einen aktuellen gcc und kann bestätigen daß das dort immer> noch auftritt? Meiner ist die letzte Version die das offizielle ARM ppa> ausspuckt, auf der ARM Webseite gibts aber schon neuere zum direkten> Download.
Ich habe den avr-gcc 9.2.0 zur Verfügung. In der Arduino IDE getestet
bringt es nur eine "left shift" Warnung.
C:\Users\devil\AppData\Local\Temp\arduino_modified_sketch_766131\sketch_aug22b.ino: In function 'int foo(int)':
4
C:\Users\devil\AppData\Local\Temp\arduino_modified_sketch_766131\sketch_aug22b.ino:24:21: warning: left shift count is negative [-Wshift-count-negative]
Bernd K. schrieb:> leo schrieb:>> Wenn ein Leftshift ploetzlich in>> die andere Richtung losgeht, ist schon voher was faul.>> Nein, der geht nicht "plötzlich" in die andere Richtung. Die Shiftweite> in meinem Beispiel war schon immer eine literale Konstante irgendwo mit> zwei simplen #define festgenagelt und war immer positiv und zur> Kompilezeit bekannt.
Ja, dann solltest Du das auch mit constexpr ausdrücken.
1
intfoo(intx){
2
constexprintshift=6-13;
3
ifconstexpr(shift<0){
4
returnx>>-shift;
5
}else{
6
returnx<<shift;
7
}
8
}
Allerdings: das geht nur mit einem C++-Compiler, un die Warnung ist
korrekterweise weg.
Rolf M. schrieb:> Wenn ich sowas schreibe wie:> [C]> int ret;> if (ret = myFunction())> [C]>> warnt er auch, weil er glaubt, das müsse bestimmt keine Zuweisung,> sondern ein Vergleich sein.
Das ist auch grenzwertiger Stil. Ich würde das nicht so hinschreiben.
IMHO ist das ein grober Designfehler der Sprache daß eine Zuweisung als
Ausdruck ausgewertet werden kann, ich finde es gut daß der Compiler da
warnt, denn man verliert nichts wenn man generell auf dieses "Feature"
verzichtet.
Wilhelm M. schrieb:> Allerdings: das geht nur mit einem C++-Compiler, un die Warnung ist> korrekterweise weg.
Es ging aber eben nicht um C++, damit erübrigt sich deine Lösung.
Jörg W. schrieb:> Wilhelm M. schrieb:>> Allerdings: das geht nur mit einem C++-Compiler, un die Warnung ist>> korrekterweise weg.>> Es ging aber eben nicht um C++, damit erübrigt sich deine Lösung.
Sehe ich nicht so: es ist wieder ein Grund über die Verwendung von C
nachzudenken. Vor allem, weil der Umstieg so einfach ist. Für den TO
könnte constexpr in genau dieser Übersetzungseinheit ein Anreiz sein.
Wilhelm M. schrieb:> es ist wieder ein Grund über die Verwendung von C nachzudenken
Diese Evangelisiererei nervt einfach.
Ihr „C++-Evangelisten“ solltet nicht davon ausgehen, dass C++ nur das
unerkannte Mauerblümchen sei, welches niemand kennt, weshalb ihr es
unbedingt allen nahelegen müsst. Diese Auffassung ist schlicht falsch:
jeder halbwegs erfahrende C-Programmierer kennt C++, kennt seine
Vorteile, seine Nachteile. Nichtsdestotrotz können sich (von ein paar
eigentständigen Hobbyprojekten vielleicht mal abgesehen) die meisten
dieser Programmierer einfach nicht aussuchen, die Sprache zu wechseln –
der Wechsel ist eben nicht so einfach, wie du suggerierst. Außerdem:
da, wo man sich die Sprache aussuchen kann, gewinnen oft andere, Python
beispielsweise.
Jörg W. schrieb:> Wilhelm M. schrieb:>> es ist wieder ein Grund über die Verwendung von C nachzudenken>> Diese Evangelisiererei nervt einfach.
Ich denke, ein Vorschlag in eine andere Richtung ist noch keine
Evangelisiererei. Ok, es ist vielleicht ein Vorschlag der Dir nicht
passt.
> Ihr „C++-Evangelisten“ solltet nicht davon ausgehen, dass C++ nur das> unerkannte Mauerblümchen sei, welches niemand kennt, weshalb ihr es> unbedingt allen nahelegen müsst.
Da liegst Du aber komplett daneben. Allerdings ist dieses Forum in der
Tat ein Ort, wo viele Personen einfach nicht aus ihrer C-Blase hinaus
schauen wollen und können.
> Diese Auffassung ist schlicht falsch:> jeder halbwegs erfahrende C-Programmierer kennt C++, kennt seine> Vorteile, seine Nachteile.
Das wage ich stark zu bezweifeln. Und das behaupte ich auch nicht von
mir.
> Nichtsdestotrotz können sich (von ein paar> eigentständigen Hobbyprojekten vielleicht mal abgesehen) die meisten> dieser Programmierer einfach nicht aussuchen, die Sprache zu wechseln –> der Wechsel ist eben nicht so einfach, wie du suggerierst.
Auch da bin ich anderer Meinung.
Wilhelm M. schrieb:> Da liegst Du aber komplett daneben. Allerdings ist dieses Forum in der> Tat ein Ort, wo viele Personen einfach nicht aus ihrer C-Blase hinaus> schauen wollen und können.
Das ist die Sicht derer, die nicht aus ihrer C++-Blase hinaus schauen
wollen und können – um mit deinen Worten zu kontern.
>> Diese Auffassung ist schlicht falsch:>> jeder halbwegs erfahrende C-Programmierer kennt C++, kennt seine>> Vorteile, seine Nachteile.>> Das wage ich stark zu bezweifeln.
Dann bezweifle es halt. Was genau hilft dir das jetzt?
> Auch da bin ich anderer Meinung.
Kannst du ja sein. Meine Meinung resultiert einfach aus Erfahrung.
Ich hätte persönlich überhaupt kein Problem, unsere Firmware hier in der
Firma in C++ zu verfassen, aber wir müssen unsere Brötchen irgendwie
verdienen. Was glaubst du, wer von unseren Kunden unseren Arbeitsaufwand
bezahlen möchte für einen Umbau von C auf C++? Das würde nur dann jemand
bezahlen, wenn sich daraus unmittelbar Probleme lösen ließen, die in C
nicht (mit vertretbarem Aufwand) lösbar wären. Aber so riesig ist der
Vorteil von C++ wiederum eben dann doch nicht. Es ist manches netter und
bequemer und schöner, gar keine Frage, aber in dem Bereich, in dem wir
arbeiten, gibt es kaum was, was nicht in C auch gänge, ohne dass man
dadurch nun unbillige Härte in Kauf nehmen müsste.
Und überall dort, wo es nicht (unbedingt) in Firmware sein muss,
dominiert schlicht und ergreifend Python. Da quält sich keiner mehr mit
C oder C++ ab. Die Millisekunde an Performance interessiert dann sowieso
keinen, und die Time-to-Market ist damit um Welten besser als in den
compilierten Sprachen.
Jörg W. schrieb:> Das würde nur dann jemand> bezahlen, wenn sich daraus unmittelbar Probleme lösen ließen, die in C> nicht (mit vertretbarem Aufwand) lösbar wären. Aber so riesig ist der> Vorteil von C++ wiederum eben dann doch nicht. Es ist manches netter und> bequemer und schöner,
Viel wichtiger ist doch, dass man in einen Bereich kommt, in dem Fehler
so früh wie möglich aufgedeckt werden. Also: compile-time statt
run-time.
> gar keine Frage, aber in dem Bereich, in dem wir> arbeiten, gibt es kaum was, was nicht in C auch gänge, ohne dass man> dadurch nun unbillige Härte in Kauf nehmen müsste.
Unbillige Härte: nur dann, wenn man die Holzhammermethode einsetzt.
> Und überall dort, wo es nicht (unbedingt) in Firmware sein muss,> dominiert schlicht und ergreifend Python.
Davon war doch gar keine Rede. Und auch das ist eine Pauschalaussage,
die so nicht stimmt. Es gibt Branchen, da sieht es anders aus, da spielt
Python gar keine Rolle. Und ich meine jetzt nicht C++-Nutzung.
Wilhelm M. schrieb:> ch denke, ein Vorschlag in eine andere Richtung ist noch keine> Evangelisiererei.
Dann schlage ich Dir an dieser Stelle noch Matlab vor. Der
"bitshift()"-Befehl hat dort auch keinerlei Probleme mit Vorzeichen.
Wilhelm M. schrieb:> Viel wichtiger ist doch, dass man in einen Bereich kommt, in dem Fehler> so früh wie möglich aufgedeckt werden. Also: compile-time statt> run-time.
Da hilft uns die Wahl der Programmiersprache praktisch gar nicht.
Aus dem Alter der totalen Anfängerfehler sind wir einfach mal raus. ;-)
> Davon war doch gar keine Rede. Und auch das ist eine Pauschalaussage,> die so nicht stimmt. Es gibt Branchen, da sieht es anders aus, da spielt> Python gar keine Rolle.
Keine Frage. Ich wollte damit nur ausdrücken: wenn man die Dose „andere
Programmiersprache“ öffnet (öffnen kann), dann ist es eben nicht nur C
vs. C++, sondern die Palette wird einfach breiter.
Wilhelm M. schrieb:> Viel wichtiger ist doch, dass man in einen Bereich kommt, in dem Fehler> so früh wie möglich aufgedeckt werden. Also: compile-time statt> run-time.
In dem obigen Fall ging es bereits um Compiletime, runtime stand hier
nirgendwo zur Debatte! Ich will entweder den if oder den else zweig
kompilieren, niemals beide gleichzeitig, der Optimizer hilft mir dabei.
Ein if auf ne konstante Bedingung hat schon so manches häßliche #ifdef
ersetzt. Mein shift ist konstant zur Kompilezeit! Wenn es kompiliert ist
es korrekt!
Würd ich das alles in C++ machen würd ich sicherlich auch keine Makros
verwenden die mir zur Compilezeit getypte und parametrierte Funktionen
generieren sondern ich würde die C++-Templatemechanismen ausschöpfen um
meine Filterfunktionen und anderen Krempel zu erzeugen. Ich müsste
etliches umkrempeln. Das will ich nicht. Noch nicht und schon dreimal
nicht für den alten in Produktion befindlichen Code, es ist nicht so daß
ich hier rumsitze und Däumchen drehe und aus schierer Langeweile neue
Baustellen aufreiße in perfekt funktionierenden Projekten. Ich hab hier
lang gewachsenes C, es war schon C bevor ich hier angefangen habe und
kein C++. Ende der Durchsage.
Bernd K. schrieb:> Wilhelm M. schrieb:>> Viel wichtiger ist doch, dass man in einen Bereich kommt, in dem Fehler>> so früh wie möglich aufgedeckt werden. Also: compile-time statt>> run-time.>> In dem obigen Fall ging es bereits um Compiletime, runtime stand hier> nirgendwo zur Debatte! Ich will entweder den if oder den else zweig> kompilieren, niemals beide gleichzeitig, der Optimizer hilft mir dabei.
Der Unterschied ist subtil, aber sehr wichtig, gerade auf für templates:
bei einem run-time if (wie bei Dir) müssen beide Zweige compiliert
werden, deswegen auf die warnings. Der Optimizer erst kann nachweisen,
dass er hier wegen const den false-Zweig verwerfen kann.
bei einem compile-time (constexpr) if wird der false-Zweig direkt
verworfen, d.h. nicht compiliert. Deswegen keine warning. Der Optimizer
ist arbeitslos.
Das ist ja ganz wichtig für templates, die dann im false-Zweig nicht
instantiiert werden.
Jörg W. schrieb:> Wilhelm M. schrieb:>> gerade auf für templates>> templates? In C?>> Ach, du lebst in deiner C++-Blase … :)
Ooch, lies doch mal alles. Ich habe auf Bernd K. geantwortet, der sich
wieder auf meinen Beitrag bezog.
Wilhelm M. schrieb:> Ooch, lies doch mal alles
Bitte lass trotzdem dein C++ hier raus. Schön dass dich das so
begeistert, sogar nachvollziehbar aber hier hilft es nicht.
Wilhelm M. schrieb:> Ich habe auf Bernd K. geantwortet
Bernd hat aber auch ausdrücklich geschrieben, dass es sich um C-Code
handelt. Damit sind irgendwelche Betrachtungen über Templates und deren
Compiler-Effizienz hinfällig genauso wie "constexpr" (ich sehe zumindest
nicht, dass jemand bereits constexpr in die aktuellen C-Standard-Drafts
eingebracht hätte).
Jörg W. schrieb:> Wilhelm M. schrieb:>> Ich habe auf Bernd K. geantwortet>> Bernd hat aber auch ausdrücklich geschrieben, dass es sich um C-Code> handelt.
Er sprach über alten Code, der schon vor seinem Eintritt in das Projekt
bestand. Er sagte auch, dass er es anders machen würde, wenn es kein
legacy-Code wäre.
Und ich hoffe für ihn und seine Firma, dass sie auch mal neue Sachen
machen.
Daniel A. schrieb:> Warnung -Wshift-count-negative, option zum ausschalten folglich> -Wno-shift-count-negative.
Das zählt natürlich nicht. Damit deaktivierst du ja das komplette
Potential dieser Warnung, auf echte (potentielle) Probleme hinzuweisen.
Das ist etwa als wenn du als Workaround für eine quietschende Bremse das
Bremssystem komplett deaktivierst. Ja klar, die Bremse quietscht dann
ganz sicher nicht mehr, aber das Auto knallt möglicherweise gegen die
nächste Wand...
> Das er warnt ist aber klar falsch. Ein false> positive.
Also doch ein BUG. Das ist der Punkt. Wir haben es bei der statischen
Codeanalyse nicht mit einer Heuristik zu tun. Wenn sie korrekt
implementiert wäre, hätte sie herausbekommen MÜSSEN, das hier kein
erkennbares Problem vorliegt und dementsprechend kein Anlaß für eine
Warnung vorliegt.
Andererseits müßte sie allerdings auch IMMER eine Warnung ausgeben,
wenn eine signed-Variable als Quelle für die Bitzahl des Shift dient,
wenn sie NICHT schon zur Compile-Zeit auflösbar ist. Denn dann hat sie
schließlich immer das Potential, zur Laufzeit negativ zu werden...
Allerdings würde dann bei sehr vielen Anwendungen der Programmierer mit
Warnungen geradezu geflutet.
Das eigentliche Problem ist also das absolut unlogische Design dieser
verschissenen Dreckssprache. Logisch wären zwei Varianten gewesen:
1) Ich akzeptiere negative Shifts und setze sie halt als positive Shifts
in die Gegenrichtung um.
2) Ich verbiete grundsätzlich signed Parameter für den Shift.
Alles andere ist unlogischer Dreck. Also genau das, was C macht und
weswegen ich C so abgrundtief hasse...
c-hater schrieb:> Also genau das, was C macht und> weswegen ich C so abgrundtief hasse...
Eigentlich magst Du C doch. Ansonsten gäbe es keinen vernünftigen Grund,
jeden Thread, wo es behandelt wird, aufzusuchen.
Bernd K. schrieb:> Wenn ich mal mehr Zeit hab mach ich nen Bugreport.
Es ist aber kein Bug: Der Compiler warnt lediglich, dass es hier
möglicherweise ein Problem gibt (und damit hat er recht).
Wie bereits geschrieben:
Jörg W. schrieb:> Naja, ohne Fehler compiliert es auch so schon, und das Ergebnis ist> korrekt. Es gibt ja keinen Fehler, sondern eine Warnung.>> Selbst die Warnung ist für sich genommen nicht falsch: der shift count> an dieser Stelle wäre ja tatsächlich negativ – nur dass die Stelle eben> aufgrund der äußeren Umstände garantiert nicht erreicht wird (was sich> ja auch im generierten Code reflektiert). Insofern ist die Warnung> verwirrend, aber eher eine Unschönheit denn ein tatsächlicher Bug.
Ein Bug würde vorliegen, wenn der generierte Code falsch ist.
Die Prüfung auf mögliche Probleme kann in verschiedenen Compiler Stages
durchgeführt werden. Ich bezweifle, dass sich die Maintainer für das
(eigentlich "selbst" eingebrockte) Problem des TE interessieren.
Solcher Code sollte imho gar nicht in einem Projekt auftauchen. -- Auch
wenn ich durchaus nachvollziehen kann wie es dazu kam.
Mikro 7. schrieb:> Es ist aber kein Bug: Der Compiler warnt lediglich, dass es hier> möglicherweise ein Problem gibt (und damit hat er recht).
Nein, er hat eben nicht Recht, es kann hier niemals ein Problem geben
und dieser Sachverhalt ist bereits zur Compilezeit eindeutig
verifizierbar. Also, ganz eindeutig: BUG.
Walter T. schrieb:> Eigentlich magst Du C doch. Ansonsten gäbe es keinen vernünftigen Grund,> jeden Thread, wo es behandelt wird, aufzusuchen.
Doch: Ich hasse es, weil ich die Schwächen kenne, bin aber viel zu oft
gezwungen, es zu benutzen. Ja, das (Erwerbs-)Leben ist halt kein
Ponyhof.
Wenn das kein Grund ist, was denn sonst?
c-hater schrieb:> Mikro 7. schrieb:>>> Es ist aber kein Bug: Der Compiler warnt lediglich, dass es hier>> möglicherweise ein Problem gibt (und damit hat er recht).>> Nein, er hat eben nicht Recht, es kann hier niemals ein Problem geben> und dieser Sachverhalt ist bereits zur Compilezeit eindeutig> verifizierbar. Also, ganz eindeutig: BUG.
Du hast offensichtlich den Unterschied zwischen einer Warn-und einer
Fehlermeldung nicht verstanden.
Der Compiler gibt eine Fehlermeldung aus, wenn der der betreffende
Quellcode formal (d.h. syntaktisch oder semantisch) inkorrekt ist.
Der Compiler gibt eine Warnmeldung aus, wenn der betreffende Quellcode
zwar formal korrekt ist, aber eine gewisse Wahrscheinlichkeit besteht,
dass er nicht das tut, was der Programmierer beabsichtigt hat.
Der zweite Fall trifft auf den Code des TE definitiv zu:
- Zu einen steht da (mit eingesetzter Konstante) der Ausdruck x<<-7. So
etwas ist in den allermeisten Fälle nicht beabsichtigt, weswegen es
legitim ist, dass der Compiler hier ein potentielles Problem aufzeigt.
- Dass der fragliche Code nie ausgewertet wird, ändert nichts daran,
dass x<<-7 fehlerhaft aussieht. Da es darüberhinaus auch unüblich ist,
nicht erreichbaren Code zu schreiben, wäre hier zusätzlich zur
ausgegebenen Warnung sogar noch eine entsprechende zweite Warnmeldung
angebracht (von der du vermutlich ebenso behaupten würdest, sie sei
ein Bug).
Da der TE weiter oben erklärt hat, wie es zu diesem seltsamen Code kam,
wissen wir, dass die Warnmeldung ignoriert werden dürfen. Der Compiler
hingegen kennt diese Erklärung nicht, da er in diesem Forum nicht
mitliest. Also kann man es ihm ein "Häh?" von seiner Seite wirklich
nicht verdenken.
Vermeintlich zu viele oder zu wenige ausgegebene Warnmeldung können
übriges niemals ein Bug sein , da der C-Standard nicht bindend festlegt,
wann und wo eine Warnung ausgegeben werden soll. Dies liegt allein im
Ermessen des Compilerbauers.
Yalu X. schrieb:> Der Compiler gibt eine Warnmeldung aus, wenn der betreffende Quellcode> zwar formal korrekt ist, aber eine gewisse Wahrscheinlichkeit besteht,> dass er nicht das tut, was der Programmierer beabsichtigt hat.
Die Wahrscheinlichkeit beträgt in diesem Fall aber ziemlich genau 0%, es
handelt sich um ein false-positive.
Außerdem: Baut man Code mit "-O0", verändern sich die Warnungen. Viele
Sachverhalte werden erst im Rahmen der Optimierung untersucht und führen
dann zu Warnungen - oder eben auch nicht, wenn keine Optimierung
stattfindet.
Warnungen sind super, und Warnungen zu UB sogar noch viel besser. Aber
diese ist schlicht irreführend und daher als Bug im Compiler zu
betrachten.
Yalu X. schrieb:> Dies liegt allein im Ermessen des Compilerbauers.
Du meinst also, dass "WONTFIX" für sämtliche Warnungen eine angemessene
Reaktion wäre? :-)
Hallo,
ihr denkt zu kompliziert. :-) Die Shiftweite, der Wert, darf nie
negativ sein. Der Wert ist nur ein Betrag und gibt nur an UM wieviele
Bits verschoben wird. Die Richtung geben allein die Operatoren vor. Du
musst also nur dafür sorgen das dein Shiftwert immer positiv ist. Nach
der einfachen Logik meckert der Compiler zu recht - kein Bug laut meiner
Meinung.
S. R. schrieb:> Yalu X. schrieb:>> Der Compiler gibt eine Warnmeldung aus, wenn der betreffende Quellcode>> zwar formal korrekt ist, aber eine gewisse Wahrscheinlichkeit besteht,>> dass er nicht das tut, was der Programmierer beabsichtigt hat.>> Die Wahrscheinlichkeit beträgt in diesem Fall aber ziemlich genau 0%, es> handelt sich um ein false-positive.
Um die Wahrscheinlichkeit auf 0 reduzieren zu können, müsste der
Compiler Gedanken lesen können.
Nur zur Klarstellung: Eine Compilerwarnung kann, muss aber nicht
notwendigerweise durch ein undefined Behavior ausgelöst werden. Der vom
TE gepostete Code bewirkt kein UB, dennoch ist er zunächst – ohne
weitergehende Erläuterungen des Programmierers – einfach nur unsinnig,
und das gleich aus zwei Gründen: wegen des negativen Shift-Arguments und
wegen des nicht erreichbaren Else-Zweigs. Ist es da falsch anzunehmen,
dass der Programmierers evtl. etwas anderes beabsichtigt hat?
> Yalu X. schrieb:>> Dies liegt allein im Ermessen des Compilerbauers.>> Du meinst also, dass "WONTFIX" für sämtliche Warnungen eine angemessene> Reaktion wäre? :-)
Ich habe nicht geschrieben, dass die Qualität der Warnmeldungen nicht
verbessert werden darf.
Also ich bekomm die Warning ganz einfach weg, also als Workaround:
1
staticinlineintyshift(intx,intshift)
2
{
3
if(shift<0){
4
returnx>>-shift;
5
}else{
6
returnx<<shift;
7
}
8
}
9
10
intfoo(intx){
11
constintshift=6-13;
12
returnyshift(x,shift);
13
}
Inline-Funktionen sind hier ohnehin Makros vorzuziehen, weil:
* Argumente nur 1x ausgewertet werden. Wenn man z.B. MAX als Makro
implementiert, werden die Argumente mehrfach ausgewertet. Das ist
schlecht bei Seiteneffekten, z.B. bei Ausdrücken (Funktionsaufruf) als
Argument, x++ o.ä. oder volatile.
* Bessere Diagnostics bei Syntax-Fehlern.
* Besser wartbar.
* Bessere Debugging-Erfahrung (zumindest mit ältlichen Debuggern).
Jedesmal wenn jemand vorzeichenbehaftete Werte schiebt, sollte
eigentlich sein Bürostuhl unter Strom gesetzt werden. Leider konnte ich
diese Policy in der Firma noch nicht etablieren.
Johann L. schrieb:> Inline-Funktionen sind hier ohnehin Makros vorzuziehen
In meinem Fall ist auch der Typ von x erst bekannt wenn die Funktion
erzeugt wird, ich müsste also auch diese inline-Hilfsfunktion jedesmal
extra erzeugen, deshalb hab ichs vorerst beim Makro belassen. Scheint
aber so daß selbst auf der kleinsten Optimierungsstufe schon nichts mehr
doppelt ausgewertet werden muss, also lass ichs erstmal so.
Durchsteppen (im source) kann ich das ganze Ding eh nicht weil der
Sourcecode des ganzen Gebildes in seiner endgültigen Form erst nach der
Makroexpansion überhaupt erst zu existieren beginnt.
Brrrz schrieb:> Jedesmal wenn jemand vorzeichenbehaftete Werte schiebt, sollte> eigentlich sein Bürostuhl unter Strom gesetzt werden.
Ich hab ehrlich gesagt noch nie verstanden, warum es sowohl in C, als
auch auf Maschinen-Ebene (zumindest bei denen, die ich kenne) für links
und recht zwei verschiedene Shift-Operationen mit nur positiven Werten
gibt, statt einfach einen Shift mit Vorzeichen zu machen, der beides
kann.
Rolf M. schrieb:> Ich hab ehrlich gesagt noch nie verstanden, warum es sowohl in C, als> auch auf Maschinen-Ebene (zumindest bei denen, die ich kenne) für links> und recht zwei verschiedene Shift-Operationen mit nur positiven Werten> gibt, statt einfach einen Shift mit Vorzeichen zu machen, der beides> kann.
Zuerst gab es halt div. CPUs und Assembler. Es ist egal ob du Shiftweite
+ Richtung oder ein Vorzeichen kodierst. Ersteres is halt klarer. Da
kann man das ganze auch gleich gut benennen:
LSL - logical shift left
LSR - logical shift right
ASR - arithmetic shift right
Besonders letzteres verkompliziert die Schieberei.
leo
Rolf M. schrieb:> Ich hab ehrlich gesagt noch nie verstanden, warum es sowohl in C, als> auch auf Maschinen-Ebene (zumindest bei denen, die ich kenne) für links> und recht zwei verschiedene Shift-Operationen mit nur positiven Werten> gibt, statt einfach einen Shift mit Vorzeichen zu machen, der beides> kann.
Für einen Wertebereich von -32 bis +31 brauchst du 6 Bit. Ob das nun "1
Bit im Opcode und 5 Parameterbits" sind oder "6 Parameterbits", ist
egal.
Ersteres ist flexibler, weil es 4 Varianten gibt: LSL, LSR, ASL, ASR.
Zwei davon (LSL und ASL) sind aber gleich, wenn man die schon im Decoder
gleich abhandeln kann, spart man Logik. Außerdem spart man Logik, wenn
man das Zweierkomplement nicht decodieren muss - schieben ist nicht
addieren.
Bernd K. schrieb:> Johann L. schrieb:>> Inline-Funktionen sind hier ohnehin Makros vorzuziehen>> In meinem Fall ist auch der Typ von x erst bekannt wenn die Funktion> erzeugt wird, ich müsste also auch diese inline-Hilfsfunktion jedesmal> extra erzeugen, deshalb hab ichs vorerst beim Makro belassen.
... und damit wären wir bei templates in C++.
Rolf M. schrieb:> Ich hab ehrlich gesagt noch nie verstanden, warum es sowohl in C, als> auch auf Maschinen-Ebene (zumindest bei denen, die ich kenne) für links> und recht zwei verschiedene Shift-Operationen mit nur positiven Werten> gibt, statt einfach einen Shift mit Vorzeichen zu machen, der beides> kann.
Auf Maschinenebene kann man das im Grunde definieren wie man will.
In der Definition einer höheren Programmiersprache wäre das schon
interessanter, denn man hätte dann ja konsequenterweise nur noch einen
Shift-Operator statt zwei. In C also nicht << und >>, sondern <> oder
was auch immer, in mitsamt Definition, welches Vorzeichen in welche
Richtung schiebt.
Spannend bliebe aber weiterhin die Sache bei negativem linkem Operanden.
Weil bei damaligen Maschinen beim Shift selbst mit definiertem
arithmetischem Shift nicht so ganz klar war, ob aus -1 einfach linksrum
-2 oder -3 wird, oder rechtsrum -1 oder -0.
Insofern wäre es leicht pervers gewesen, zwar eine negative Anzahl
zuzulassen, ohne aber ein klares Ergebnis bei negativem Operand zu
definieren.
A. K. schrieb:> In der Definition einer höheren Programmiersprache wäre das schon> interessanter, denn man hätte dann ja konsequenterweise nur noch einen> Shift-Operator statt zwei.
Vermutlich gerade WEIL die darunter liegende Maschine zwei
verschiedene Befehle hat muss man das in der Hochsprache ebenfalls
abbilden weil ansonsten womöglich der Compiler zur Compilezeit nicht
mehr wasserdicht beweisen kann ob es immer positiv oder immer negativ
ist und deswegen jedesmal Code für eine Fallunterscheidung und beide
Befehle einbauen müsste anstatt einfach nur den einen Befehl
hinzuschreiben den der Programmierer (der einzige der es wissen kann)
wollte.
Es gibt nämlich einen Fall, wo eine negative Zahl x bei -x negativ
bleibt. Und die Warnung kommt vermutlich schon von einem Compileschritt
vor der Ersetzung durch eine Konstante.
Bei char ist es die -128, die negativ bleibt.
900ss D. schrieb:> Wilhelm M. schrieb:>> und damit wären wir bei templates in C++>> du wirst langweilig.
und schaue - etwas schopfschüttelnd - zu wie man sich hier (in C) abmüht
;-)
Wilhelm M. schrieb:> und schaue - etwas schopfschüttelnd - zu wie man sich hier (in C) abmüht
Niemand müht sich ab. Wenn man weiß wie die Sprache tickt kann man viele
solcher Sachen locker flockig und sogar sauber hinschreiben bei denen
sich ein Anfänger noch die Augen reiben würde und man kommt schon
verdammt weit damit. Der Anfänger reibt sich aber auch bei C++ die Augen
wenn ihm die volle Macht dieser Sprache mit all ihren barocken Türmchen
und Erkerchen ins Gesicht geschleudert wird, also halbwegs Gleichstand.
Jörg W. schrieb:> Bernd K. schrieb:>> Der Anfänger reibt sich aber auch bei C++ die Augen>> Unleserliche Programme lassen sich in jeder Programmiersprache verfassen
Für einen Anfänger kann auch sauberer Code vollkommen unleserlich sein,
je mächtiger und komplexer die Sprache umso länger hält dieser Zustand
an.
Jörg W. schrieb:> Bernd K. schrieb:>> Der Anfänger reibt sich aber auch bei C++ die Augen>> Unleserliche Programme lassen sich in jeder Programmiersprache verfassen
Aber in keiner geht es besser als in Whitespace, da sieht man Garnichts.
Bernd K. schrieb:> je mächtiger und komplexer die Sprache umso länger hält dieser Zustand> an.
Nö. Simple Sprachen verursachen da mehr Kopfzerbrechen.
Ich finde Wilhelm durchaus auch in dieser Hinsicht nervig, aber das ist
noch lange kein Grund, deshalb nun alle möglichen Scheinargumente
hervorzuzaubern, warum die Sprache C++ Mist wäre. Diese "Argumentation"
ist einfach noch nerviger.
Jörg W. schrieb:> Scheinargumente> hervorzuzaubern, warum die Sprache C++ Mist wäre
Das hab ich doch gar nicht gesagt. Ich versuchte mit einem Augenzwinkern
einen Gleichstand herbeizuführen damit alle wieder beruhigt ihres Weges
gehen können. Ich nehme nur deshalb zufällig kein C++ weil sich halt
eben alles irgendwann mal so ergeben hat wie es heute ist und ich auch
noch nicht an harte Grenzen gestoßen bin, nicht weil ich irgendwas an
C++ auszusetzen hätte.
Jörg W. schrieb:> Bernd K. schrieb:>> einen Gleichstand herbeizuführen>> Ich finde, dass das eher Kindergartenniveau ist. "Du eins, ich eins."
Warum musst Du jetzt anfangen zu pöbeln, aus heiterem Himmel? Und Sachen
unterstellen die gar nicht gesagt wurden ("c++ sei mist")? Warum?
Bernd K. schrieb:> Jörg W. schrieb:>> Scheinargumente>> hervorzuzaubern, warum die Sprache C++ Mist wäre>> Das hab ich doch gar nicht gesagt. Ich versuchte mit einem Augenzwinkern> einen Gleichstand herbeizuführen damit alle wieder beruhigt ihres Weges> gehen können. Ich nehme nur deshalb zufällig kein C++ weil sich halt> eben alles irgendwann mal so ergeben hat wie es heute ist und ich auch> noch nicht an harte Grenzen gestoßen bin, nicht weil ich irgendwas an> C++ auszusetzen hätte.
Dabei könnte man doch gerade an diesem einen zufälligen Punkt anfangen,
etwas cherry-picking zu machen, indem man beides zusammen führt. Es ist
ja nun nicht schwer oder undurchsichtig, C und C++ via header-only zu
mischen.
Wilhelm M. schrieb:> Dabei könnte man doch gerade an diesem einen zufälligen Punkt anfangen,> etwas cherry-picking zu machen, indem man beides zusammen führt.
Vor allem weil das geradezu nach templates schreit... inline+template
ist der perfekte Ersatz für viele Makros. Ein anderes Beispiel dafür
sind die min/max-Funktionen - die lassen sich mit Makros nicht so toll
bauen.
Bernd K. schrieb:> Warum musst Du jetzt anfangen zu pöbeln, aus heiterem Himmel? Und Sachen> unterstellen die gar nicht gesagt wurden ("c++ sei mist")? Warum?
Die wurden nicht direkt gesagt, aber unterschwellig hast du genau das
ausgedrückt: groß, komplex, "barocke[n] Türmchen und Erkerchen ins
Gesicht geschleudert".
Das ist das, was ich schlicht unter Niveau fand.
Wilhelm M. schrieb:> Dabei könnte man doch gerade an diesem einen zufälligen Punkt anfangen,> etwas cherry-picking zu machen
Da hängt noch mehr dran, ich hab zum Beispiel stellenweise stark
abgespeckten startup-code ohne __libc_init_array und den ganzen Sermon,
ich initialisiere nur was für C nötig ist, und beim Linkerscript bin ich
mir auch nicht sicher ob da noch alle sections drin sind die nötig sind.
Und dann ist es die Zeit, ich müsste erstmal Rostlöser an den grauen
Zellen ansetzen um da wieder halbwegs in die Gänge zu kommen mit C++ und
wie ich das dann sauber mit dem alten Code mischen kann ohne
irgendwelchen Mist zu bauen. Und am Ende fang ich dann an vor lauter
Euphorie alles umzubauen was schon mal funktioniert hat, aber ich hab
auch nicht unendlich viele Ressourcen. Deshalb lass ich das erstmal. Ich
bin immer noch zufrieden mit dem was ich habe.
Bernd K. schrieb:> Da hängt noch mehr dran, ich hab zum Beispiel stellenweise stark> abgespeckten startup-code ohne __libc_init_array und den ganzen Sermon,> ich initialisiere nur was für C nötig ist, und beim Linkerscript bin ich> mir auch nicht sicher ob da noch alle sections drin sind die nötig sind.
Wer da sein eigenes Süppchen kochen möchte, muss das eben selbst pflegen
und die entsprechenden 7 Zeilen da hinein kopieren. Alle anderen welche
den 0815-Standard-Startup-Code aus Beispielen oder Projekt-Templates
verwenden müssen da gar nix tun.
Bernd K. schrieb:> Wilhelm M. schrieb:>> Dabei könnte man doch gerade an diesem einen zufälligen Punkt anfangen,>> etwas cherry-picking zu machen>> Da hängt noch mehr dran, ich hab zum Beispiel stellenweise stark> abgespeckten startup-code ohne __libc_init_array und den ganzen Sermon,> ich initialisiere nur was für C nötig ist, und beim Linkerscript bin ich> mir auch nicht sicher ob da noch alle sections drin sind die nötig sind.
Und so ein Vorgehen findest Du jetzt klar und durchsichtig? Mmh ...
> Und dann ist es die Zeit, ich müsste erstmal Rostlöser an den grauen> Zellen ansetzen um da wieder halbwegs in die Gänge zu kommen mit C++ und> wie ich das dann sauber mit dem alten Code mischen kann ohne> irgendwelchen Mist zu bauen.
Auch wenn ich mich wiederhole: man muss ja nicht alles auf C++
umstellen, es genügt dieses eine kleine Beispiel als Einstieg.
Jörg W. schrieb:> Die wurden nicht direkt gesagt, aber unterschwellig hast du genau das> ausgedrückt: groß, komplex, "barocke[n] Türmchen und Erkerchen ins> Gesicht geschleudert".>> Das ist das, was ich schlicht unter Niveau fand.
Also komm, jetzt lass aber mal wieder gut sein. Man kanns echt
übertreiben. "Unterschwellig". Ich glaub Dein Niveaudetektor läuft Amok,
kalibrier den bitte mal neu.
Dann lass doch einfach auch solche doofen Anspielungen sein. Ich weiß
echt nicht, was "barocke Türmchen und Erkerchen" sein sollen wenn keine
Provokation.
Bezüglich des Startup-Codes: ich sehe ja, dass es Gründe geben kann, ihn
gelegentlich zu erweitern (selig die AVR-Tage, wo man den mitgelieferten
Startup-Code eigentlich immer ohne weiteres Nachdenken benutzen konnte,
da er 99,9 % aller Anwendungsfälle abgedeckt hat), aber warum braucht
man solche Sonderlocken, __libc_init_array() rauszuwerfen? Wenn du das
nicht benutzt, wird das doch sowieso automatisch eliminiert.
Wilhelm M. schrieb:> Und so ein Vorgehen findest Du jetzt klar und durchsichtig? Mmh ...
Ist sehr klar und sehr durchsichtig und ISO-Konform. Der Startupcode ist
für C, nicht für C++, nicht für Rust und auch nicht für Pascal sondern
für C.
Jörg W. schrieb:> solche Sonderlocken, __libc_init_array() rauszuwerfen?
Weil das was es macht in C nicht gebraucht wird? Warum soll ich
Sonderlocken für C++ einbauen die gar nicht genutzt werden?
Bernd K. schrieb:> Weil das was es macht in C nicht gebraucht wird? Warum soll ich> Sonderlocken für C++ einbauen die gar nicht genutzt werden?
Zirkuläre Argumentation? "Ich kann C++ nicht benutzen weil ich dafür
meinen Startupcode anpassen muss was nicht nicht brauche weil ich C++
nicht benutze"
Bernd K. schrieb:> Jörg W. schrieb:>> solche Sonderlocken, __libc_init_array() rauszuwerfen?>> Weil das was es macht in C nicht gebraucht wird? Warum soll ich> Sonderlocken für C++ einbauen die gar nicht genutzt werden?
C++ ist erstmal einer der standardmäßigen Anwendungsfälle, aber das
heißt erstens ja nicht, dass es der einzige Fall ist, und zweitens,
wie schon geschrieben, kostet es nichts, das Ding drin zu lassen. Wenn
man es nicht benutzt, stört es letztlich nicht. Man muss sich ja nicht
zusätzliche Arbeit (und potenzielle Fehlerquellen) an Land ziehen, nur
um vorhandene und erprobte Technik zu kastrieren.
Ich überlege gerade, das Pendant eines statischen Konstruktors in einem
C-Projekt unterzubringen …
Jörg W. schrieb:> Ich weiß> echt nicht, was "barocke Türmchen und Erkerchen" sein sollen> wenn keine Provokation.
Eine neutrale Tatsachenfeststellung vielleicht, jetzt wo Du so direkt
fragst?
Ich hätte ja sonst weiter zu dem Thema nichts gesagt aber immerhin hast
diesmal Du grundlos einen Streit vom Zaun gebrochen und unterstellst
andern grundlos böse Absichten und dann auch noch Inkompetenz zwischen
den Zeilen. Und das noch als Moderator. Manchmal frag ich mich echt was
hier los ist, haben wir gerade wieder Vollmond oder was?
Bernd K. schrieb:> Eine neutrale Tatsachenfeststellung vielleicht
Dann siehst du die Aussage
"C ist eine antike primitive Sprache zur Verarbeitung von Bytes ohne
Möglichkeiten zur Abstraktion, Wiederverwendbarkeit, Modularisierung,
Ressourcen-Verwaltung, strukturierter Fehlerbehandlung und
Datenkapselung, welche hauptsächlich von Personen verwendet wird, die
fortschrittlichere Sprachen nicht verstehen"
sicherlich auch als neutrale Tatsachenfeststellung.
Jörg W. schrieb:> C++ ist erstmal einer der standardmäßigen Anwendungsfälle
Aber nicht in meinen C-Projekten.
Begründung lass ich jetzt weg, denn das geht keinen was an und wird eh
nur wieder mir im Munde umgedreht bei dem hohen Streitlustkoeffizienten
hier.
Dr. Sommer schrieb:> Dann siehst du die Aussage>> "C ist eine antike primitive Sprache zur Verarbeitung von Bytes ohne> Möglichkeiten zur Abstraktion, Wiederverwendbarkeit, Modularisierung,> Ressourcen-Verwaltung, strukturierter Fehlerbehandlung und> Datenkapselung, welche hauptsächlich von Personen verwendet wird, die> fortschrittlichere Sprachen nicht verstehen">> sicherlich auch als neutrale Tatsachenfeststellung.
Der letzte Telsatz beleidigt Personen, der andere Teil ist faktisch
falsch bis auf "antik", das ist zutreffend und "primitiv" teilweise
zutreffend.
Weder meine Türme noch die Erker haben irgendwen beleidigt (außer Dir
anscheinend) noch sind sie unzutreffend.
Bernd K. schrieb:> Weder meine Türme noch die Erker haben irgendwen beleidigt (außer Dir> anscheinend) noch sind sie unzutreffend.
Warum schriebst du dann "Türme" und "Erker" und nicht "mächtige
Funktionalität" und "effiziente Möglichkeiten"? Nicht beleidigend genug?
Bernd, lass gut sein. Wenn du eine offensichtlich extreme
Voreingenommenheit als "neutrale Tatsachenfeststellung" auszugeben
versuchst, dann müssen wir darüber nicht weiter diskutieren, denn wir
werden hier ohnehin keine Einigkeit erzielen.
Mach dein Ding, dein Problem ist ja zumindest halb gelöst. Ein Ticket
bei GCC kannst du allemal dafür öffnen, vielleicht interessiert sich
wirklich einer der Entwickler mal dafür und weiß, wo man dabei ansetzen
muss für eine Korrektur.
Dr. Sommer schrieb:> Bernd K. schrieb:>> Weder meine Türme noch die Erker haben irgendwen beleidigt (außer Dir>> anscheinend) noch sind sie unzutreffend.>> Warum schriebst du dann "Türme" und "Erker" und nicht "mächtige> Funktionalität" und "effiziente Möglichkeiten"? Nicht beleidigend genug?
Weder "Turm" noch "Erker" sind negativ besetzte Begriffe.
Und in zwei Stunden kommt der andere Moderator und räumt diese ganze
Bullshit-Diskussion die ihr da jetzt wegen NICHTS und aus purer
Langeweile vom Zaun gebrochen habt wieder weg.
Bernd K. schrieb:> Weder "Turm" noch "Erker" sind negativ besetzte Begriffe.
Warum hast du sie dann benutzt? Wolltest du andeuten, wie dekorativ und
geräumig C++ ist?
Dr. Sommer schrieb:> Bernd K. schrieb:>> Weder "Turm" noch "Erker" sind negativ besetzte Begriffe.>> Warum hast du sie dann benutzt? Wolltest du andeuten, wie dekorativ und> geräumig C++ ist?
Ja genau. Kurz nachdem ich "die volle Macht" erwähnte wollte ich noch
das Augenmerk auf die ansprechende Dekoration und Geräumigkeit lenken.
Und auf die vielen kleinen Winkel in denen man so gut Verstecken spielen
kann.
Und jetzt geh in den Keller und lach endlich mal!
Bernd K. schrieb:>> C++ ist erstmal einer der standardmäßigen Anwendungsfälle> Aber nicht in meinen C-Projekten.
Ich finde es super, wie du überall gerade argumentierst, warum Dinge
doof sind, weil sie gerade in deinem aktuellen Anwendungsfall nicht
passen.
Cool, dass du einen zertifizierten Startup-Code für C geschrieben hast
und den für C++ neu zertifizieren lassen müsstest. Echt geil. Hat aber
nix mit C++ zu tun, sondern mit deinem zertifizierten Startup-Code.
S. R. schrieb:> Echt geil. Hat aber> nix mit C++ zu tun, sondern mit deinem zertifizierten Startup-Code.
Und was hat der ganze Thread hier überhaupt mit C++ zu tun?
Verfolgst Du mich jetzt durch das ganze Forum und mußt überall Deinen
Senf dazugeben? Was hat das hier diskutierte Thema mit C++ zu schaffen,
was hab ich damit zu schaffen? Geh woanders hin und nimm die C++
Evangelisten gleich alle mit, das nervt echt langsam!
S. R. schrieb:> Ich finde es super, wie du überall gerade argumentierst, warum Dinge> doof sind, weil sie gerade in deinem aktuellen Anwendungsfall nicht> passen.
So? Wo tu ich das denn? Ich glaub Du leidest unter Wahnvorstellungen.
Hier bei dem Thema gehts um eine reine C-Angelegenheit. Natürlich finde
ich es dann doof wenn überall Evangelisten aus den Löchern kommen die
mir andere Programmiersprachen aufschwatzen wollen, so penetrant wie
verzweifelte Staubsaugervertreter.
S. R. schrieb:> Cool, dass du einen zertifizierten Startup-Code für C geschrieben hast
Jetzt geht der Fieberwahn endgültig mit Dir durch, wo hab ich was von
zertifiziert geschrieben? Wenn ich was zertifiziertes haben will dann
kauf ich das irgendwo fertig, glaubst Du ich spiel in so einem
lächerlichen Zertifikatszirkus freiwillig als der Clown in der Manege
mit?
Johann L. schrieb:> Jörg W. schrieb:>> Ich überlege gerade, das Pendant eines statischen Konstruktors in einem>> C-Projekt unterzubringen …>> Du meinst Attribut constructor?
Yo, hatte ich dann auch gefunden und mir angesehen, was dabei rauskommt.
Jörg W. schrieb:> Bernd K. schrieb:>>> Warum musst Du jetzt anfangen zu pöbeln, aus heiterem Himmel? Und Sachen>> unterstellen die gar nicht gesagt wurden ("c++ sei mist")? Warum?>> Die wurden nicht direkt gesagt, aber unterschwellig hast du genau das> ausgedrückt: groß, komplex, "barocke[n] Türmchen und Erkerchen ins> Gesicht geschleudert".>> Das ist das, was ich schlicht unter Niveau fand.
Deine Argumentation kommt mir bekannt vor, so hast Du mich zum Natsieh
gemacht.
Gruß,
Holm
Holm T. schrieb:> Deine Argumentation kommt mir bekannt vor, so hast Du mich zum Natsieh> gemacht.
Dazu hast du dich nebenan schon selbst gemacht:
Holm T. schrieb:> und wenn es hier so weiter geht kommen Neuentwicklungen nur noch in der> Form vom Kamel- und Schafsrassen, Burkas und fliegenden Teppichen aus> Deutschland.
Rolf M. schrieb:> Holm T. schrieb:>> Deine Argumentation kommt mir bekannt vor, so hast Du mich zum Natsieh>> gemacht.>> Dazu hast du dich nebenan schon selbst gemacht:>> Holm T. schrieb:>> und wenn es hier so weiter geht kommen Neuentwicklungen nur noch in der>> Form vom Kamel- und Schafsrassen, Burkas und fliegenden Teppichen aus>> Deutschland.
Jörg war schneller, das was Du da zitierst ist noch nicht so alt und ich
bin nach wie vor der Überzeugung das ich damit nicht falsch liege.
Schicke mir ne PN wenn Du weiter zanken willst.
@Bernd: Nachdem Du Deine Befindlichkeiten wieder des langen und breiten
ausgekippt und jeden 2. abgecancelt hast stören Dich nun andere User?
Ich sag mal dazu: Achwas. Tut mir unendlich leid.
Gruß,
Holm
Thread beobachten
Seitenaufteilung abschalten