Variablen mit 0 initialisieren

@ Stefan Us (stefanus)

>int counter=0;
>int counter;

>Mit ist allerdings aufgefallen, dass in beiden Fällen exakt der selbe
>Assembler Code erzeugt wird. Also wird das wohl vom Compiler weg
>optimiert.

Der ist halt nicht ganz doof.

>Ist es falsch, globale Variablen mit 0 zu initialisieren?

Nö.

Stefan U. schrieb:
> Also wird das wohl vom Compiler weg
> optimiert.

Inzwischen ja, früher beim GCC jedoch nicht.  Muss also keineswegs
jeder Compiler gleich handhaben.

> Da ich mit vielen unterschiedlichen Programmiersprachen arbeiten muss,
> habe ich mir sicherheitshalber angewöhnt, Variablen immer zu
> initialisieren. Wenn ich in jedem Einzelfall überlegen muss, welche
> Sonderlocken die eine oder Sprache hier gerade hat, baue ich potentiell
> mehr funktionale Fehler.

Bei welcher Programmiersprache wäre es denn nicht definiert?

zeitler schrieb:
> Aber nicht lokale!

Doch, auch, aber nur, wenn sie "static" sind.

Ist also eher eine Frage der Speicherklasse denn des
Sichtbarkeitsbereichs.

Stefan U. schrieb:
> Aber ich möchte sichergehen, dass ich die Unterschiede der Sprachen
> nicht durcheinander werfe.

Wirst du wohl oder übel aber müssen, denn bei anderen Sprachen willst
du ja vielleicht lieber ein

1

$variable = undef;

oder

1

variable = None

oder etwas dergleichen stattdessen benutzen.

asdfasd schrieb:
> Wird kein bestimmter Inhalt vorrausgesetzt weil das Programm die
> Variablen zur Laufzeit initialisiert, werden sie auch nicht mit
> irgendwelchen Dummywerten initialisiert.

Wenn sie keinen expliziten Wert bei der Definition bekommen, werden sie 
automatisch mit 0 initialisiert. Das ist kein "Dummywert", sondern 
einfach nur der Default. Ob ihnen dann später ein anderer Wert 
zugewiesen wird, ist dafür unerheblich, weil der Compiler in der Regel 
nicht sicherstellen kann, daß die Variable vor dieser Zuweisung nicht 
schon irgendwo benutzt wird und dort noch den alten Wert haben muss.

> Das Initialisieren dient also der Dokumentation des Programms - es
> zeigt dem Leser, welche Annahmen das Programm bzgl der Variablen macht.
> Diese Dokumentationsmöglichkeit sollte man nicht aus irgendwelchen
> Hirngespinnsten heraus ("hab mal gehört, dass könnte evtl ein paar Bytes
> Plattenplatz oder 3 Taktzyklen beim Programmstart einsparen") aufgeben.

Es geht wohl eher nicht nicht um Plattenplatz, da ein kleiner 8-Bitter 
mit 1k Flash und 64 Bytes RAM keine Festplatte hat. Da kann es schon 
relevant sein, wie die 0 in die Variable kommt.

Markus schrieb:
> Ist bei mir schon eine Weile her, aber die Initialisierung globaler
> Variablen erzeugt m.W.n. keinen ausführbaren Code

Das nicht, aber in älteren GCC-Versionen wurde auch für mit 0
initialisierte globale und statische Daten zusätzlicher Speicherplatz
benötigt (egal, ob nun auf Festplatte oder im Flash eines Controllers),
da der Initialwert dort wie alle anderen Initialwerte von .data
behandelt worden ist.  Das ist dann schon eine Pessimierung gegenüber
der Variante, bei der (im so genannten .bss) einfach nur notiert wird,
wie viel Speicher beim Programmstart auszunullen ist.

Das Ausnullen des globalen und statischen Speichers beim Start ist
ein Feature, welches in C schon immer definiert war, insofern ist es
völlig korrekt, sich drauf zu verlassen.  Wenn man sich nicht darauf
verlassen kann, dann kann man sich auch nicht mehr drauf verlassen,
dass „int foo = 0;“ auch tatsächlich die Variable „foo“ mit 0
initialisiert und nicht vielleicht mit 42 …

BirgerT schrieb:
> einfach auch um die Warnmeldung "Variable XXX may be used uninitialised"
> zu umgehen.

Eine meiner Lieblingssünden.  Nein, nicht diese Warnung, sondern
stattdessen platt und pauschal eine Initialisierung vorzusehen. ;-)

Die verhindert nämlich die Generierung der Warnung bei Tippfehlern.
Sowas hier zum Beispiel:

1

   int i, j;

2

3

   for (i = 0; i < MAX; i++) {

4

     do_something(array[j]);

5

     // ...

6

     j = i + 42;

7

     // ...

8

   }

Klar, hier ist es offensichtlich, aber wenn da noch ein bisschen bla
und blubb ringsum stehen, übersieht man sowas schon schnell mal.  Wenn
du jetzt „aus Prinzip“ stets Initialisierungen schreibst:

1

   int i = 0, j = 0;

2

3

   for (i = 0; i < MAX; i++) {

4

     do_something(array[j]);

5

     // ...

6

     j = i + 42;

7

     // ...

8

   }

… dann bekommst du für den fehlerhaften Code nichtmal mehr eine
Warnung.

ffff schrieb:

> Reinkommen muss die 0 ja sowieso. Ob das der Compiler jetzt default
> macht(oder der Controller) oder ich explizit ist völlig egal.

Nein, ist es nicht.

Das Ausnullen der globalen und statischen Variablen beim Programmstart
erfolgt recht effektiv en bloc.

> Ich weiß auch
> nicht, ob der C-Standard(ANSI-C -> C90) das so vorgibt.

Wenn du die Sprache nicht kennst, solltest du sie auch nicht benutzen.

BirgerT schrieb:
> Jörg W. schrieb:
>> Sowas hier zum Beispiel:
>>    int i, j;
>>
>>    for (i = 0; i < MAX; i++) {
>>      do_something(array[j]);
>>      // ...
>>      j = i + 42;
>>      // ...
>>    }
>
> innerhalb von Schleifen brauche ich nur selten globale Variablen..
>
> for (uint8_t cnt = MAX; cnt > 0; --cnt) {;}

in dem Beispiel sind i und j aber lokale Variablen und und vor allem:
 bei dir fehlt das j das bei Jörg nicht initialisiert war

Walter S. schrieb:
> in dem Beispiel sind i und j aber lokale Variablen

Ja, nur dafür kann man ja die Warnung auch bekommen, denn globale
Variablen sind ja immer initialisiert.

Insofern ist das natürlich hier off-topic (denn hier ging es um
Variablen mit static storage), ich wollte nur die Argumentation mal
anbringen, dass das „sicherheitshalber immer“ Vorsehen eines 
Initializers
keineswegs so vernünftig ist, wie es auf den ersten Blick scheint.

ffff schrieb:
> Das ist ein scheiß Beispiel, weil es in C kein bool gibt...

Da bist du wohl noch auf einem arg alten Stand. bool wurde vor 16 Jahren 
zum offiziellen Bestandteil von C gemacht.

Peter II schrieb:
>
> Ich schreibe auch nicht
>
>

1

> if ( a == true )

2

>

Das ist auch besser so.
Abgesehen davon, dass das Augenkrebs erzeugt, ist das möglicherweise 
falsch.
Ich habe schon Code gesehen, bei dem true != TRUE war.

Stefan U. schrieb:
> Also wenn zum Standard gehört, dann wundert es mich schon, dass man dazu
> eine Header Datei einbinden muss

Die Headerdatei musst du nicht einbinden, wenn du “_Bool” als Typnamen
benutzt.  Dieser Name ist “intrinsic”.

Lediglich wenn du den (bequemer les- und schreibbaren) Namen “bool”
benutzen willst, musst du sie einbinden.  Der Grund ist einfach, dass
dieser Name vor C99 im application namespace lag, und es daher legal
war, dass eine Applikation den Namen selbst definiert hat.  Dadurch
verbot es sich, den nächsten Standard dazu inkompatibel zu machen.
In dieser Hinsicht ist man bei C etwas vorsichtig (anders als bspw.
bei Python).  Solche Art Vorsicht dürfte durchaus dazu beigetragen
haben, dass C derart allgegenwärtig ist, trotz aller (nicht unbekannten)
Macken.

Stefan U. schrieb:
> Also wenn zum Standard gehört, dann wundert es mich schon, dass man dazu
> eine Header Datei einbinden muss

Mich nicht. Und zwar ...

Stefan U. schrieb:
> Ich merke schon, C verwöhnt uns mit Stabilität. Wenn ich einen alten
> Code compilieren kann, dann wird er auch funktionieren (jedenfalls
> normalerweise).

... genau deshalb.

Stefan U. schrieb:
> Jetzt bin ich aber verunsichert,

Dann drücke deine Verunsicherung den in Halle Lehrenden mal aus.
Nach mehr als 15 Jahren hätten sie schon mal ihre Lehre ein wenig
aktualisiert haben können.

(Wenn man natürlich als glänzendes Beispiel nur Microsoft vor Augen
hat, die sich seit Jahr und Tag sträuben, etwas Moderneres als den
mehr als 25 Jahre alten ersten C-Standard zu implementieren, dann
sollte man sich über sowas nicht wundern.)

Peter II schrieb:
> sondern konzentrieren sich auf C++

War das nicht vielmehr C#?

A. K. schrieb:
> Peter II schrieb:
>> sondern konzentrieren sich auf C++
>
> War das nicht vielmehr C#?

Nicht nur. Es wird auch fleißig an neuen C++ Features gearbeitet.
http://blogs.msdn.com/b/vcblog/archive/2015/06/19/c-11-14-17-features-in-vs-2015-rtm.aspx

Peter II schrieb:
> sie halten halt nicht am alten C fest, sondern konzentrieren sich auf
> C++

Man könnte das eine tun, ohne das andere lassen zu müssen.  Alle
außer Winzigweich schaffen das schließlich problemlos (und damit
meine ich nicht nur GCC oder clang, sondern auch die kommerziellen
wie IAR).

Dann sollten sie konsequent sein und den Support für C gänzlich
einstampfen.

Jörg W. schrieb:
> Dann sollten sie konsequent sein und den Support für C gänzlich
> einstampfen.

Nope, das ergibt schon Sinn. Alte Programme sind in C, neue in C++/C#. 
Die alten sollen übersetzbar bleiben, mehr aber auch nicht. Die längst 
favorisierten Libs kannst du in C sowieso nicht nutzen.

Peter II schrieb:
> Das kann aber eine Firma für sich selber entscheiden.

Klar dürfen sie das, aber dann müssen sie sich auch nicht wundern,
wenn man ihnen nachsagt, dass sie hinter dem Mond leben.

Ich würde jedenfalls in keinem meiner Programme heutzutage mehr
irgendwelche Verrenkungen anstellen, damit sie sich auf einem
prä-C99-Compiler übersetzen lassen.

Jörg W. schrieb:
> Ich würde jedenfalls in keinem meiner Programme heutzutage mehr
> irgendwelche Verrenkungen anstellen, damit sie sich auf einem
> prä-C99-Compiler übersetzen lassen.

Dann compilier einfach unter C++. Es gibt zwar so ein paar C Features 
wie Variable Length Arrays und Flexible Array Members die es nur in C 
gibt aber benutzt die dort überhaupt jemand?

Sebastian V. schrieb:
> Dann compilier einfach unter C++.

Ah ja, noch einer, der glaubt, C sei eigentlich nur eine Untermenge
von C++?

Vergiss es.  Probier's doch einfach mal, ein größeres Stück Software,
in C geschrieben, durch einen C++-Compiler zu scheuchen.

> aber benutzt die dort überhaupt jemand?

Ja, auch diese, neben named initializers beispielsweise.

Wenn ich C++ schreiben möchte, dann würde ich es auch tun, aber dann
sehen die Programme eben auch grundlegend anders aus.  Statt eines
named initializers hätte ich dann beispielsweise einen Konstruktor.

Aber deshalb den Aufwand spendieren, existierenden C-Code mit wohl
mehreren Mannjahren Inhalt in C++-Code umzuschreiben, der letztlich
nur das gleiche tut (was auch noch getestet werden müsste)?  Nee,
da ist mir meine Lebenszeit zu schade.  Dann nehme ich einfach einen
der vielen ordentlichen C-Compiler, und wenn jemand den Salat für
Windows compilieren will, dann muss er sich eben vom MS-Compiler
verabschieden.  Es gibt ja auch dort Alternativen.

Peter II schrieb:
> Scheinbar bist du ein kleiner Teil der Entwickler die noch Anwendungen
> für PCs mit C schreiben.

Wer spricht denn von neu schreiben?

Es geht um Code, in dem schon ein Jahrzehnt (oder mehr) an Entwicklung
drin steckt, und der trotzdem noch weiterentwickelt werden soll,
ohne dabei deshalb nun drauf verzichten zu müssen, dass sich auch die
Sprache C im Laufe ihrer vier Jahrzehnte weiterentwickelt hat.

Mach mal.  Für den Anfang: schreib' mir AVRDUDE auf C++ um.

In 5 Jahren sehen wir uns dann wieder … zumindest, wenn du es in
deiner Freizeit machen musst.

Jörg W. schrieb:
> Mach mal.  Für den Anfang: schreib' mir AVRDUDE auf C++ um.

Was heißt jetzt auf C++ umschreiben? So umschreiben, dass es mit einem 
C++ Compiler compiliert oder komplett alles auf C++ umstellen? Ich hab 
mir gerade mal den Source geladen und alles in Visual Studio gepackt. 
Erstmal ist AVRDUDE mal wieder so ein Teil was die Existenz von Windows 
komplett ignoriert. Überall includes für sys/time.h, unistd.h und 
anderer lustiger Sachen wie optarg, die es nur unter Linux gibt. 
Außerdem ein tolles configure Script was ich natürlich auch nicht 
starten kann. Ansonsten hab ich noch inline Assembler an zwei Stellen 
und Variable Lenght Arrays an einer Stelle gefunden. Von 45 .c Dateien 
compilieren jetzt 40 Stück. Irgendwas scheint mit der Konfiguration für 
den USB Teil noch nicht zu stimmen. Wenn man wollte könnte man AVRDUDE 
aber sicherlich mit Visual Studio ans laufen kriegen. Dabei ist das 
größte Problem nicht die fehlenden C99 Features sondern die Ausrichtung 
des Projekts auf eine Linux Umgebung.

Sebastian V. schrieb:
> Überall includes für sys/time.h, unistd.h und
> anderer lustiger Sachen wie optarg, die es nur unter Linux gibt.

Die gibts nicht nur unter Linux, sondern auch unter Unix. ;-)

Okay, <sys/time.h> könnte man besser als <time.h> scheiben - offenbar 
ein kleiner Fauxpax von Jörg. Denn <time.h> gehört zur 
C-Standard-Bibliothek und wird natürlich auch von C-Entwicklungssystemen 
unter Windows unterstützt.

<unistd.h> gehört zum POSIX-Sprachumfang und hat trotzdem nur bedingt 
mit unixoiden Systemen zu tun. Denn POSIX wird/wurde auch auf manchen 
"alternativen" Betriebssystemen unterstützt.

Zum Beispiel Windows:

Microsoft selbst musste in den 90er Jahren beim amerikanischen Militär 
eine Bestätigung unterschreiben, dass sie POSIX in vollem Umfang 
unterstützen. Sonst wären sie dort nämlich sang- und klanglos 
rausgeflogen. Genau aus diesem Grunde wurde damals in Windows NT unter 
anderem eine POSIX-1.0-kompatible Umgebung eingepflanzt. Über die Jahre 
fand hier allerdings wieder eine Rückentwicklung statt. Die 
POSIX-Version wurde zunächst nicht weiter gepflegt und später wieder 
entfernt. Warum, kann man nur spekulieren: Wahrscheinlich wurde denen 
Posix lästig. Hauptsache, sie hatten den Wisch beim Militär.

> Außerdem ein tolles configure Script was ich natürlich auch nicht
> starten kann.

Tja, Windows eignet sich halt nur bedingt zur Entwicklung ;-)

Und trotzdem: avrdude-Portierungen auf Windows existieren.

> Dabei ist das
> größte Problem nicht die fehlenden C99 Features sondern die Ausrichtung
> des Projekts auf eine Linux Umgebung.

Komisch, wo kommt dann das avrdude.exe auf meinem Rechner her?

Sebastian V. schrieb:
> Dabei ist das größte Problem nicht die fehlenden C99 Features sondern
> die Ausrichtung des Projekts auf eine Linux Umgebung.

Du irrst komplett.

Das Ding compiliert locker unter MinGW (und nein, MinGW hat keine
Unix-Umgebung, sondern eine Windows-Umgebung), sogar als Crosscompilat.

Letzteres ist der Weg, wie ich derzeit den Windows-Nutzern ihre .exe
bereit stelle.

Die beiden inline-Assembler-Dinge sind inb() und outb() für den
(eher historischen) direkten Parallelportzugriff, unter Windows
übrigens (die Unixe bieten dafür nämlich eine Abstraktion, die sauber
über einen Treiber geht, nur Windows hat sowas nie nötig gehabt).  Wenn
das das einzige Problem wäre, würde sich schätzungsweise irgendein
Pendant dafür für den MS-Compiler finden lassen.

<sys/time.h> gab's meiner Erinnerung sogar schon vor 25 Jahren auf
Turbo-C.

Frank M. schrieb:
> Genau aus diesem Grunde wurde damals in Windows NT unter
> anderem eine POSIX-1.0-kompatible Umgebung eingepflanzt.

In diesem "POSIX subsystem" gab es eine volle Entwicklungsumgebung 
(kommandozeilenorientiert).
Und zwar gcc mit der ganzen toolchain :-)

Jörg W. schrieb:
> Das Ding compiliert locker unter MinGW (und nein, MinGW hat keine
> Unix-Umgebung, sondern eine Windows-Umgebung), sogar als Crosscompilat.

Wie auch immer man genau eine Linux/Windows/POSIX-Umgebung definiert. 
Ich kenne MinGW nicht wirklich aber offensichtlich bringt es Header mit 
die es so eigentlich nicht unter Windows gibt und eher Linux/POSIX 
typisch sind. Außerdem soll man damit configure Scripte ausführen 
können, was ja sonst auch nicht unter Windows geht. Es ist zwar keine 
komplette Umgebung wie Cygwin aber bringt zumindest Teile mit.

Frank M. schrieb:
> Okay, <sys/time.h> könnte man besser als <time.h> scheiben

In <sys/time.h> gibts doch noch ganz anderes Zeug als in <time.h>. Ich 
hab auf die schnelle jetzt sowieso nicht gesehen was aus <sys/time.h> 
überhaupt gebraucht wird. Ich hab für meinen Test die includes überall 
auskommentiert und es schien nichts wichtiges zu fehlen.

Jörg W. schrieb:
> <sys/time.h> gab's meiner Erinnerung sogar schon vor 25 Jahren auf
> Turbo-C.

Von mir aus kanns das sonstwo gegeben haben. Wenn es nicht Teil des 
C-Standards ist und man es trotzdem benutzt, sollte man am Ende nicht 
über Visual Studio meckern, weil es den Header dort nicht gibt.

Sebastian V. schrieb:

> Ich kenne MinGW nicht wirklich aber offensichtlich bringt es Header mit
> die es so eigentlich nicht unter Windows gibt und eher Linux/POSIX
> typisch sind.

Wobei sich dieser Teil "msvcrt" nennt, also die Kompatibilität zu
Microsoft-C.

> Außerdem soll man damit configure Scripte ausführen
> können, was ja sonst auch nicht unter Windows geht.

Das ist aber kein Feature von MinGW, sondern hängt an einer Bash
und ein paar Shell-Utilities.  Interessiert mich fürs Crosscompilat
aber nicht, da dort das configure ja noch native auf meinem FreeBSD
läuft.

> Es ist zwar keine
> komplette Umgebung wie Cygwin aber bringt zumindest Teile mit.

Nein, es ist komplett anders.  Cygwin emuliert das Posix-API.  MinGW
bietet das Win32-API.  <unistd.h> ist beispielsweise nahezu leer.

> Ich
> hab auf die schnelle jetzt sowieso nicht gesehen was aus <sys/time.h>
> überhaupt gebraucht wird. Ich hab für meinen Test die includes überall
> auskommentiert und es schien nichts wichtiges zu fehlen.

Ich habe auch keine Ahnung, warum das da drin steht. ;-)  Ja,
AVRDUDE ist historisch natürlich unter Unix entstanden (FreeBSD
in diesem Falle), die Erweiterung in Richtung Win32 kam später.
Da aber offenbar diejenigen, die die Erweiterung geschrieben haben
(die dann schon native sind, siehe ser_win32.c), sich nicht an den
schon existierenden <sys/time.h> und <unistd.h> gestört haben, sind
sie halt noch drin geblieben.

> Wenn es nicht Teil des
> C-Standards ist und man es trotzdem benutzt, sollte man am Ende nicht
> über Visual Studio meckern, weil es den Header dort nicht gibt.

Hat doch auch keiner, oder wo siehst du das?

Ich habe über den C-Compiler von Visual Studio nur gemeckert, weil
er standard-mäßig hinter dem Mond lebt und damit immer mehr obsolet
wird.

Sebastian V. schrieb:
> Wie auch immer man genau eine Linux/Windows/POSIX-Umgebung definiert.
> Ich kenne MinGW nicht wirklich aber offensichtlich bringt es Header mit
> die es so eigentlich nicht unter Windows gibt und eher Linux/POSIX
> typisch sind.

Das hört sich so an, als ob Windows bzw. Microsoft den Standard 
definiert, was C betrifft. Das ist ein Irrtum. C gab es schon zu Zeiten, 
als "Windows" tatsächlich nur Fenster im Mauerwerk waren.

Tatsächlich ist es umgekehrt: C wurde Anfang der 70er auf Unix-Rechnern 
für Unix-Rechner entwickelt. Microsoft hat in den 80ern zunächst nur 
erbärmliche Versuche unternommen, selbst ein C-Entwicklungssystem für 
Windows einzuführen. Von irgendeinem C-Standard unter Windows konnte da 
keine Rede sein.

Also wenn unter Windows irgendein Header fehlt, dann liegt es nicht 
daran, dass er nicht zum Standard gehört, sondern es liegt einfach 
daran, dass es in Windows wegen Unfähigkeit fehlt - siehe <unistd.h>.

Du kannst nicht einfach argumentieren, dass alles, was unter Windows 
nicht verfügbar ist, auch nicht zum Standard gehört. POSIX ist ein 
Standard.

> In <sys/time.h> gibts doch noch ganz anderes Zeug als in <time.h>.

Du hast offenbar nicht verstanden, warum es solche Konstruktionen wie

     <irgendein-include.h>

     <sys/irgendein-include.h>

überhaupt gibt. Das erste Include beschreibt 
Schnittstellen/Datenstrukturen, die Betriebssystem-unabhängig sind. Das 
zweite beschreibt dann den Betriebssystem-abhängigen Teil. Warum Jörg da 
<sys/time.h> verwendet, hat wahrscheinlich rein historische Gründe: 
Früher (vor über 20 Jahren) gab es nur das Betriebssystem-abhängige 
Teil. Später wurde das geändert bzw. aufgetrennt in 2 Includes.

> Ich
> hab auf die schnelle jetzt sowieso nicht gesehen was aus <sys/time.h>
> überhaupt gebraucht wird. Ich hab für meinen Test die includes überall
> auskommentiert und es schien nichts wichtiges zu fehlen.

Es kommt immer mal vor, dass man bestimmte Standard-Header in neue 
C-Quellcodes einfach schon mal reinkopiert - auch wenn man sie später 
nicht braucht. Ist Dir wahrscheinlich noch nie passiert.

> Von mir aus kanns das sonstwo gegeben haben. Wenn es nicht Teil des
> C-Standards ist und man es trotzdem benutzt, sollte man am Ende nicht
> über Visual Studio meckern, weil es den Header dort nicht gibt.

Auch das liest sich so, als ob Du den C-Standard über das Betriebssystem 
Windows definierst. Das ist falsch. Der C-Compiler von Microsoft ist nur 
eine erbärmliche Umsetzung, der neuere C-Standards (C99 und weitere der 
letzten 15 Jahre) komplett ignoriert.

Die IT-Welt dreht sich nicht um Windows.

Peter II schrieb:
> darum ging es überhaupt nicht.

Das Ziel ist mir bekannt. Nur die Beschreibung des Weges dahin hängt 
sich an so etwas auf wie Includes, die unter Windows fehlen.

Peter II schrieb:
> C wird von MS nicht weiter entwickelt, warum auch.

Der Quellcode des Betriebssystems Windows besteht also zu 100% aus C++?

Oder wie schätzt Du das Verhältnis C : C++?

Ich nehme an, dass der C-Anteil erheblich größer ist als der C++-Anteil. 
Daher kann ich Deiner rhetorischen Frage "warum auch" nur einen 
ironischen Aspekt abgewinnen.

Peter II schrieb:
> Das Windows sich übersetzten lässt, sind alle Dinge vorhanden die
> gebraucht werden.

Bis irgendein Marketing-Manager von MS bestimmt, ihren eigenen 
C-Compiler in den Orkus zu werfen ("braucht eh keiner"). ;-)

Frank M. schrieb:
> Du kannst nicht einfach argumentieren, dass alles, was unter Windows
> nicht verfügbar ist, auch nicht zum Standard gehört. POSIX ist ein
> Standard.

Aber ein anderer als der C Standard. Man kann sich natürlich immer auf 
den Standpunkt stellen, dass wenn ein Feature von [lieblings OS hier] 
nicht auf [anderes OS hier] läuft, es nur ein Fehler/Nachlässigkeit des 
anderen OS sein kann. Es gibt nunmal verschiedene Betriebsysteme und 
Unterschiede zwischen diesen. Es wäre auch ganz nett wenn MS sich mehr 
um den POSIX Standard kümmern würde, tun sie aber gerade nicht.

Wenn man Software programmiert und einem die Kompatibilität mit mehreren 
Betriebsystemen wichtig ist, dann muss man eben mit der Schnittmenge der 
Features auskommen. Wenn einem Windows egal ist, packt man eben alles 
mit POSIX Zeug voll. Anders herum kann man auch alles mit der WinAPI 
vollpacken.

Sebastian V. schrieb:
> Wenn man Software programmiert und einem die Kompatibilität mit mehreren
> Betriebsystemen wichtig ist, dann muss man eben mit der Schnittmenge der
> Features auskommen.

Gerade das tut AVRDUDE recht vorbildlich.  Ich hätte da auch noch
AVaRICE als Gegenbeispiel.  Das ist zwar in C++, mittlerweile sogar
ein wenig OO (und nicht nur als alternativer C-Dialekt), aber es ist
durch und durch mit Posix-Features durchsetzt, sodass man es auf Win32
nur benutzen kann, wenn man Cygwin nimmt.

Die paar müden Header in AVRDUDE, die man vermutlich relativ flink
aufräumen könnte, wenn wirklich jemanden die MSVC-Kompatibilität
interessieren würde, sind Peanuts im Vergleich.  Nur, siehe oben,
warum sollte ich da irgendeine Anstrengung unternehmen, das Zeug
ready to go für einen obsoleten Compiler zu trimmen?  Den
Win32-Build bekommt man allemal über MinGW auf die Reihe, jemanden,
der es (wie seinerzeit Eric Weddington) als Windows-Nutzer für
Windows-Nutzer bauen würde, findet man sowieso nicht (die machen alle
nur die Hände auf, leider), dann nagle ich den Kram eben auch weiterhin
unter FreeBSD als Cross-Compilat zusammen.  MSVC kann mir dann einfach
gestohlen bleiben.

Nein, ein Umschreiben von C-Code mit dem einzigen Zweck, dass ihn dann
auch ein C++-Compiler ohne zu meckern nimmt, halte ich für komplett
verschwendete Liebesmüh.  Wenn schon C++, dann auch ordentlich, dann
könnte man wenigstens auch mit ein paar anderen Altlasten im Code
aufräumen.  Nur steht dann der Aufwand halt in keinem Verhältnis zum
Nutzen.

Jörg W. schrieb:
> Nein, ein Umschreiben von C-Code mit dem einzigen Zweck, dass ihn dann
> auch ein C++-Compiler ohne zu meckern nimmt, halte ich für komplett
> verschwendete Liebesmüh.

Von den Headern abgesehen, gab es doch nur eine einzigen Stelle, wo 
einmal ein Variable Length Array zum Einsatz kam. Also verglichen mit 
dem Aufräumen der Header noch deutlich weniger Arbeit.

Sebastian V. schrieb:
> gab es doch nur eine einzigen Stelle, wo einmal ein Variable Length
> Array zum Einsatz kam

Und, was soll damit passieren?  Soll ich das jetzt wieder rauswerfen,
nur weil ein Compiler, den sowieso keiner (mehr) benutzt, damit nicht
klar kommt?

Nee, meine Richtung ist da eine andere: wann immer es sinnvoll ist,
werden die C99-Features einfach benutzt.  Variablendeklarationen
nicht nur am Anfang des Blocks sind nun auch schon überall mit dabei
(OK, wird für MSVC kein Thema sein, weil C++ das schon immer brauchte),
und wenn ich named initializer brauche, würde ich sie ebenfalls
nehmen wollen.

Bitte verwechsle das jedoch nicht mit systemunabhängiger Programmierung:
das Teil soll es natürlich schon auch weiterhin (native) für Windows
geben, da lege ich Wert drauf.  Wenn ich mal Laune dafür habe, kann
ich mir auch die paar nicht-C-Standard-Header mal ansehen, inwiefern
sie überhaupt sinnvoll sind.  Kann gut sein, dass die jenseits der
tatsächlich plattformabhängigen Teile (ser_posix.c) völlig unnötig sind.

Naja, C99-Standardbibliothek ist noch was anderes als die komplette
Unterstützung der C99-Syntaxerweiterungen (gegenüber C89).

Nun sei nicht so quengelig; C99 ist ja erst (2015-1999) Jahre her.

Hans schrieb:
> Wenn Du es rauswerfen würdest, ließe sich der Code nicht nur mit Visual
> Studio, sondern auch mit jedem anderen C++-Compiler übersetzen.

Wem genau würde das in irgendeiner Weise helfen?

C++-Code wird es davon trotzdem nicht, jedenfalls kein sinnvoller.

> Außerdem
> natürlich nach wie vor mit allen C99-Compilern.

Das lässt er sich auch jetzt schon …