Wo findet man Programmierer?

[Markus Becker]

Moin,

Henning Paul wrote:

Im Gegentum: Bist Du im "Meldung löschen?"-Dialog, weil Du mit der linken
inneren Taste gerade alle Meldung durchgescrollt hast, ist diese Taste
"Nein", damit Du gefahrlos zur nächsten Nachricht kommst und nicht die
Taste wechseln mußt. Hast Du im Meldung-Optionsmenü mit der rechten Taste
explizit "Meldung löschen" ausgewählt, ist rechts "Nein".
Die Taste, die etwas "gefährliches" auslöst ist immer die, die zuletzt
_nicht_ benutzt wurde.

Man kann sich alles schönreden. Aber ich finde es krank, wenn mir das
'Ja' unter der Maus verschwinden würde und zu einem 'Nein' wird, nur
weil ich vorher etwas bestimmtes gemacht habe.

Siemens mag das anders sehen.

Markus

 

[Joerg Wunsch]

Vinzent 'Gadget' Hoefler <nntp-2005-02@t-domaingrabbing.de> schrieb:

Nö, wenn du eine passende Programmierumgebung hast, bei der der
Linker das ordentlich organisiert, kannst du auch mit normalen
Variablen arbeiten (zugehörige section wird auf entsprechende
Adressen beim Linken gemappt).

Toll. Und warum sollte ich mir das antun?

*Du* sollst nicht, das ist die Aufgabe desjenigen, der die
Programmierumgebung zusammenbaut.

Und darüber, wieviel Zeit man in die Programmierumgebung stecken darf,
reden wir wohl lieber nicht. ;-) Die für C läuft für Atmel AVR schon
seit Jahren, die für Ada steckt immer noch in den Kinderschuhen. Das
ist dann die Kehrseite der Medaille.

Wo hast du den Schwachsinn her?

|An integer may be converted to any pointer type. Except as
|previously specified, the result is implementation-defined, might
|not be correctly aligned, might not point to an entity of the
|referenced type, and might be a trap representation.

Was also so gut wie aequivalent zu "undefined" ist.

Wieso? Steht doch ausdrücklich dort, dass es implementation-defined
ist. Warum willst du da unbedingt ein undefined reininterpretieren?
Wenn natürlich deine Adresse nicht den aligment requirements des
Prozessors entspricht, knallt es, aber das ist eine Prozessorfrage.
Und *wohin* der Zeiger dann zeigt, das musst du natürlich schon selbst
wissen, aber das ist bei Ada nicht anders.

Ich fand diese Definition jedenfalls deutlich strikter, als ich vom
C-Standard erwartet hätte. Es wird dem Compiler eben nicht gestattet,
heute dies und morgen jenes aus einem derartigen Typecast zu
compilieren.

Das Ergebnis ist sehr wohl implementation-defined, und du weißt
natürlich genausogut wie alle anderen, wie die Implementierungen
das definieren.

Ja. Fuer jede Implementation einzeln. D.h. unter Umstaenden auch
abhaengig vom gerade gueltigen Speichermodell.

Und bei Ada? Bist du wieder bei demjenigen, der das in die
Programmierumgebung hineinzimmern musste und damit u. U. heute noch
immer nicht fertig geworden ist...

Versteh mich nicht falsch, ich habe nichts gegen Ada, aber es nun als
den Stein der Weisen hinstellen zu wollen, bringt's auch nicht. Viele
der Dinge, die du da aufgezählt hast, sind ohnehin eher marginal.

--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL

http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

 

[Vinzent 'Gadget' Hoefler]

MaWin wrote:

"Vinzent 'Gadget' Hoefler" <nntp-2005-02@t-domaingrabbing.de> schrieb
im Newsbeitrag news:1381700.8DliNq6zaD@jellix.jlfencey.com...

Hint: Es heisst Einleitungs_zeile_.

|Foo : SDRAM_Timing_Control;
|[...]
|Foo.Cas_Lat := 3;

Das gleiche in C:

Falsch.

SDRAM_Timing Control Foo;
Foo.Cas_Lat = 3;

Falsch, da komplett dysfunktional. Ich nehme an, Du meintest so etwas:

|typedef struct { /* Annahme: Reihenfolge sei low-order-first */
| unsigned int ras_cas_dly : 2;
| unsigned int ras_pchg_dly : 2;
| /* das muesste eigentlich ein eigenstaendiger enum */
| /* sein, aber ich bin faul, ignorieren wir das fuer */
| /* heute also mal */
| unsigned int cas_lat : 1;
| unsigned int dummy : 3;
|} sdram_timing_control_t;
|
[...]
| static volatile sdram_timing_control_t foo =
| { ras_cas_dly : 3,
| ras_pchg_dly : 0,
| cas_lat : 3,
| dummy : 0,
| };

Wirft einen Binaerwert von (erwartungsgemaess) 000.1.00.11 in die
Struktur. Richtig waere allerdings 000.1.00.01. Warum das so ist (und
der Rest eigentlich auch nur zufaellig stimmt), ueberlegst Du Dir bitte
selbst. (Dass der Compiler nicht einmal warnt, dass mindestens einer
der zugewiesenen Werte gar nicht in das Bit-Feld passen, ist da nur
noch eine der Nebensaechlichkeiten, an die man sich im Umgang mit C
gewoehnt).

So was passiert nur, wenn man v o n C k e i n e
b l a s s e s t e A h n u n g hat.

Nein, so was passiert, wenn jemand Namenloses faelschlich vermutet, den
Sinn irgendwelcher zitierten Deklarationen verstanden zu haben.


Vinzent.

--
worst case: The wrong assumption there actually is one.

 

[Vinzent 'Gadget' Hoefler]

Joerg Wunsch wrote:

Vinzent 'Gadget' Hoefler <nntp-2005-02@t-domaingrabbing.de> schrieb:

Nö, wenn du eine passende Programmierumgebung hast, bei der der
Linker das ordentlich organisiert, kannst du auch mit normalen
Variablen arbeiten (zugehörige section wird auf entsprechende
Adressen beim Linken gemappt).

Toll. Und warum sollte ich mir das antun?

*Du* sollst nicht, das ist die Aufgabe desjenigen, der die
Programmierumgebung zusammenbaut.

Ich muss die passenden Linkerdeklarationen trotzdem selbst schreiben.

Wo hast du den Schwachsinn her?

|An integer may be converted to any pointer type. Except as
|previously specified, the result is implementation-defined, might
|not be correctly aligned, might not point to an entity of the
|referenced type, and might be a trap representation.

Was also so gut wie aequivalent zu "undefined" ist.

Wieso? Steht doch ausdrücklich dort, dass es implementation-defined
ist. Warum willst du da unbedingt ein undefined reininterpretieren?

Weil mir das u.a. von den Koryphaeen in d.c.l.c erst vor kurzem so
beigebracht wurde. :->

Bist du wieder bei demjenigen, der das in die
Programmierumgebung hineinzimmern musste und damit u. U. heute noch
immer nicht fertig geworden ist...

Ich weiss nicht, aber funktionierende Compiler fuer die Zielplattformen,
die ich brauche, existieren. Wo sie nicht existieren, gibt es notfalls
Ada-nach-C-Konverter.

Versteh mich nicht falsch, ich habe nichts gegen Ada, aber es nun als
den Stein der Weisen hinstellen zu wollen, bringt's auch nicht.

Das habe ich nicht getan. Ich habe lediglich dargelegt, warum ich es
_gerade_ fuer hardwarenahe Programmierung fuer _besser_ geeignet halte
als C. Und ich spreche da auch nicht ganz ohne Erfahrung.

Viele
der Dinge, die du da aufgezählt hast, sind ohnehin eher marginal.

Ist das eine Aufforderung, noch ein bisschen mehr zu erzaehlen? ;-)


Vinzent.

--
worst case: The wrong assumption there actually is one.

 

[Vinzent 'Gadget' Hoefler]

Joerg Wunsch wrote:

Manfred kannst du kaum als ,,namenlos'' hinstellen, und jeder, der
hier auch nur mehr als drei Tage mitgelesen hat weiß, dass MaWin
einfach ein Symbol ist, sodass ihm praktisch jeder den Verstoß gegen
die Netiquette verzeiht.

<kindergarten>Er hat mich zuerst beleidigt.</kindergarten>

Das heißt nicht, dass man mit dem fachlich
(oder gar politisch, nicht wahr, Oli? ;-) immer einverstanden sein
muss,

Ich zitiere:

|Falsch.

Das ist eine nachweislich falsche Aussage, offensichtlich induziert
durch das fehlende Verstaendnis des Problems an sich.

|SDRAM_Timing Control Foo;
|Foo.Cas_Lat = 3;

Nette Idee, aber beim Lesen des Threads haette ihm klar werden sollen,
dass genau das *nicht* funktioniert. Gut, das kann man mit
Newslaufzeiten entschuldigen.

(Und im uebrigen sind auch laut aktuellem C-Standard Bit-Felder nicht
gerade das gelbe vom Ei, die entsprechenden Passagen strotzen nur so
von "implementation-defined" und "unspecified".)

|So was passiert nur, wenn man   v o n   C   k e i n e
|b l a s s e s t e    A h n u n g  hat.

Ich gebe zu, ich habe mit C von ein paar kleineren Treibern und dem
Debuggen des - ach so wunderschoen kurzen, aber leider eklatant
falschen - Codes von Kollegen keine wesentliche Erfahrung, aber "keine
blasseste Ahnung" ist nachweislich falsch.

|Die restlichen 16 KILOBYTE dummes ADA-Programm wollen wir mal nicht

Von Ada hat er offensichtlich noch weniger Ahnung, sonst wuesste er,
dass es Ada heisst, dass das zitierte Teil mitnichten ein Programm war
und dass Source-Code per se nicht dumm sein kann, was ich als Autor
desselben nun als persoenliche Beleidigung haette auffassen koennen,
aber bitte schoen: Meine Ex-Frau hat mir schon schlimmeres an den Kopf
geworfen. Also, was soll's?

|kommentieren, so viel Gelaber ist eher fuer Frauen am Gartenzaun.

Dass dieses Gelaber /mich/ davor schuetzt, Fehler zu machen, die ich bei
ihrem Auftreten am praktischen System prinzipiell hoechstens mit dem
Oszilloskop debuggen koennte, uebersieht der Herr dabei geflissentlich.

Man nennt das Typsystem. Nicht alles, was 8 Bit gross ist, will man
einem anderen Ding, was zufaellig auch 8 Bit gross ist, zuweisen
(koennen).

was MaWin schreibt, aber zu den synonymbenutzenden

<klugscheisser>Es heisst Pseudonym.</klugscheisser>

Dummschwätzern gehört er weiß Gott nicht.

Im speziellen Fall hat er meine persoenliche Grenze von mehr als 60%
Unsinn inklusive eines persoenlichen Angriff auf meine Intelligenz
deutlich ueberschritten. Und in so einem Fall lasse ich dann auch das
arrogante, selbstverliebte Arschloch raushaengen, das ich nun mal bin.

Love it or leave it.


Vinzent.

--
worst case: The wrong assumption there actually is one.

 

[Vinzent 'Gadget' Hoefler]

Joerg Wunsch wrote:

Vinzent 'Gadget' Hoefler <nntp-2005-02@t-domaingrabbing.de> schrieb:

*Du* sollst nicht, das ist die Aufgabe desjenigen, der die
Programmierumgebung zusammenbaut.

Ich muss die passenden Linkerdeklarationen trotzdem selbst
schreiben.

Nicht, wenn das Programmiersystem ordentlich gemacht worden ist.

Mal kurz zur Klaerung: Es wird von mir gemacht. Ich entscheide, welche
Hardware mit welcher Adresse angesprochen wird, nicht irgendein
Development-Kit irgendeines Mikroprozessor-Herstellers.

In diesem speziellen Fall sind also ich und der "Hersteller" des
Programmiersystems gewissermassen identisch.

Wieso? Steht doch ausdrücklich dort, dass es
implementation-defined ist. Warum willst du da unbedingt ein
undefined reininterpretieren?

Weil mir das u.a. von den Koryphaeen in d.c.l.c erst vor kurzem so
beigebracht wurde. :-

Nu, ich habe mich kürzlich in die andere Richtung korrigieren lassen
müssen und war selbst erstaunt, wie weit der Standard eigentlich die
gängige Praxis unterstützt.

Tja, so kann man sich taeuschen. Lesen bildet (wie ich erst gestern
wieder schmerzvoll feststellen durfte).

Ich weiss nicht, aber funktionierende Compiler fuer die
Zielplattformen, die ich brauche, existieren.

Dann hast du zu wenige Zielplattformen. ;-)

Ich glaube nicht. Eher zu wenig Zeit, alle auszuprobieren.

(Und sorry, aber jemand, der ernsthaft Bit-Felder in C verwendet, kann
auch nicht allzuviele verschiedene Zielplattformen haben oder er hat
Spass daran, sich die Deklarationen per #ifdef zurechtzubiegen.)

Das habe ich nicht getan. Ich habe lediglich dargelegt, warum ich es
_gerade_ fuer hardwarenahe Programmierung fuer _besser_ geeignet
halte als C.

Da würde ich einigermaßen mitgehen, mit der Prämisse halt, dass es oft
sehr viel länger dauert, bis es für eine Zielplattform eine
Ada-Umgebung gibt, während C praktisch immer da ist.

Wie gesagt, es gibt Ada-nach-C-Konverter. Und da Ada eine sehr strikt
standardisierte Sprache ist, ist die Erfolgschance der Lauffaehigkeit
des Produktes einer solchen Konvertierung ungleich hoeher als
andersrum. ;->


Vinzent.

--
worst case: The wrong assumption there actually is one.

 

[Joerg Wunsch]

Vinzent 'Gadget' Hoefler <nntp-2005-02@t-domaingrabbing.de> schrieb:

*Du* sollst nicht, das ist die Aufgabe desjenigen, der die
Programmierumgebung zusammenbaut.

Ich muss die passenden Linkerdeklarationen trotzdem selbst
schreiben.

Nicht, wenn das Programmiersystem ordentlich gemacht worden ist.

Wieso? Steht doch ausdrücklich dort, dass es
implementation-defined ist. Warum willst du da unbedingt ein
undefined reininterpretieren?

Weil mir das u.a. von den Koryphaeen in d.c.l.c erst vor kurzem so
beigebracht wurde. :-

Nu, ich habe mich kürzlich in die andere Richtung korrigieren lassen
müssen und war selbst erstaunt, wie weit der Standard eigentlich die
gängige Praxis unterstützt.

Ich weiss nicht, aber funktionierende Compiler fuer die
Zielplattformen, die ich brauche, existieren.

Dann hast du zu wenige Zielplattformen. ;-)

Das habe ich nicht getan. Ich habe lediglich dargelegt, warum ich es
_gerade_ fuer hardwarenahe Programmierung fuer _besser_ geeignet
halte als C.

Da würde ich einigermaßen mitgehen, mit der Prämisse halt, dass es oft
sehr viel länger dauert, bis es für eine Zielplattform eine
Ada-Umgebung gibt, während C praktisch immer da ist.

--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL

http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

 

[Joerg Wunsch]

Vinzent 'Gadget' Hoefler <nntp-2005-02@t-domaingrabbing.de> schrieb:

Nein, so was passiert, wenn jemand Namenloses ...

Hör bitte mit *diesem* Niveau auf, sonst landest du sicher nicht nur
in meinem Killfile.

Manfred kannst du kaum als ,,namenlos'' hinstellen, und jeder, der
hier auch nur mehr als drei Tage mitgelesen hat weiß, dass MaWin
einfach ein Symbol ist, sodass ihm praktisch jeder den Verstoß gegen
die Netiquette verzeiht. Das heißt nicht, dass man mit dem fachlich
(oder gar politisch, nicht wahr, Oli? ;-) immer einverstanden sein
muss, was MaWin schreibt, aber zu den synonymbenutzenden
Dummschwätzern gehört er weiß Gott nicht.

--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL

http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

 

[Martin Lenz]

Am Mon, 07 Feb 2005 18:52:15 +0100 hat Guido Grohmann
<guido.grohmann@gmx.de> geschrieben:

Oliver Bartels schrieb:

Jetzt lach bitte nicht, aber viele Rennfahrer bremsen mit dem
*linken* Fuß und bei den Rennmoppeds läuft aus gutem Grund
(Hochschalten in der Kurve) die Schaltung auch umgekehrt wie bei
Strassenmaschinen.
Und stell' Dir vor: Ich kann von einer Minute auf die andere von
meinem Mopped (Gas drehen mit rechter Hand, bremsen vorne
mit rechter Hand, Schalten mit linkem Fuß usw.) auf mein Auto
(Gas mit rechtem Fuß, Schalten mit Tipptronic) oder ein anderes
mit Schaltgetriebe (Kupplung mit linkem Fuß, schalten mit der
rechten Hand, also da, wo beim Mopped das Gas ist ... )
umsteigen, ohne dass dies zu Problemen führt.
Und ganz viele andere Menschen können das auch ...

Und es passiert überhaupt nicht, daß Erstbenutzer eines Wagens
Automatikgetriebes denselben mal eben gegen ein anderes Auto setzen,
oder anderen Flurschaden verursachen.

So schlimm ist es meistens nicht, aber eine Vollbremsung statt Kupplung
ist fast immer drin Obwohl Freunde, die mal mit meinem Auto fahren eh
immer vorwarne, nicht zu kuppeln.

--
Martin

 

[Jan Bruns]

"Vinzent 'Gadget' Hoefler":

Joerg Wunsch wrote:

Das habe ich nicht getan. Ich habe lediglich dargelegt, warum ich es
_gerade_ fuer hardwarenahe Programmierung fuer _besser_ geeignet
halte als C.

Da würde ich einigermaßen mitgehen, mit der Prämisse halt, dass es oft
sehr viel länger dauert, bis es für eine Zielplattform eine
Ada-Umgebung gibt, während C praktisch immer da ist.

Wie gesagt, es gibt Ada-nach-C-Konverter. Und da Ada eine sehr strikt
standardisierte Sprache ist, ist die Erfolgschance der Lauffaehigkeit
des Produktes einer solchen Konvertierung ungleich hoeher als
andersrum. ;-

Jedenfalls hast Du einige sinnvolle Meditationen geliefert,
die das Nachvollziehen der Falschheit der Aussage

| Hardwarenahe Programmierung heist Kernel-Treiber schreiben und das
| macht man nur in C/C++.

ermöglichen. Diese Aussage war wohl ursprünglich auf HW-nahe
Programmierung für x86-PCs gemünzt. Allerdings unterstützen
nichtmal dort alle C-Compiler so gängige CPU-Funktionalitäten
wie bspw. MMX (schon gar nicht vollautomatisiert).

Na ja, wer Treiber für Linux oder Win schreiben muss, der wird
wohl in der Tat zumindest ausschnittweise C benötigen, zumindest
um die OS-API bedienen zu können (in dem Bereich scheinen Tools,
die einem sowas ersparen, ja doch eher selten/teuer/unverfügbar
zu sein). Auch das hat nix mit HW-, sondern vielmehr mit OS-Nähe
zu tun.

Gemeint war wohl:
< Hardwarenahe Programmierung hat manchmal einen Bezug zu
< Kernel-Treibern. Linux/Win-Kernel-Treiber werden für oft in C
< formuliert.

Gruss

Jan Bruns

 

[MaWin]

"Vinzent 'Gadget' Hoefler" <nntp-2005-02@t-domaingrabbing.de> schrieb im
Newsbeitrag news:1482571.vs60KkzT2j@jellix.jlfencey.com...

Hint: Es heisst Einleitungs_zeile_.
[...] wenn jemand Namenloses

Wer inhaltlich verloren hat, versucht's halt so, kennen wir schon.

Du darfst beruhigt akzeptieren, das an einer Programmiersprache
wohl was oberfaul sein muss, wenn 4 Leute erst mal beim Lesen
auf Anhieb in die Fallen tapsen, die diese Programmiersprache
bietet. Dazu traegt auch bei, das niemand 16 KILOBYTE lesen will,
wenn es ca. 13 Deklarationszeilen auch getan haetten wie in 'C'.
--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

 

[MaWin]

"Andreas Schwarz" <usenet@andreas-s.net> schrieb im Newsbeitrag
news:4206679d$0$18566$9b4e6d93@newsread4.arcor-online.net...

Das lässt sich aber auf die Software nicht so einfach übertragen.

Aber sehr wohl.

Sonst hast du eine "Schere" die Word- und RTF-"Papiere" zerschneiden kann,
eine andere die PDF schneidet, und noch eine die HTML schneidet.

Papierschere, Blechschere, ZickZackSchere hat man auch in der Realitaet,
aus gutem Grund. Schon alleine, weil es beim Schreiben eines Buches abnervt,
wenn der Stift staendig unter der nie benoetigten Schere liegt.

Wieso also nicht, statt lange im Werkzeugkasten zu kramen, dem Papier
beibringen wie es sich selbst zerlegen kann?

Weil tausende Jahre Erfahrung der Menschheit zeigen, das das kein
tragfaehiges Konzept ist. Ich will nicht alle bereits beschriebene un
in einem Ordner abgehefteten Papiere aendern, bloss weil ich bei EINEM
neuen Papier einen Kreis schneiden will.

Natuerlich ist das geschilderete auch kein MVC, entgegen Axels Vermutung:
http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html
--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

 

[Holger Petersen]

"Jan Bruns" <post@abnuto.de> writes:

Na ja, wer Treiber fuer Linux oder Win schreiben muss, der wird
wohl in der Tat zumindest ausschnittweise C benoetigen, zumindest
um die OS-API bedienen zu koennen

So rein prinzipiell kann ich Dir da nicht zustimmen...

Die "C-Header" und sonstigen Sachen werden von einem C-Compiler
(auf Wuunsch) doch in 'normalen' Assembler umgewandelt, oder?

Und dann _könnte_ man auch gleich Makro's in Assembler schreiben.
Oder sich (einmalig) der Mühe unterziehen, das in Äquivalente der
benutzten Programmierspraceh umzuwandeln. Für 'perl' wurde sowas
in frühen Linux-Distributionen während der Installation von perl
durchgeführt.

(in dem Bereich scheinen Tools,
die einem sowas ersparen, ja doch eher selten teuer/unverfuegbar
zu sein).

Das mag an der potentiellen Nutzerzahl liegen; 'Angebot<->Nachfrage'
Es gibt auf jeden fall eine Möglichkeit, unter Linux in Assembler zu
arbeiten

Auch das hat nix mit HW-, sondern vielmehr mit OS-Naehe=
zu tun.

Nicht prinzipiell. Einen OS-Aufruf könnte man auch mit einer
Turing-Maschine machen, oder?

Gruss, Holger

 

[Jan Bruns]

"Holger Petersen":

"Jan Bruns":

Na ja, wer Treiber fuer Linux oder Win schreiben muss, der wird
wohl in der Tat zumindest ausschnittweise C benoetigen, zumindest
um die OS-API bedienen zu koennen

So rein prinzipiell kann ich Dir da nicht zustimmen...

Klar. Ist rein prinzipiell auch verkehrt.

Die "C-Header" und sonstigen Sachen werden von einem C-Compiler
(auf Wuunsch) doch in 'normalen' Assembler umgewandelt, oder?

Schön wär's ja. So ist es aber leider nicht.

#define HOCHWICHTIGESZEUGS konkretes Ding
#ifdef IRGENDWOAUSMAKEFILE
#define such_mich_special konkret1
#else
#define such_mich_special konkret2
#endif
#define unwichtig(p1) SUPERWICHTIGABERAUSUNBEKANNTERDATEI(p1)

compiliert zur leeren Menge, ergibt auch bereits nach dem
Macro-replacement ein leeres Ergebnis.

Und dann _könnte_ man auch gleich Makro's in Assembler schreiben.
Oder sich (einmalig) der Mühe unterziehen, das in Äquivalente der
benutzten Programmierspraceh umzuwandeln. Für 'perl' wurde sowas
in frühen Linux-Distributionen während der Installation von perl
durchgeführt.

Natürlich *könnte* man das, wenn
1.) die Header überhaupt zur Verfügung stehen
bei MS gibt's das DDK neuerdings nur noch gegen *viel* Bares
2.) die Header keine undokumentierten compilerspezifischen
Konstrukte verwenden (ist das Speicherabbild echter C++ Interfaces
offiziell dokumentiert?)
3.) der Aufwand lohnt (DriverPI != vielgenutzte API)
4.) die Zielsprache entsprechende Konstrukte unterstützt

Vollautomatisch funktioniert das in der Praxis nicht.

So unterstützt z.B. der freepascal Präprocessor nicht sämtliche
C-Präprozessor-Konstrukte. Verbleibt also die Möglichkeit,
defines zu Konstanten zu übersetzen. Konstanten dürfen aber
(im Gegensatz zu C-defines) nicht umdefiniert werden (ist in
C mit vorherigem undefine erlaubt; MS macht übrigens intensiven
Gebrauch von diesem "Trick").

Weitere Probleme tauchen auf, wenn die Übersetzung eine
"Konstrukterkennung" implementieren müsste.
Unschönes Beispiel aus "dsound.h":
___________________________________________________

#undef INTERFACE
#define INTERFACE IReferenceClock
DECLARE_INTERFACE_(IReferenceClock, IUnknown)
{ STDMETHOD(QueryInterface) (THIS_ REFIID, LPVOID *) PURE;
STDMETHOD_(ULONG,AddRef) (THIS) PURE;
STDMETHOD_(ULONG,Release) (THIS) PURE;
STDMETHOD(GetTime) (THIS_ REFERENCE_TIME *pTime) PURE;
[...]
};
#endif // __IReferenceClock_INTERFACE_DEFINED__
#ifndef IReferenceClock_QueryInterface
#define IReferenceClock_QueryInterface(p,a,b) IUnknown_QueryInterface(p,a,b)
#define IReferenceClock_AddRef(p) IUnknown_AddRef(p)
#define IReferenceClock_Release(p) IUnknown_Release(p)
#if !defined(__cplusplus) || defined(CINTERFACE)
#define IReferenceClock_GetTime(p,a) (p)->lpVtbl->GetTime(p,a)
[...]
#else // !defined(__cplusplus) || defined(CINTERFACE)
#define IReferenceClock_GetTime(p,a) (p)->GetTime(a)
[...]
#endif // !defined(__cplusplus) || defined(CINTERFACE)
#endif // IReferenceClock_QueryInterface
____________________________________________________


sollte eigentlich möglichst übersetzt werden zu ungefähr:

____________________________________________________

TYPE
IReferenceClock_GetTime = FUNCTION(p_REFERENCE_TIME) : ULONG;

IReferenceClock_functionpointerlist = packed record
QueryInterface, AddRef, Release,... : egal;
GetTime : IReferenceClock_GetTime;
end;

IReferenceClock = object
f : ^IReferenceClock_functionpointerlist;
FUNCTION GetTime(pTime : p_REFERENCE_TIME) : ULONG;
constructor init;
destructor kill;
end;

FUNCTION IReferenceClock.GetTime(pTime : p_REFERENCE_TIME) : ULONG;
BEGIN
GetTime := f^.Gettime(pTime);
END;

constructor IReferenceClock.init;
BEGIN
END;
....
____________________________________________________

PROGRAM bsp;
uses dsound;

VAR
refclk_parent : ???;
refclk : IReferenceClock;
ptim : REFERENCE_TIME;

BEGIN
...
refclk_parent.create_refclk(refclk);
refclk.GetTime(@ptim); //no errorchecking, yet
writeln(ptim);
END.

____________________________________________________

(in dem Bereich scheinen Tools,
die einem sowas ersparen, ja doch eher selten teuer/unverfuegbar
zu sein).

Das mag an der potentiellen Nutzerzahl liegen; 'Angebot<->Nachfrage'
Es gibt auf jeden fall eine Möglichkeit, unter Linux in Assembler zu
arbeiten

Ist dabei aber immer darauf angewiesen, daß irgendjemand bereits
Makros für den jeweils gewünschten syscall geschrieben hat.

Gruss

Jan Bruns

 

[Axel Schwenke]

"MaWin" <me@private.net> wrote:

Ich will nicht alle bereits beschriebene un
in einem Ordner abgehefteten Papiere aendern, bloss weil ich bei EINEM
neuen Papier einen Kreis schneiden will.

Vererbung.

Natuerlich ist das geschilderete auch kein MVC, entgegen Axels Vermutung:
http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html

Ähem. Wie hast du denn dieses historische Dokument gefunden?

Aber MVC ist ein *Konzept*. Keine Schritt-für-Schritt-Anleitung,
an die man sich sklavisch halten muß, sondern ein Designprinzip.
Ein wesentliches Ziel von MVC ist Trennung von (G)UI und Logik.

http://de.wikipedia.org/wiki/Model_View_Controller


XL

 

[Vinzent 'Gadget' Hoefler]

MaWin wrote:

Du darfst beruhigt akzeptieren, das an einer Programmiersprache
wohl was oberfaul sein muss, wenn 4 Leute erst mal beim Lesen
auf Anhieb in die Fallen tapsen, die diese Programmiersprache
bietet.

Ach, Du sprichst ueber C? ;->

Die Falle ist hier allerdings nicht die Programmiersprache sondern die
Hardware, die dahinter deklariert ist. Das praktische daran *ist* aber
eben, dass nachdem diese Deklarationen stehen, so ziemlich exakt gar
keine Fallen bei der Nutzung mehr existieren (codemaessig, logisch
natuerlich die ueblichen), es sei denn, Du bist so ambitioniert und
masochistisch, den Dreck anhand des Ada-Codes nach C konvertieren zu
wollen, statt einfach das Register Set Manual zu Rate zu ziehen.

Dazu traegt auch bei, das niemand 16 KILOBYTE lesen will,
wenn es ca. 13 Deklarationszeilen auch getan haetten wie in 'C'.

Show me. Wenn Du es zumindest halbwegs _sauber_ machen willst, werden es
einige mehr. Allein das Ausmerzen von literalen Konstanten durch
entsprechende #define duerften mehr werden. Und sicher iSv. "ich kann
Zeugs Dinge zuweisen, die ich gar nicht zuweisen darf/will" wird es
dadurch eben auch nicht. Und _genau_ das ist mein Anspruch. Deswegen
sind die Deklarationen auch etwas elaborierter als sie minimal
notwendig waeren: "You can program C in every language. - I just don't
want that."


Vinzent.

--
worst case: The wrong assumption there actually is one.

 

[Vinzent 'Gadget' Hoefler]

Jan Bruns wrote:

"Vinzent 'Gadget' Hoefler":

Jedenfalls hast Du einige sinnvolle Meditationen geliefert,
die das Nachvollziehen der Falschheit der Aussage

| Hardwarenahe Programmierung heist Kernel-Treiber schreiben und das
| macht man nur in C/C++.

ermöglichen.

Das hoffe ich doch. Immerhin wuerde der Beweis der Korrektheit obiger
Aussage meine Existenz an sich in Frage stellen.

BTW, Dinge wie

apicdef.h:
|#define APIC_EIO_ACK 0x0 /* Write this to the EOI register */

scheinbar ein Tippfehler, der evt. ein Grund fuer

apic.h:
|/* Docs say use 0 for future compatibility */
|apic_write_around(APIC_EOI, 0);

sein koennte,

lassen mich dann doch daran zweifeln, ob C fuer hardwarenahe
Programmierung tatsaechlich so gut geeignet ist. (Der Sinn der
Deklaration von Konstanten, um sie dann im geeigneten Moment nicht zu
benutzen, erschliesst sich mir nicht.)

Diese Aussage war wohl ursprünglich auf HW-nahe
Programmierung für x86-PCs gemünzt.

Selbst da wuerde sie nicht stimmen.

Na ja, wer Treiber für Linux oder Win schreiben muss, der wird
wohl in der Tat zumindest ausschnittweise C benötigen, zumindest
um die OS-API bedienen zu können

Ja. Du hast die Gruende, warum man Schnittstellen einer C-API zu anderen
Sprachen praktisch nur per Hand machen kann, ja mindestens ansatzweise
schon gezeigt. Das ist muehsam und fuer einen Treiber, der in der
Groessenordnung von ueblicherweise kaum mehr als 1 bis 2 kSLOC liegt,
einfach zu aufwendig. In der Zeit, die man zum Konvertieren passender
Header benoetigt, hat man den C-Code auch ausreichend entwanzt. ;-)

(in dem Bereich scheinen Tools,
die einem sowas ersparen, ja doch eher selten/teuer/unverfügbar
zu sein).

Es ist fuer so ein Tool in der Praxis faktisch unmoeglich, aus ueblichen
C-Headern /brauchbare/ Deklarationen zu entwickeln.

Auch das hat nix mit HW-, sondern vielmehr mit OS-Nähe
zu tun.

Ja.

Gemeint war wohl:
Hardwarenahe Programmierung hat manchmal einen Bezug zu
Kernel-Treibern. Linux/Win-Kernel-Treiber werden für oft in C
formuliert.

Das waere weniger inkorrekt gewesen, ja.


Vinzent.

--
worst case: The wrong assumption there actually is one.

 

[Bernd Laengerich]

Vinzent 'Gadget' Hoefler wrote:

Ich weiss nicht, aber funktionierende Compiler fuer die Zielplattformen,
die ich brauche, existieren. Wo sie nicht existieren, gibt es notfalls
Ada-nach-C-Konverter.

Hmm, aber das widerspricht der Aussage, bei C wären die
int-to-pointer-casts undefined, denn der Ada-nach-C-Konverter muß ja
genau darauf aufbauen. In logischer Konsequenz könnten dann nämlich
nicht alle Ada-Konstrukte abgebildet werden.

Bernd

 

[Bernd Laengerich]

Martin Lenz wrote:

So schlimm ist es meistens nicht, aber eine Vollbremsung statt Kupplung

Hmm, bei europäischen Autos mit Autmakatikgetriebe ist das Bremspedal
aber doch nicht so breit wie bei den Amis. Ich trat da bisher immer ins
Leere, wenn ich mal nicht dran dachte. Auch die rechte Hand fiel
manchmal herunter (Toyota Previa Automatik mit Lenkradschaltung)

Bernd

 

[Vinzent 'Gadget' Hoefler]

Bernd Laengerich wrote:

Vinzent 'Gadget' Hoefler wrote:

Ich weiss nicht, aber funktionierende Compiler fuer die
Zielplattformen, die ich brauche, existieren. Wo sie nicht
existieren, gibt es notfalls Ada-nach-C-Konverter.

Hmm, aber das widerspricht der Aussage, bei C wären die
int-to-pointer-casts undefined,

Hmm, nein. Wir haben uns ja mittlerweile auf "implementation-defined"
geeinigt.

denn der Ada-nach-C-Konverter muß ja
genau darauf aufbauen. In logischer Konsequenz könnten dann nämlich
nicht alle Ada-Konstrukte abgebildet werden.

Das iSv. "alle" kann man im allgemeinen ohnehin nicht (direkt). Bei
protected types z.B. kann man sich notfalls mit "selbstgebastelten"
Semaphoren behelfen, spaetestens beim Tasking musst Du es irgendwie
auch die zur Verfuegung stehende Laufzeitbibliothek mappen. Mit
Standard-C kommst Du da nicht mehr allzuweit.


Vinzent.

--
worst case: The wrong assumption there actually is one.