Forum: Compiler & IDEs Variablen mit 0 initialisieren


von Stefan F. (Gast)


Lesenswert?

Ich habe irgendwo gelesen, dass man globale Variablen mit mit 0 
initilaisieren soll, weil dies bereits der Vorgabe entspricht und 
Programmspeicher vergeudet.
1
int counter=0;
2
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.

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.

Andererseits möchte ich aber auch korrekt programmieren, daher die 
folgende Frage:

Ist es falsch, globale Variablen mit 0 zu initialisieren? Wenn ja, 
warum?

von Falk B. (falk)


Lesenswert?

@ 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ö.

von zeitler (Gast)


Lesenswert?

Bei C sorgt das Startup-Programm dafür, daß globale Variablen zu Beginn 
mit 0 initialisiert werden. Aber nicht lokale!

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

zeitler schrieb:
> Aber nicht lokale!

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

Ist also eher eine Frage der Speicherklasse denn des
Sichtbarkeitsbereichs.

von Stefan F. (Gast)


Lesenswert?

> Bei welcher Programmiersprache wäre es denn nicht definiert?

Definiert ist es sicher bei allen Programmiersprachen. Aber ich möchte 
sichergehen, dass ich die Unterschiede der Sprachen nicht durcheinander 
werfe. Bzw diese Situation von vorne herein vermeiden.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Markus (Gast)


Lesenswert?

Jörg W. schrieb:
> 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.

Ist bei mir schon eine Weile her, aber die Initialisierung globaler 
Variablen erzeugt m.W.n. keinen ausführbaren Code, bzw. wäre nicht 
notwendig. Die Werte werden in einem Bereich in der Programmdatei 
abgelegt, der nach dem Laden des Programms/beim Programmstart vom Loader 
oder der Crt an die entsprechende Stelle des Hauptspeichers (init dseg 
o.ä.) kopiert wird.

von asdfasd (Gast)


Lesenswert?

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

Nein.  Aber nicht alle ;-)

Wenn das Programm bestimmte Inhalte von Variablen vorraussetzt (egal ob 
lokale oder globale), werden die Variablen entsprechend initialisiert. 
Ob diese Werte nun 42, &foo, oder eben 0 oder NULL sind, ist 
nebensächlich.

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

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.

Die Entscheidung, welche Variablen nun im BSS-, DATA- oder CODE-Segment 
landen, überlasse ich dem Compiler - aktuelle bekommen es optimal hin 
und bei denen, die das nicht optimieren, so what?  In 99.99% der Fälle 
ist es eh vollkommen schnuppe.

von Rolf M. (rmagnus)


Lesenswert?

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.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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 …

von BirgerT (Gast)


Lesenswert?

Auch wenn nicht per Anweisung initialisierte Variablen auf "0" gesetzt 
werden - ich initialisiere die Variablen mit einem Wert, einfach auch um 
die Warnmeldung "Variable XXX may be used uninitialised" zu umgehen.

von Peter II (Gast)


Lesenswert?

BirgerT schrieb:
> Auch wenn nicht per Anweisung initialisierte Variablen auf "0" gesetzt
> werden - ich initialisiere die Variablen mit einem Wert, einfach auch um
> die Warnmeldung "Variable XXX may be used uninitialised" zu umgehen.

welche Warung? bei mir kommt bei globalen Variablen keine.

von BirgerT (Gast)


Lesenswert?

Peter II schrieb:
> welche Warung? bei mir kommt bei globalen Variablen keine.

Einstellungssache?

uint8_t state;
:
if(state != 0) {;}
:

Gut, ich verwende auch AVR Studio 6..

von Peter II (Gast)


Lesenswert?

BirgerT schrieb:
> Einstellungssache?

oder nicht getestet?


Ich habe vorher mit dem gcc getestet.
1
#include <stdio.h>
2
3
int i;
4
5
int main(void) {
6
  int b;
7
8
  printf("%d %d", i, b );
9
10
  return 0;
11
}
gcc test.c -Wall

test.c: In function 'main':
test.c:8:3: warning: 'b' is used uninitialized in this function 
[-Wuninitialized]
   printf("%d %d", i, b );

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch Moderator
von ffff (Gast)


Lesenswert?

Rolf M. schrieb:
> 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.


Reinkommen muss die 0 ja sowieso. Ob das der Compiler jetzt default 
macht(oder der Controller) oder ich explizit ist völlig egal. Grad beim 
Initalisieren von Controllern(egal ob Echtzeit oder PC) ist es eben eher 
nicht so wichtig, wie gut das mein Startup-Code ist.

Schöner ist es auf jeden Fall, das explizit anzugeben. Ich weiß auch 
nicht, ob der C-Standard(ANSI-C -> C90) das so vorgibt. Wenn ich mich 
aber jetzt in die alltägliche Situation begebe, wo ich fremden Code 
anschaue, dann ist es mit Sicherheit schöner eine explizite 
Wertzuweisung zu haben, anstatt implizit davon auszugehen, das das schon 
passt!

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von BirgerT (Gast)


Lesenswert?

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) {;}

Arbeite lieber mit while(){} und do{}while().

Aber ich habe übersehen, dass dieser Thread nicht unter "µC & 
Elektronik" steht..

von Walter S. (avatar)


Lesenswert?

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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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

Bei JavaScript sieht das schon ganz anders aus. Und bei Python erst 
Recht. Leider.

von W.S. (Gast)


Lesenswert?

Stefan U. schrieb:
> Ich habe irgendwo gelesen, dass man globale Variablen mit mit 0
> initilaisieren soll, weil dies bereits der Vorgabe entspricht und
> Programmspeicher vergeudet.

Da hast du aber komisches Zeug gelesen.

Also, mal ganz im Ernst:
Variablen sollte man bittesehr vor ihrer ersten lesenden Benutzung mit 
einem vernünftigen Wert versehen, da sie ja sonst irgend einen 
zufälligen Wert haben können. Das ist eigentlich alles.

C-Leute haben es sich leider angewöhnt, zu erwarten, daß der für die 
Variablen benutzte RAM von irgend jemandem zuvor geputzt und genullt 
worden ist. OK, wer sich drauf verläßt, ist gelegentlich angeschmiert.

Aber selber im Programm alles pauschal nullen? Finde ich albern. Besser 
ist es eben, beim Programm schreiben die Variablen vor ihrer Verwendung 
nicht unbeschrieben zu lassen.

W.S.

von Peter II (Gast)


Lesenswert?

W.S. schrieb:
> C-Leute haben es sich leider angewöhnt, zu erwarten, daß der für die
> Variablen benutzte RAM von irgend jemandem zuvor geputzt und genullt
> worden ist. OK, wer sich drauf verläßt, ist gelegentlich angeschmiert.

C legt fest das es so ist - das ist kein Zufall was das passiert.

Ich schreibe auch nicht
1
if ( a == true )

sondern
1
if ( a )

weil ich faul bin, und die Sprache festlegt das beides richtig ist. ( a 
is bool)

von ffff (Gast)


Lesenswert?

Peter II schrieb:
> W.S. schrieb:
>> C-Leute haben es sich leider angewöhnt, zu erwarten, daß der für die
>> Variablen benutzte RAM von irgend jemandem zuvor geputzt und genullt
>> worden ist. OK, wer sich drauf verläßt, ist gelegentlich angeschmiert.
>
> C legt fest das es so ist - das ist kein Zufall was das passiert.
>
> Ich schreibe auch nicht
> if ( a == true )
>
> sondern
> if ( a )
>
> weil ich faul bin, und die Sprache festlegt das beides richtig ist. ( a
> is bool)

Das ist ein scheiß Beispiel, weil es in C kein bool gibt... deine 
if-bedingung prüft nur ob der Ausdruck != 0 ist

von Peter II (Gast)


Lesenswert?

ffff schrieb:
> Das ist ein scheiß Beispiel, weil es in C kein bool gibt... deine
> if-bedingung prüft nur ob der Ausdruck != 0 ist

Option 4 (C99)
#include <stdbool.h>

von Rolf M. (rmagnus)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

Also wenn zum Standard gehört, dann wundert es mich schon, dass man dazu 
eine Header Datei einbinden muss - aus der lustigerweise auch noch 
hervor geht, dass true einem Integer mit dem Wert 1 und false einem 
Integer mit dem Wert 0 entspricht.

von Jürgen S. (starblue) Benutzerseite


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

Jetzt bin ich aber verunsichert, denn hier
http://www2.informatik.uni-halle.de/lehre/c/c625.html
heisst es, dass bool in C kein Standard Typ ist.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von ?!? (Gast)


Lesenswert?

Stefan U. schrieb:
> Jetzt bin ich aber verunsichert, denn hier
> http://www2.informatik.uni-halle.de/lehre/c/c625.html
> heisst es, dass bool in C kein Standard Typ ist.

Des Rätsels Lösung ist einfach.
Die Seite stammt von 1995. Und C99 wurde 1999 eingeführt.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.)

von Peter II (Gast)


Lesenswert?

Jörg W. schrieb:
> (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.)

sie halten halt nicht am alten C fest, sondern konzentrieren sich auf 
C++

Braucht jemand wirklich diese neuen C Features unter Windows?

von (prx) A. K. (prx)


Lesenswert?

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

War das nicht vielmehr C#?

von Stefan F. (Gast)


Lesenswert?

> Die Seite stammt von 1995. Und C99 wurde 1999 eingeführt.

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

Jetzt wird das Bild wieder rund, das kann ich nachvollziehen. Ich mag C 
trotz seiner seniorenhaften Eigenarten.

von Sebastian V. (sebi_s)


Lesenswert?

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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

: Bearbeitet durch User
von Peter II (Gast)


Lesenswert?

Jörg W. schrieb:
> Man könnte das eine tun, ohne das andere lassen zu müssen.

Das kann aber eine Firma für sich selber entscheiden. Scheinbar fragen 
die Kunden diese Funktion nicht nach, oder sind nicht bereit dafür mehr 
Geld zu zahlen.

IAR (und die anderen) erzeugt auch Programm abseits von x68, da ist die 
nachfrage nach C vermutlich größer und damit auch der Markt.

ganz abschalten können sie C nicht, vermutlich weil der Windows-Kernel 
selber noch genug C quellen hat.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Peter II (Gast)


Lesenswert?

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.

naja, Andere sind halt schon ein schritt weiter und würde keine ihre 
Programm mehr mit C schreiben.

Scheinbar bist du ein kleiner Teil der Entwickler die noch Anwendungen 
für PCs mit C schreiben.

von Sebastian V. (sebi_s)


Lesenswert?

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?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch Moderator
von Peter II (Gast)


Lesenswert?

Jörg W. schrieb:
> 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.

da in  C++ viele Dinge einfacher sind, wird auch der code einfacher. 
Keiner zwingt dich den ganzen code auf oop umzusetzen.

Aber eh ich mir die Finger breche und z.b. eine map in C neu zu 
implementieren ändere ich die Endung und setzen den neuen code in C++ 
um. Das spart mir dann sogar zeit.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Sebastian V. (sebi_s)


Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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?

: Bearbeitet durch Moderator
von npn (Gast)


Lesenswert?

Sebastian V. schrieb:
> 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.

Was für ein Unsinn! Lies mal hier:

Zitat aus https://www.mikrocontroller.net/articles/AVRDUDE:
1
Das Programm ist unter MS-Windows (Cygwin nicht erforderlich),
2
Linux, BSD, Solaris und Mac OS X lauffähig. Die Version für
3
MS-Windows ist im WinAVR-Paket enthalten. Der Quellcode
4
ist frei verfügbar (Lizenz beachten).

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Klaus W. (mfgkw)


Lesenswert?

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 :-)

von Sebastian V. (sebi_s)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch Moderator
von Peter II (Gast)


Lesenswert?

Frank M. schrieb:
> 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.

darum ging es überhaupt nicht.

Er will nur testen ob sich der AVRDUDE auf den C++ Compiler umsetzen 
lässt und man dafür keine 5Jahre Teilzeit braucht.

Dann kann man alle neue C++ Features nutzen und ist nicht mehr auf C 
begrenzt.

C wird von MS nicht weiter entwickelt, warum auch.
Wenn mehr möchte stellt auf dem c++ Compiler um (ich meine nicht das 
Projekt auf OOP1 ) und kann die neusten Features nutzen.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch Moderator
von Peter II (Gast)


Lesenswert?

Frank M. schrieb:
> Peter II schrieb:
>> C wird von MS nicht weiter entwickelt, warum auch.
>
> Der Quellcode des Betriebssystems Windows besteht also zu 100% aus C++?

wer sagt das? Aber quellcode mutiert nicht über Nacht, so das er am 
nächste tag neue Features braucht.

Jetzt könnte man ja auch einfach sagen:
Das Windows sich übersetzten lässt, sind alle Dinge vorhanden die 
gebraucht werden.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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"). ;-)

: Bearbeitet durch Moderator
von Sebastian V. (sebi_s)


Lesenswert?

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.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Sebastian V. (sebi_s)


Lesenswert?

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.

von Bill (Gast)


Lesenswert?

Stefan U. schrieb:
> Da ich mit vielen unterschiedlichen Programmiersprachen arbeiten muss,

Merkwürdig, alle anderen, die ich kenne, die ebensfalls mehrere 
Programmiersprachen nutzen, die verstehen zumindest die Grundlagen des 
Programmierens.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Peter II (Gast)


Lesenswert?

Scheinbar haben sie es in VS2015 umgesetzt

[...]
die C++-Entwickler von Visual Studio 2015 RTM (Release to Manifacturing) 
erwarten können. Demnach ist unter anderem die Umsetzung der 
C99-Standardbibliothek mit Ausnahme von dem für C++ uninteressanten 
tgmath.h und den Pragma-Makros CX_LIMITED_RANGE/FP_CONTRACT nun 
abgeschlossen.
[...]

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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

von Klaus W. (mfgkw)


Lesenswert?

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

von Hans (Gast)


Lesenswert?

Jörg W. schrieb:
> 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?

Es geht doch nicht um den Visual Studio C-Compiler, sondern den 
C++-Compiler. Den benutzen einige Leute ...

Wenn Du es rauswerfen würdest, ließe sich der Code nicht nur mit Visual 
Studio, sondern auch mit jedem anderen C++-Compiler übersetzen. Außerdem 
natürlich nach wie vor mit allen C99-Compilern.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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 …

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.