Beiträge anzeigen

Zitat von: bluecode am 19. March 2012, 19:08
Wie gesagt: Datenstrukturen. Zumindest ich würde meinen Monitor gegen die Wand schmeißen wenn ich die jedes Mal wieder neu implementieren müsste oder auf die Krücke void* zurückfallen würde.
Wenn man keine Container braucht, sondern eingebettete Strukturen benutzen kann (und ich würde behaupten, das ist fast immer der Fall), dann kommt man in C mit ein bisschen Präprozessoreinsatz recht weit.

Dann würde ich sowas wie boost's intrusive container(s) bauen.

10

OS-Design / Re: C oder C++

« am: 19. March 2012, 19:08 »

Zitat von: nnosdev am 19. March 2012, 00:51

Okay, Templates sind sicherlich eine angenehme Sache. Aber jetzt auf die schnelle wüsste ich nichts wo ich die tief im Kernel brauchen könnte.

Wie gesagt: Datenstrukturen. Zumindest ich würde meinen Monitor gegen die Wand schmeißen wenn ich die jedes Mal wieder neu implementieren müsste oder auf die Krücke void* zurückfallen würde.

Zitat

Scoped-Lock ist ein nettes Design-Pattern! Aber theoretisch liese sich das einigermaßen simpel auch mit C realisieren.

Ich wüsste nicht wie man das in C nachmachen würde und schon gar nicht "simpel".

11

Lowlevel-Coding / Re: Error: cannot represent relocation type BFD_RELOC_X86_64_GOTP

« am: 23. February 2012, 22:23 »

Also ich hab für meinen x64 Port des Kernels kein PIC genommen, sagt meine configure-Datei. Warum willst du das denn nehmen?

12

Zwei Anmerkungen:
1. Was überhaupt nicht zu Sprache kam waren Templates für nettere Container ohne void* bzw. einmal bei der Implementierung castet man halt und nicht ständig. Ich finde, dass das Datenstrukturen allgemein um einiges angenehmer macht
2. Zur oben erwähnten RAII: Zwei weitere sehr relevante Beispiele ist std::shared_ptr für automagische Freigabe von Objekten (in meinen letzten Projekten hatte ich kein einziges delete mehr) und automatisches freigeben von Locks (das hatte ich auch mal so implementiert und fand es sehr hilfreich:

Code: [Auswählen]

Mutex mymutex;
[...]
void f([...])
{
  // code außerhalb der critical section

  {
    scoped_lock l(mymutex); // <- ruft mymutex.lock() auf

    // code innerhalb des critical section
  } // <- exakt hier kommt der Destruktor von l und ruft mymutex.unlock() auf

  // code außerhalb des critical section
}

Das schöne daran ist, dass es schlichtweg egal ist wie man ans Ende des Blocks kommt, es wird immer der Lock freigegeben, ohne häßliches goto + rumgehacke um den return value irgendwie dann am Ende hinzukriegen.

13

Lowlevel-Coding / Re: Error: cannot represent relocation type BFD_RELOC_X86_64_GOTP

« am: 23. February 2012, 20:12 »

Zitat von: ScAr_TeX am 19. February 2012, 17:34

Hat zufällig jemand einen Lösungsansatz für dieses Problem?

-mcmodel=kernel, wobei du damit auch nicht an die Adresse die du dir vorstellst kommst, sondern halt an -2GB.

14

Softwareentwicklung / Re: cast von Zeiger auf nicht Zeiger und umgekehrt in C unter spezieller Berücksi...

« am: 11. February 2012, 00:33 »

Nein, die Frage ist was genau standardkonform überhaupt bedeutet. Und da hilft ein Test mit Compiler X auf Platform Y halt garnichts.

15

Softwareentwicklung / Re: cast von Zeiger auf nicht Zeiger und umgekehrt in C unter spezieller Berücksi...

« am: 10. February 2012, 22:19 »

Und was genau soll das zeigen, Dimension?

16

Softwareentwicklung / Re: cast von Zeiger auf nicht Zeiger und umgekehrt in C unter spezieller Berücksi...

« am: 30. January 2012, 19:45 »

Zitat von: taljeth am 30. January 2012, 10:39

Zitat
offsetof(), das ist IMHO auch deswegen nötig weil ja das tatsächliche Speicherlayout in Strukturen auch wieder implementierungsspezifisch ist. Das meistens dahinter im Endeffekt nur der selbe Hack steckt den Du auch direkt benutzen würdest ist da erst mal egal, immerhin muss dafür derjenige gerade stehen der die libc für die konkrete Plattform gebaut hat und der sollte genau wissen was geht und was nicht.
Und jetzt rate mal, wie offsetof implementiert ist?
Das ist einfach ein Makro, das die Pointerarithmetik versteckt. Wenn das Makro also nicht mehr kompiliert, hast du auch kein offsetof. Als Funktion, die man dazulinken könnte, geht das nicht.

Da wäre ich mir nicht so sicher, gcc hat dafür ein builtin, siehe hier. Aber keine Ahnung warum genau man das brauch, ich versteh auch nicht was es da so für Randfälle für den "member-designator" geben kann, die man eventuell mit Pointerarithmetik alleine nicht hinbekommt.

17

Softwareentwicklung / Re: cast von Zeiger auf nicht Zeiger und umgekehrt in C unter spezieller Berücksi...

« am: 28. January 2012, 11:47 »

Ich würde mal vermuten man darf dann auch die Differenz der beiden Pointer wieder zum kleineren addieren und dieser muss dann mit dem größeren übereinstimmen, oder?

18

Softwareentwicklung / Re: cast von Zeiger auf nicht Zeiger und umgekehrt in C unter spezieller Berücksi...

« am: 26. January 2012, 20:38 »

@Dimension: Dein Code macht überhaupt keinen Sinn (void*-Pointer dereferenzieren?)

Standard-C garantiert beim casten afaik sowieso nur, dass in (u)intptr_t gecastet werden kann und wieder zurück (und das Ergebnis davon gleich dem Zeiger vorher ist). Ich würde vermuten, dass es nicht garantiert ist, dass man auf den Integer verändert und dann zurückcastet, bin mir aber in keinster Weise sicher. Problematischer ist, dass bei far-Zeigern, dass zwei Zeiger ungleich sein können aber trotzdem den gleichen Speicher adressieren. Unabhängig davon ist ständiges wechseln der Segmentregister eine bescheidene Idee.

19

Lowlevel-Coding / Re: GDT-Alignment

« am: 07. January 2012, 14:13 »

Zitat von: rizor am 07. January 2012, 13:46

Ja, der GDB sagt, dass alles gut aussieht (vom Speicherlayout her).

Nur um das ganz genau geklärt zu haben: Du schaust im gdb auch direkt vor der Stelle an der es schief läuft? Ansonsten kannst du auch mal im bochs debugger dir das direkt davor ausgeben lassen. ~~Ist das eigentlich noch im Realmode? Wie sehr freut sich denn die IVT da? Adresse 0 hat auch noch den Vorteil, dass man da um den Dreh bei einer Nullpointer-Dereferenzierung gerne mal hinschreibt.~~ E_ALGIN_NOT_ADDRESS

20

Lowlevel-Coding / Re: GDT-Alignment

« am: 06. January 2012, 23:46 »

Zitat von: rizor am 06. January 2012, 22:41

Wenn ich die GDT an 8-Byte ausrichte (laut Intel die optimale Position), bekomme ich einen GPF.

Einen GPF bei was bzw. wann? Und was sagen die gängigen Emulatoren zum Grund des GPF? Ist die Struktur auch im Speicher korrekt (direkt vor dem GPF)?

edit: Was ist das eigentlich für eine komische Struktur mit .value und .mapping?