Re: Nette Features in C# 3.0

* Stefan Reuther wrote:
> Lutz Donnerhacke wrote:
>> Du mußt also - um ein C-Compiler zu portieren - den Code (für Includes und
>> Libraries) anpassen und nicht nur das Backend.
>
> Richtig. Den Code, *den der Compiler benutzt, um meine Binaries für das
> Ziel zu erstellen*. Nicht den Compiler-Code selbst.

IBTD. Aber egal.

>> Frontend: Quellcode -> Zwischencode
>> Optimierer: Zwischencode -> Zwischencode
>> Backend: Zwischencode -> Maschinencode
>>
>> Frontend und Optimierer haben keine Abhängigkeiten bzgl. der Zielmaschine.
>
> In real existierenden Compilern schon.

Dann soll man die Begriffe nicht verwenden.

> Einmal indirekt über die verwendete Bibliothek und z.B. deren <limits.h>.

Warum?

> Zum anderen über nach außen exportierte Eigenschaften der Maschine.
> int foo[sizeof(int)==4 ? 1 : -1];
> Hier sollte das Frontend die maschinenspezifische Größe von 'int'
> kennen. Schlimmer wird's mit structs, bitfields, etc.

Warum?

>> Was auch immer Du da tust, es ist kein Compiler.
>
> Was ist Turbo C 2.0, (c) 1988 Borland, dann?

Eine Mischform.

> Querverbindungen zwischen den einzelnen Schichten eines Compilers sind
> schon lange üblich.

Aber das nennt man dann nicht mehr X-End.

>> Kann ich das? Was weiß ich denn - sprachmäßig - von long?
>
> Die Minimalbereiche:
> long: -(2^31 - 1) .. +(2^31 - 1)
> unsigned long: 0 .. 2^32 - 1
> Und noch diverse Bonus-Infos, z.B. dass die positiven Werte in beiden
> Typen die gleiche Repräsentation im Speicher haben.

Das ist zuwenig. Leider. Ich weiß nicht einmal wie groß sizeof(long) minimal
ist. Oder doch. Ich habe einen Compiler, da ist es eins.

>> Wieviele Leute schreiben Code, indem sie an jede Rechenoperation ein
>> explizites Maskieren auf die gewünschte Bitbreite anhängen?
>
> Wenn die Korrektheit der Operation davon abhängt, tu ich das sogar.
> Meistens ist das aber nicht der Fall.

Es ist fast immer der Fall, da die Rechnungen je nach Ideal andere
Ergebnisse bringen. Integer Overflow kennst Du offenbar nicht.

>> Diese Aussage ist falsch. Es läßt sich kaum ein Programm so schreiben, daß
>> es von "jeder" C-Implementation übersetzt werden kann. C stellt dem viel
>> zuviele Hürden in den Weg. Selbst wenn man sich auf C99 beschränkt.
>
> C erlaubt es, Programme zu schreiben, die Transformationen zwischen
> Dateien durchführen. Ein Compiler ist nichts anderes.

Diese Programme sind fast nie portabel.

> Mein 40-KLOC-C-Projekt macht genau das. Es verrechnet Dateien, die
> Spieler eingesendet haben, mit einem Spieluniversum, und generiert
> daraus neue Dateien für die Spieler.

Und wie parst Du die Daten? Portabel?
Wie kommuniziert das Programm? Per Netzwerk?

>> Warum eigentlich? Mein Arbeitsplatzrechner ist um Größenordnungen
>> langsamer als die Windows-Entwickler-Büchse meines Nachbarn. Trotzdem
>> sind meine Compilezyklen deutlich kürzer.
>
> Vermutlich deswegen:
> c:\home> cpp32 "\Programme\bcc55\Include\windows.h"
> Borland C++ Win32 Preprocessor 5.5.1 Copyright (c) 1993, 2000 Borland
> \Programme\bcc55\Include\windows.h:
>
> c:\home> wc windows.i
> 337288 1432631 17892019 windows.i
>
> Natürlich ist das Technologie der Steinzeit :)

Nein. Ich verwende Steinzeittechnologie, denn derartige Dateigrößen kommen
mir nicht ins Haus. Und wenn das Parsen zu langsam ist, verbessere ich den
Parseralgorithmus und dumpe nicht den Core nach dem Erstparsen auf die Platte.

>> Völlig klar, jedoch ist C schon vorher unportabel, so daß man auf stdint.h
>> und ähnliche Krücken ausweichen muß. Ich habe z.B. das Problem, eine 64bit
>> Zahl auszugeben. Welchen Prefix nimmt man dafür in printf(3)?
>> "%ld", "%lld", "%I64d"? Es ist ja schließlich die Standardbibliothek. Und
>> die kann nicht mal die Dateigröße korrekt ermitteln.
>
> Wenn du den 64-Bit-Wert in einem long long speicherst, dann %lld. long
> long ist der einzige Typ, der garantiert 64 Bit aufnehmen kann.

"long long" gibt es nicht in der C-Norm. Next try.

> Wenn du als 64-Bit-Typ int64_t aus <stdint.h> bzw. <inttypes.h>
> verwendest, kannst du auch PRId64 aus letzterer verwenden.

Genau. Ich muß meinen Code von einem Preprozessor vorbereiten lassen, damit
er überhaupt noch kompiliert. Grandios!

> Klar, furchtbar umständlich. Deswegen nehme ich ja für neue Sachen nur
> 'std::cout << wert'.

Bloat kann ich mir auch in besseren Sprachen einkaufen. Da habe ich
wenigstens etwas davon.

>> Erkläre mir einfach mal, wie ich die Dateigröße eines Files ermittle.
>> Portabel - soweit möglich - geht das so:
>
> (lesen und mitzählen)
>
> Korrekt. In nacktem C gibt's sowas wie 'stat' nicht.

stat ist nicht portabel. stat für Windows liefert Dateigrößen von 32bit.
Next try.

>> *size += (uint64_t)len; /* will fail if 64bit types are composite */
>
> C kann nun mal keine Operatoren überladen. Entweder du hast C99 mit
> einem garantierten 64-bit-Typ, oder du hast eine C90-Implementation, die
> zufällig einen solchen Typen bietet, oder du hast verloren.

Ich danke viele Male für diese hoch portable und effiziente Krücke einer
Programmiersprache. *kotz*

>>>Man muss nicht 25000 Klassen portieren, um C auf eine andere Plattform zu
>>>bringen.
>>
>> In einer brauchbaren Sprache (wie z.B. Java) ist das nicht nötig, weil der
>> Code der Bibliotheken, einfach so übersetzbar ist.
>
> Um eine C-Bibliothek zu portieren, muss ich prinzipiell nur
> open/close/read/write und malloc implementieren, und dann noch so
> Kleckerkram wie signal.
>
> Für Java brauch ich zusätzlich noch den ganzen TCP/IP-Kram, GUI,
> Properties, Shared Libraries, einen GC, etc.

Java ist in der Grundsprache (ohne Libraries) sauber definiert. Es ist somit
semantisch korrekter Code wesentlich leichter schreibbar. Die meisten
Bibliotheken sind selbst in Java geschrieben und beziehen ihre Korrektheit
aus genau dieser Sprachnorm. In C ist das nicht möglich.

>>>In meinem Bastelprojekt (~70 kLOC in .cc-Dateien) finde ich genau 3
>>>#ifdefs, die Compilerfeatures testen: Vorhandensein von 'isfinite' und
>>>'putenv', sowie ein zusätzliches Debug-Gimmick (Backtrace-Generator) für
>>>x86/gcc/ELF-Plattformen. Dazu noch zwei Module, die die Unterschiede
>>>zwischen Windows- und Unix-Plattformen kapseln (Dateinamenarithmetik und
>>>so Zeug).
>>
>> Gratuliere. Ich habe schon mehr #ifdefs/Spezifika bei einem einfachen
>> Mapping von (übers Netzwerk kommenden) Strukturen auf Speicherbereiche.
>
> Sowas zerlege ich zu Fuß. Einzige Annahme ist CHAR_BIT=8. Das ist zwar
> langsamer, aber die paar nano-MIPS hab ich schon noch übrig.

Wenn ich zu Fuß zerlegen will, dann kann ich gleich
type (MonadPlus m) => Parser a s m
nehmen. Das ist deutlich einfacher.

C nehme ich, wenn der erzeugte Code kompakt und schnell sein muß, weil ich
fast immer die Kontrolle über das Compilat habe (weil der Quellcode zu
schwach abstrahiert). Wenn ich es portabel, kompakt und schnell haben will,
nehme ich Ada und in diesem konkreten Fall repesentation clauses.

>> Ich weiß zwar nicht, was Filenamenarithmetik ist, ...
>
> filename = dirname + basename
> dirname = dirname1 + dirname2
>
> Halt unter der Berücksichtigung lokaler Konventionen, dass z.B. unter
> Windows "c:\foo" ein absoluter Dateiname ist, unter Unix aber nicht.

Was ist an folgendem Code falsch?
char * concat_filepath(char const * dirname, char const * name) {
int len = strlen(dirname) + strlen(DIRSEP) + strlen(name);
char * result = (char *)malloc(len + 1);
strcat(strcat(strcpy(result,dirname),DIRSEP),name);
return result;
}

C kennt ja nunmal keine Strings.

>>>Zusätzlich treffe ich noch die Annahme CHAR_BIT=8; da ich Dateien
>>>verarbeite, die auf dem PC zuhause sind, ist das wohl angebracht.
>>
>> Diese Annahme gibt der Standard her, wenn auch nicht explizit.
>
> Der Standard garantiert IMHO nur CHAR_BIT >= 8.

Nein. Zwei Fußnoten und ein Absatz im Rahmen zu sizeof lassen sich logisch
zu CHAR_BIT = 8 auswerten. Es ist nur typisch, daß das nicht mal den Autoren
auffällt.
.

Relevant Pages

  • Re: [VB?] & Java ...
    ... Der Autor Manuel Siekmann bzw. dessen Firma www.makasy.com ... Compiler verhält sich bei VB6-Source-Input nahezu kompatibel. ... Implementierungen relativ elegant möglich (ohne viel Code ... Soviel erstmal zur prinzipiellen Arbeitsweise der neuen ...
    (microsoft.public.de.vb)
  • Re: Grundsatzfrage zum Klassen-Design
    ... Dass, wenn sich Tabellen ändern, sowohl Du als auch ich in den Code ... Sicherlich haben Interfaces ihren Zweck. ... den Compiler zum Generieren von Fehlermeldungen zu bewegen. ... weil mich SPs nun endgültig auf eine DBE festnageln. ...
    (microsoft.public.de.german.entwickler.dotnet.csharp)
  • Re: Migration auf .NET - Winform or WPF or Silverlight or ?
    ... Wenn man vor der Konvertierung den Visual Basic 6.0 Code Advisor laufen lässt, dann merkt man erst einmal, wie "unsauber" programmiert wurde. ... Neuentwurf sinnvoller ist, insbesondere dann, wenn ein grober Bruch (z.B. Benutzerschnittstelle mittels WPF, LINQ im Hintergrund etc.) mit alten Technologien erfolgen soll. ... Dass den Compiler keine Struktur interessiert, wenn die Syntax richtig angewandt wurde, ist die Grundlage dafür, dass der Compiler überhaupt funktioniert. ... VB6-Weg nicht als unsauber bezeichnen. ...
    (microsoft.public.de.vb)
  • Re: Bankswitching!
    ... Das macht alles der Compiler. ... und dann kann man zwecks Optimierung normalerweise seinen Code ... > globale Variablen und je eine Bank pro Modul für lokale. ... | Banking optimization removes MOVLB instruction in instances where it ...
    (de.comp.lang.misc)
  • Re: [Lisp] Gruende fuer Garbage Collection
    ... weil einen der Compiler dann ohnehin ... Dann kann man in jeder Sprache Code schreiben, ... 'Praktisch' hat dieser Prozessor ... Next by Date: ...
    (de.comp.lang.misc)