C Compiler unter Win

Hallo Maik,

super. Vielen Dank!!

Werd mir alle Vorschläge mal anschauen.

Jens.

Hab in nächster Zeit nur diesen Rechner.

Schau dir auch mal CodeLite an.
http://codelite.org/
http://codelite.org/Main/ReadMore

Jens schrieb:
> Hab in nächster Zeit nur diesen Rechner.

Schon mal was von virtuellen Maschinen gehört? z.B. den VMWare Player, 
der geht sehr gut unter Windows und ist kostenlos.

Rolf Magnus schrieb:
> Ob
>
> Jens schrieb:
>> ein älterer, eher langsamer XP Laptop
> dafür geeignet ist, ist allerdings fraglich.

Kein Problem. Nur mind. 2 GB Speicher sollte man haben und das Linux 
sollte nicht gerade in der Maximalkonfiguration laufen.

Hallo,

bin vielleicht etwas spät dran, will aber unbedingt Pelles C 
(http://www.smorgasbordet.com/pellesc/) empfohlen haben.

Vorteile:

- unterstützt C99 und C11

- unterstützt Microsoft Erweiterungen (d.h. falls du Bibliotheken 
brauchst, kannst du .LIBs nutzen, also Bibliotheken die mit MSVC++ statt 
mit gcc kompiliert wurden)

- eingebauter Resourceneditor

- gibts nativ in 32 oder 64 Bit (das letzte mal als ich einen 64 Bit gcc 
und 64 Bit Qt brauchte, sah es schlecht aus; ist allerdings auch schon 
etwas her)

Mit c# die grafischen Umsetzung programmieren und mit PInvoke auf eine 
c-Dll zugreifen. Dann ist man auch dieses gruselige Linux los.

Jens schrieb:
> - C Programm sollte später einfach auf ARM portierbar sein. Deshalb C
> und kein C++/C#
C++ und C# sind zwei völlig verschiedene Dinge, daher ist "C++/C#" 
ziemlicher Unsinn. C++ ist standardisiert, und wenn du 
standard-konformen Code schreibst ist dieser perfekt portabel. Mehr als 
Java oder C#, und mindestens so wie C. In C++ ist es allerdings 
komfortabler:
In C portabel einen 32bit-Integer ausgeben:

1

int32_t x = 42;

2

printf ("Die Zahl ist " PRId32 ".", x);

In C++:

1

int32_t x = 42;

2

std::cout << "Die zahl ist " << x << ".";

Wenn man nachträglich den Typ auf zB uint16_t ändert, muss man in C 
jegliche Ausgabe auf PRId16 ändern. In C++ muss man gar nichts ändern.

Dr. Sommer schrieb:
> Mehr als Java oder C#

Erzähl mal!

Gustav schrieb:
> Erzähl mal!
Java ist nur für 32bit-Plattformen konzipiert, denn dessen "int" 
Datentyp muss immer 32bit groß sein. Auf einer 36bit oder 25bit 
Plattform müssen diese erst kompliziert (und langsam) emuliert werden. 
In C++ ist dann ein "int" halt 25bit groß, portabler Code sollte sich 
nicht daran stören. Außerdem sind in Java Array-Indices immer "int", 
d.h. 32bit - daher kann Java nur 4GB-Arrays anlegen, auch wenn die 
Plattform mehr könnte (wie zB x86_64). In C++ kein Problem, denn dort 
verwendet man size_t für Array-Größen & Indices, was je nach Plattform 
zB 32 oder 64bit groß ist.

C++ Code passt sich also der Plattform an um dort direkt effizient zu 
laufen, während Java Anforderungen stellt die bei weitem nicht immer 
effizient erfüllbar sind, weswegen es auch gar keine JVM's auf solchen 
Plattformen gibt.

Dr. Sommer schrieb:
> Auf einer 36bit oder 25bit Plattform

Viel Spaß noch mit deiner PDP10 oder Honeywell 6000!

Gustav schrieb:
> Viel Spaß noch mit deiner PDP10 oder Honeywell 6000!
Oder diverse moderne DSP's. Bei denen gibt's zB gar keinen 
8-Bit-Datentypen - sehr schlecht für Java und sein Zwangs-8bit-"char". 
C(++) hat kein Problem mit 36bit oder 32bit- "char"...

Java hat auch kein Problem damit, weil die JVM auch auf deinen 
exotischen Gedankenspiel-Rechnern korrekte Datentypen bereitstellen 
kann.

Gustav schrieb:
> Java hat auch kein Problem damit, weil die JVM auch auf deinen
> exotischen Gedankenspiel-Rechnern korrekte Datentypen bereitstellen
> kann.
1. sind die keineswegs Gedankenspiele und 2. geht das nur sehr 
suboptimal und ineffizient. Theoretisch lässt sich jede Sprache auf 
jeder Plattform nutzen solange sie turing-vollständig ist (weswegen die 
Portabilitäts-Diskussion theoretisch hinfällig ist); praktisch bereitet 
aber die aus Java's Inflexibilität resultierende Ineffizienz derartige 
Probleme dass das nicht sinnvoll machbar ist.

Und wie du vielleicht weißt ist x86_64 (AMD64) keine besonders exotische 
Architektur, und dennoch kann Java dessen kompletten Speicher nicht 
ausnutzen aufgrund der 32bit-Array-Größe & Indices.

Die Logik ist ganz einfach: Die Menge an Plattformen auf denen Java 
sinnvoll läuft ist eine echte Teilmenge der Plattformen auf denen C(++) 
sinnvoll läuft, ergo ist C(++) portabler als Java. Da kannst du auch 
nichts durch Herunterspielen von dir nicht passenden Plattformen dran 
ändern.

Boris P. schrieb:
> Dr. Sommer schrieb:
>> Java und sein Zwangs-8bit-"char".
>
> Ist doch gut, dann läuft der Code so wie man es erwartet (und ist nicht
> abhängig von der Platform).
Korrekter C(++) Code ist nicht abhängig von der Plattform, denn dieser 
erwartet nicht dass ein char 8bit groß ist, denn das ist in den C und 
C++ Standards nirgends garantiert!

Boris P. schrieb:
> Warum sollte man ein Array definieren wollen, dass den ganzen Speicher
> des Systems ausnutzt?
Weil niemand mehr als 640KB RAM braucht? Java ist einfach nicht 
aufwärts/Zukunfts-Kompatibel, wenn es quasi überall 32bit-Integer 
vorschreibt. Selbst im viel älteren C hat man begriffen, dass man für 
Array Größen & Indices einen flexiblen Datentyp braucht (size_t).
Im Java's altem Datei-API wurden 32bit-Integer sogar für Dateioffsets 
verwendet, d.h. man konnte nur maximal 2 GB große Dateien anlegen. Aber 
wer hat schon Festplatten in der Größe, gell. Zum Glück haben sie dafür 
jetzt ein neues API. Arrays sind aber Bestandteil der Sprache und daher 
nicht so leicht zu ändern. Wenn die üblichen RAM-Größen & Bedarf ähnlich 
weiterwachsen wie Festplatten, werden die 32bit auch irgendwann zu 
Problemen führen...

Boris P. schrieb:
> Java gibts doch auch als 64bit Version. Damit kommt man
> speichertechnisch recht weit ;-)
Aber da ist "int" immernoch 32bit groß. Das ist ein prinzipielles 
Problem der Sprache, das man nicht durch bessere JVM's lösen kann, 
sondern nur durch Re-Design der Sprache selbst.

Boris P. schrieb:
> Das ist auch gut so. Und es hat nichts damit zu tun, wie viel Speicher
> du mit einerJava Anwendung nutzen kannst.
Aber wie groß ein Array sein kann. Versuche mal ein Array mit mehr als 
2^31 Einträgen anzulegen.

Boris P. schrieb:
> Da wäre dann eine
> Baumstruktur o.Ä. angemessen.
Die könnte man da hineinspeichern (Heap-Struktur). Wäre effizienter als 
1000000x "new" aufzurufen und Referenzen zu verwenden.

Boris P. schrieb:
> So what? Einen praktischen Nutzen hat sowas nicht => Braucht kein Mensch
> :-)
Genau wie die 640 KB RAM - braucht auch keiner - noch nicht. Es ist 
wie gesagt ein prinzipielles Problem, was u.a. darin begründet ist dass 
Java keine Typ-Aliase hat. Aber all das ändert immer noch nicht die 
Tatsache, dass C(++) portabler als Java ist.

Ob euer Gefeilsche um ein wenig mehr Performance dem TE wirklich 
weiterhilft? Der wollte doch ausdrücklich C und KEIN C++ und wohl auch 
kein Java, obwohl er das bereits kennt?

Gibt es überhaupt eine Möglichkeit die QT Widgets zu verwenden bei 
REINEM C Code? Meiner Kenntnis nach nicht.

C C++ oder was schrieb:
> Der wollte doch ausdrücklich C und KEIN C++ und wohl auch
> kein Java, obwohl er das bereits kennt?
Der Punkt ist, dass er bezüglich der Begründung für "kein C++" scheinbar 
einem Mythos aufgesessen ist.

Dr. Sommer (Gast) schrieb:
> Der Punkt ist, dass er bezüglich der Begründung für "kein C++" scheinbar
> einem Mythos aufgesessen ist.

Weiß ich nicht. Ich denke viele wie der TE tun sich eher schwer mit der 
Syntax von C++ zurechtzukommen.

1

    class MyWidget : public QVBox

2

    {

3

    public:

4

        MyWidget( QWidget *parent=0, const char *name=0 );

5

    };

6

7

    MyWidget::MyWidget( QWidget *parent, const char *name )

8

            : QVBox( parent, name )

9

    {

Ist halt doch was anderes als C.

Rufus Τ. Firefly (rufus) (Moderator) schrieb:

C C++ oder was schrieb:
>> Gibt es überhaupt eine Möglichkeit die QT Widgets zu verwenden bei
>> REINEM C Code?

> Nö, es sei denn, man bastelt sich eine DLL, die den QT-Krempel kapselt
> und ein C-Aufrufinterface bietet.

Danke! Konnte auch bisher nichts brauchbares im Netz finden. Es wird dem 
Geneigten wenn es um QT geht einfach zu oft C++ als "C" untergeschoben.

> Aber das entfernt sich immer weiter von dem, was der Threadstarter wohl
> will.

> Der aber hat sich seit mehreren Tagen hier nicht mehr blicken lassen.

Tippe mal auf typische Reaktion "verschreckt". ;)

Ist doch eigentlich ein spannendes Thema.

Würde ich auch sagen:

> Code::Blocks mit MinGW und wxWidgets:
> http://www.codeblocks.org/

Rufus Τ. Firefly (rufus) (Moderator) schrieb:

> Nein, dem Thredstarter geht es nicht um die Syntax, sondern er nimmt an,
> daß es Probleme mit der Portierung von C++ - Code auf einen ARM geben
> wird.

> Hier wird ja noch oberflächlicher gelesen, als ich das an schlechten
> Tagen hinbekomme ...

Verstehe ich nicht. Ich habe es so verstanden, dass er auf dem PC die 
GUI zur Simulation benötigt. Was also hat dieser Teil des Codes mit dem 
Programmcode eines Mikrocontrollers ARM in Sachen "Portierung" zu tun? 
Das sind doch zwei Paar Schuhe.

ARM: C-Code
PC: C++ GUI  (will er nicht)

ARM: C-Code
PC: (auch nur Code in) C GUI (will er)

SO habe ich das verstanden.

>Code::Blocks mit MinGW und wxWidgets:
>http://www.codeblocks.org/
für das hab ich mich entschieden und ist genau das richtige.


ARM: Algrothmis zum Bewegen in C, Bewegung selbst: PID Regler in C, 
Endstufe, Motoren.

PC: Algorithmus zum Bewegen in C, Simulation und Darstellung der 
Bewegung in C/C++

Als ich so um '98 Simulationen mit grafischer Ausgabe unter Windows in C 
geschrieben habe, war das glaub ich direkt mit den Funktionen der gdi 
und user DLLs (damals noch 16 Bit Code). Zum Zusammenklicken der Dialoge 
hatte MSVC++ einen Ressourcen Editor. Die MFC habe ich definitiv nicht 
verwendet.

Heutzutage würde ich zu Mingw greifen und mir irgendwo anders einen 
grafischen Ressourcen Editor beschaffen, wenn Dialoge überhaupt benötigt 
werden.

Das ganze Theater mit sockets und DLLs ist nicht nötig - man kann 
Objectfiles von einem C Compiler mit Objectfiles von einem C++ Compiler 
zusammenlinken. Der C++ Compiler braucht noch ein extern "C" in der 
Schnittstellendeklaration.

Geht besser, als Objectfiles von 2 verschiedenen C++ Compilern :-)

Damit kann man dann die GUI in C++ machen, und das zu testende Programm 
in C.

Alternativ, auch die GUI in C:
- Irgendein C-Compiler - hat nichts mit der GUI zu tun
  (wenn die GUI-Bibliothek keine besonderen Anforderungen stellt).
- Eine GUI-Bibliothek aussuchen. Mir fallen z.B. ein:
  - IUP (sehr einfach, Plattformunabhängig)
  - Win32 (etwas komplizierter...)
  - gtk (Tut auch auf Windows, obwohl es von Unix kommt)

Rufus Τ. Firefly (rufus) (Moderator) schrieb:

C C++ oder was schrieb:
>> SO habe ich das verstanden.

> Aha:

>> Anforderungen wären:
>> - C Programm sollte später einfach auf ARM portierbar sein.
>>   Deshalb C und kein C++/C#

Nix "Aha". Er hat es ja jetzt nochmals präzisiert

ARM: C-Code
PC: C++ GUI in WxWidgets ; Algorithmen in C

Ob WxWidgets gegenüber Qt Vorteile hat wäre dann nochmals eine andere 
Frage. Aber das muss er selber wissen. Gibt außerdem auch noch andere 
GUI Toolkits.

Forderung

> - Einfache GUI bzw. "Canvas" zum zeichnen

Siehe Anhang!

>C

>python.gif