Forum: PC-Programmierung malloc nur innerhalb einer main ?


von Peter B. (funkheld)


Lesenswert?

Hallo, guten Tag.

Ich finde malloc nur innerhalb einer main bei den Lehrtexten.
Ausserhalb kommt eine Fehlermeldung wenn ich sie ganz am Anfang setze.

Wie kann man bitte in einer Procedure auf malloc zb *p zugreifen wenn 
die
sich in einer main befindet.


Gruss

von Johannes S. (Gast)


Lesenswert?

malloc() darf man überall aufrufen, ausser vielleicht in einer ISR. Wenn 
der allozierte Speicher für den Aufrufer ist dann muss man den eben als 
return Wert zurückliefern.

von cppbert (Gast)


Lesenswert?

Peter B. schrieb:
> Hallo, guten Tag.
>
> Ich finde malloc nur innerhalb einer main bei den Lehrtexten.
> Ausserhalb kommt eine Fehlermeldung wenn ich sie ganz am Anfang setze.
>
> Wie kann man bitte in einer Procedure auf malloc zb *p zugreifen wenn
> die
> sich in einer main befindet.
>
> Gruss

Immer ein Beispiel posten, und wenn du darueber nach denkst kann das ja 
eigentlich nicht sein, wuerde ja jegliche programmstrukturierung 
erschweren  so bald man malloc braucht

von Olaf D. (Firma: O.D.I.S.) (dreyero)


Lesenswert?

Da ich meine Glaskugel nicht finden kann, kann ich heute nur Vermutungen 
über die Fehlermeldungen und deren Ursachen anstellen.

main malloc procedure ???

Klingt als ob du versuchst Pascal und C zu verheiraten.

Gruß
Olaf

(WoistnurdieverdammteGlaskugelgottverdammmich)

: Bearbeitet durch User
von Peter B. (funkheld)


Lesenswert?

Ausserhalb kommt Illegale command....

Innerhalb der main funktioniert es.

Danke.
1
#include <stdio.h>
2
#include <stdlib.h>
3
4
unsigned   char *p = malloc(64000 * sizeof(char));
5
unsigned   char *z = malloc(64000 * sizeof(char));
6
7
int main(void) {
8
  
9
10
11
   if(p != NULL) {
12
      *p=99;             /* alternativ auch p[0] = 99  */
13
      *(p+63999) = 255;  /* alternativ auch p[63999] = 255 */
14
      printf("Allokation erfolgreich von p... \n");
15
   }
16
   else {
17
      printf("Kein virtueller RAM mehr verfuegbar ...\n");
18
      return EXIT_FAILURE;
19
   }
20
   
21
   if(z != NULL) {
22
      *z=100;            /* alternativ auch p[0] = 100  */
23
      *(z+63999) = 101;  /* alternativ auch p[63999] = 101 */
24
      printf("Allokation erfolgreich von z... \n");
25
   }
26
   else {
27
      printf("Kein virtueller RAM mehr verfuegbar ...\n");
28
      return EXIT_FAILURE;
29
   } 
30
   
31
   printf("%d %d\n", p[0], p[63999]);
32
   /* Sie können die Werte auch so ausgeben lassen. */
33
   printf("%d %d\n", *p, *(p+63999));
34
   
35
   printf("%d %d\n", z[0], z[63999]);
36
   /* Sie können die Werte auch so ausgeben lassen. */
37
   printf("%d %d\n", *z, *(z+63999)); 
38
   return EXIT_SUCCESS;
39
}

von Olaf D. (Firma: O.D.I.S.) (dreyero)


Lesenswert?

Außerhalb der main Funktionen liegt der ctor-Bereich.
Da sind nur Initialisierungen erlaubt. Keine Funktionsaufrufe
die ja eine Reihenfolge benötigen.

Gruß
Olaf

von cppbert (Gast)


Lesenswert?

du sollte wirklich noch ein bisschen die C Sprache lernen

es ist (so gut wie) nie erlaubt ausserhalb von Funkionen (z.B. main oder 
put_pixel usw.) Code aus zu führen, das ist invalider C Code

printf würde da auch nicht gehen - hat nichts mit malloc zu tun

von Nico W. (nico_w)


Lesenswert?

Schonmal drüber nachgedacht, dass es neben Main noch weitere Funktionen 
geben darf?

Und wie kommt man auf die Idee dynamisch statischen Speicher zu 
erzeugen?

Und wo gibt's du ihn wieder frei?

von Johannes S. (Gast)


Lesenswert?

Peter B. schrieb:
> unsigned   char *p = malloc(64000 * sizeof(char));
> unsigned   char *z = malloc(64000 * sizeof(char));
>
> int main(void) {

nee, sowas ist auch nicht erlaubt, Funktionsaufrufe im Niemandsland.
1
unsigned   char *p;
2
unsigned   char *z;
3
4
int main(void) {
5
    p = malloc(64000 * sizeof(char));
6
    z = malloc(64000 * sizeof(char));

von Peter B. (funkheld)


Lesenswert?

Ahh...Danke.

Wusste nicht das man das bei der malloc ausserhalb setzen kann.
unsigned   char *p;
unsigned   char *z;

Alle Texte die ich mir angeschaut habe war auch keine malloc ausserhalb 
der main. Darum kannte ich es nicht.

Danke.

von Programmierer (Gast)


Lesenswert?

Peter B. schrieb:
> Alle Texte die ich mir angeschaut habe war auch keine malloc ausserhalb
> der main.

malloc ist hier nicht speziell. Du kannst jede Funktion von der main() 
oder jeder anderen Funktion aus aufrufen. Das gezeigte malloc() 
außerhalb jeglicher Funktion geht aber nicht, und das gilt auch für das 
Aufrufen aller anderen Funktionen. Das hat nichts mit malloc() an sich 
zu tun.

Du willst einen globalen fixen Speicherblock haben, welcher für die 
ganze Laufzeit des Programms existiert? Dann mach doch einfach ein fixes 
Array:
1
unsigned char z [64000];

sizeof(char) ist übrigens immer 1.

von Peter B. (funkheld)


Lesenswert?

Danke.

Für die Wechselgrafik bei VGA brauche ich jetzt 2x 64000Byte

Gruss

von Peter B. (funkheld)


Lesenswert?

Hmmm...Danke.
Wie wird dann jetzt die malloc-adresse bitte übergeben an eine Funktion?


Mit int *pp geht es nicht und mit int pp auch  nicht.
-------------------------------------------------
void mal_vga2(...)
{
  int y;

  for (y = 0; y <=63999; y++)
  {
    pokeb (VIDEO_SEGMENT, y,pp[y]);
  }
}
-------------------------------------------------

Gruss

von Programmierer (Gast)


Lesenswert?

Lies doch bitte ein Buch über C...
1
unsigned char pp [64000];
2
3
void mal_vga2(...)
4
{
5
  for (size_t y = 0; y < sizeof(pp); ++y)
6
  {
7
    pokeb (VIDEO_SEGMENT, y, pp+y);
8
  }
9
}
Statt "pp+y" geht auch "&pp[y]", was aber IMO etwas umständlich ist.

von Johannes S. (Gast)


Lesenswert?

das ist auch keine 'malloc adresse' sondern ein Pointer oder auf Deutsch 
Zeiger. Und das Thema sollte man zumindest im Buch nachlesen.
1
void mal_vga2(unsigned char* pp)
2
{
3
}

der int Pointer würde bei 63999 Unheil anrichten.

von leo (Gast)


Lesenswert?

Peter B. schrieb:
> Wie wird dann jetzt die malloc-adresse bitte übergeben an eine Funktion?

Moechtest du vielleicht deine Schwierigkeiten etwas auftrennen?

1) Lerne C. Wechsle deine Lehrbehelfe, was du jetzt hast taugt wohl 
wenig.
2) Spiel mit TC/DOS usw.

Derzeit hast du einfach zu viele Probleme auf einmal.

My 2c

leo

von Peter B. (funkheld)


Lesenswert?

http://openbook.rheinwerk-verlag.de/c_von_a_bis_z/014_c_dyn_speicherverwaltung_002.htm#mj15d2f92e13cde897bb59c32a20d2a31a

Das Buch habe ich hier.

Aber meine Fragen  dort drin ein Alptraum.
Da sucht man sich ein Wolf.

Gruss

von Johannes S. (Gast)


Lesenswert?

ja, weil das Verständnis für Zeiger fehlt. Das ist kein malloc Problem, 
das sind mehrere Etagen darunter wo du anfangen musst.

von Peter B. (funkheld)


Lesenswert?

Ich habe ja dieses TC 3.0 für DOS.

Ich möchte ein Spiel mit C entwickeln.
Da kommt jetzt wohl zuviel zusammen VGA, malloc-Speicher usw..

------------------------------
1) Lerne C. Wechsle deine Lehrbehelfe, was du jetzt hast taugt wohl
wenig.
2) Spiel mit TC/DOS usw.
----------------------------

von Programmierer (Gast)


Lesenswert?

Peter B. schrieb:
> Ich habe ja dieses TC 3.0 für DOS.
>
> Ich möchte ein Spiel mit C entwickeln.

Du hast also einen Schraubenzieher und möchtest ein Space Shuttle bauen? 
Möchtest du nicht vielleicht erst etwas mehr über Maschinenbau, 
Aerodynamik und moderne Werkzeuge lernen, bevor du so ein 
Himmelfahrtskommando startest?

Also ein aktueller C++ Compiler (z.B. g++) mit einer aktuellen IDE (z.B. 
Qt-Studio) und einem aktuellen Grafik-Framework (z.B. OpenGL) oder einer 
richtigen Spiele-Engine (z.B. Unreal Engine).

Du machst es dir unnötig schwierig durch Nutzung einer veralteten 
Plattform und hohen Ambitionen, ohne erstmal die absoluten Grundlagen zu 
lernen. C und C++ sind schwierige Sprachen, da muss man sich erst mit 
vielen Details auseinander setzen.

von Programmierer (Gast)


Lesenswert?

PS: Das Rheinwerk-Buch ist ziemlich fehlerbehaftet. Auf der verlinkten 
Seite steht z.B. was von "ANSI-C++" - das ist zwar rein technisch nicht 
komplett falsch, aber dennoch eine sehr unübliche Bezeichnung. Man 
spricht normalerweise von ISO-C++.

von Johannes S. (Gast)


Lesenswert?

zumindest gibt es in dem Buch das Kapitel 12 - Zeiger. Das sollte man 
keinesfalls überspringen bevor es an die Spieleprogrammierung geht...

von S. R. (svenska)


Lesenswert?

Peter B. schrieb:
> Das Buch habe ich hier.

Das Buch "C von A bis Z" ist für deine Umgebung ein paar Jahre zu jung. 
Geh in die örtliche Bibliothek, dort in die Büchersuche und suche nach 
Literatur, die aus der Zeit deines Compilers stammt.

Kann sein, dass die das aus dem Keller holen müssen (war bei uns damals 
in der Uni so), aber normalerweise ist sowas vorhanden.

Da findest du sicherlich auch Informationen zur Programmierung von 
VGA-Grafik unter DOS mit Turbo C++.

von Dirk B. (dirkb2)


Lesenswert?

Peter B. schrieb:
> 
http://openbook.rheinwerk-verlag.de/c_von_a_bis_z/014_c_dyn_speicherverwaltung_002.htm#mj15d2f92e13cde897bb59c32a20d2a31a
>
> Das Buch habe ich hier.
>
> Aber meine Fragen  dort drin ein Alptraum.
> Da sucht man sich ein Wolf.

Da hast du recht. So heißt der Autor.

Allerdings hat der Autor keinen guten Ruf und die Online-Ausgabe (1. 
Auflage) ist noch voller Fehler.

von cppbert (Gast)


Lesenswert?

Peter B. schrieb:
> Ich habe ja dieses TC 3.0 für DOS.
>
> Ich möchte ein Spiel mit C entwickeln.
> Da kommt jetzt wohl zuviel zusammen VGA, malloc-Speicher usw..
>
> ------------------------------
> 1) Lerne C. Wechsle deine Lehrbehelfe, was du jetzt hast taugt wohl
> wenig.
> 2) Spiel mit TC/DOS usw.
> ----------------------------

du brauchst kein malloc um zu probieren wie Pointer an Funktionen 
uebergeben werden - da reicht dir auch ein Zeiger auf int
1
#include <stdio.h>
2
3
void test(int* ptr)
4
{
5
  *ptr = 20;
6
}
7
8
int main()
9
{
10
  int x;
11
  x = 10;
12
  printf("%i\n", x);
13
  test(&x);
14
  printf("%i\n", x);
15
  return 0;
16
}

von cppbert (Gast)


Lesenswert?

cppbert schrieb:
> Peter B. schrieb:
>> Ich habe ja dieses TC 3.0 für DOS.
>>
>> Ich möchte ein Spiel mit C entwickeln.
>> Da kommt jetzt wohl zuviel zusammen VGA, malloc-Speicher usw..
>>
>> ------------------------------
>> 1) Lerne C. Wechsle deine Lehrbehelfe, was du jetzt hast taugt wohl
>> wenig.
>> 2) Spiel mit TC/DOS usw.
>> ----------------------------
>
> du brauchst kein malloc um zu probieren wie Pointer an Funktionen
> uebergeben werden - da reicht dir auch ein Zeiger auf int
> #include <stdio.h>
>
> void test(int* ptr)
> {
>   *ptr = 20;
> }
>
> int main()
> {
>   int x;
>   x = 10;
>   printf("%i\n", x);
>   test(&x);
>   printf("%i\n", x);
>   return 0;
> }

bei malloc oder deinem compact-model könnte es es ein far pointer sein

also eher

int far *ptr

von leo (Gast)


Lesenswert?

cppbert schrieb:
> bei malloc oder deinem compact-model könnte es es ein far pointer sein

Ad TO: Genau das meinte ich. "könnte" ..., das ist nicht hilfreich. Wie 
gesagt, zuerst mal (aktuelles) C lernen, dann die Abgruende von 
Uralt-IT.

leo

von Johannes S. (Gast)


Lesenswert?

Oder TurboPascal benutzen, da gibts doch auch Grafik Units für.
Aber das man sich das überhaupt antun möchte... Fertige alte SW mal 
laufen zu lassen oder mal wieder einen Apple ][ prompt zu sehen ist ja 
cool, aber alleine auf die Quälerei mit den 64k Segmenten hätte ich 
überhaupt keinen Bock.
Einen schnuckeligen Cortex-M mit TFT, schnell, stromsparend, Spaß.  Da 
hätten auch die Enkel noch was von.

von Dirk B. (dirkb2)


Lesenswert?

Johannes S. schrieb:
> Oder TurboPascal benutzen, da gibts doch auch Grafik Units für.

Für Turbo-C auch.

von Peter B. (funkheld)


Lesenswert?

Ja danke.

Der TC3.0 hat eine gute Grafik Unit.

Aber das wollte ich nicht.

Alte Bücher darüber finde ich nicht über dieses TC3 und altgebackene C 
für den 8086. Nur hier da kurze Berichte.

Gruss

von Programmierer (Gast)


Lesenswert?

Peter B. schrieb:
> Alte Bücher darüber finde ich nicht über dieses TC3 und altgebackene C
> für den 8086.

Warum tust du dir das dann an... es gibt jede Menge Bücher über 
aktuelles C und die dazugehörigen Umgebungen (z.B. Visual Studio), und 
auch jede Menge leistungsfähige Tools. Warum überhaupt C, mit z.B. Java 
oder C# kann man viel leichter Desktop-Anwendungen schreiben; auch 
hierzu gibt es Unmengen an Büchern und extrem ausgefeilten Tools. Wenn 
man z.B. mal mit IntelliJ arbeitet fragt man sich, warum man sich mit 
Turbo C rumärgert... Auf dem Desktop, außerhalb von Treibern und 
OS-Entwicklung, gibt es sehr wenig Grund für C.

von cppbert (Gast)


Lesenswert?

Programmierer schrieb:
> Warum tust du dir das dann an...

Er hat einen MIST FPGA mit einem 8086 Core sich zum spielen besorgt

von S. R. (svenska)


Lesenswert?

cppbert schrieb:
>> Warum tust du dir das dann an...
> Er hat einen MIST FPGA mit einem 8086 Core sich zum spielen besorgt

...und weigert sich, zeitgenössische Literatur zu benutzen.

von cppbert (Gast)


Lesenswert?

Peter B. schrieb:
> Alte Bücher darüber finde ich nicht über dieses TC3 und altgebackene C
> für den 8086. Nur hier da kurze Berichte.

die C Probleme die du hast passieren auch mit den neuesten C Kompilern
(ja, inline assembler sieht anders aus und ja es läuft nicht unter DOS 
aber davon abgesehen wären deine ganzen bisherigen Probleme so auch 
unter jedem top-aktuellen C Kompiler passiert)

-Funktionsaufruf ausserhalb von main oder anderen Funktionen (bei dir 
mit malloc passiert)
-Pointer an Funktion übergeben
-x <=320
-case ohne break
usw.

von Programmierer (Gast)


Lesenswert?

cppbert schrieb:
> Programmierer schrieb:
> Warum tust du dir das dann an...
>
> Er hat einen MIST FPGA mit einem 8086 Core sich zum spielen besorgt

Und da gibt es keine moderneren Soft Cores für, wie Cortex-M1? Und muss 
man sich unbedingt an dieses Board binden und sich mit dem antiken 8086 
Kram rumschlagen? Man könnte z.B. auch ein BeagleBone Black nehmen, der 
kann FullHD HDMI Grafik. Den kann man mit Linux oder auch Bare Metal 
programmieren, und dafür brandaktuelle C-und C++-Tools benutzen. Oder 
Java, Python, Tcl,... Far Pointer, Segment Umschaltung und so was 
brauchts da nicht.

von cppbert (Gast)


Lesenswert?

ok das mit malloc kompiliert auch unter dem aktuellen gcc

https://gcc.godbolt.org/z/3FaNQp

wieso geht das?

von Programmierer (Gast)


Lesenswert?

cppbert schrieb:
> wieso geht das?

Weil du auf C++ gestellt hast. C++ erlaubt sowas. Ist natürlich ziemlich 
sinnfrei; man kann auch einfach ein globales Array (s.o.) definieren 
oder einen Vector nutzen:
1
std::vector<unsigned char> p (64000);

Erspart auch die Fehlerbehandlung.

von cppbert (Gast)


Lesenswert?

ich kompilier so selten C das ich gar nicht merke wenn ich mit der 
vollen C++ Laserkanone daher komme

von cppbert (Gast)


Lesenswert?

Ist dann aber auch blöd für Peter wenn er solche Beispiele findet

von Peter B. (funkheld)


Lesenswert?

Hallo, guten Tag.
Jetzt funktioniert es so wie ich es mit der Grafik möchte und dem malloc 
dank eurer ERBARMUNGSLOSEN Hilfe.

Ich würde gerne mal ein anders C ausprobieren für den 8086 aus den 
früheren Tagen unter DOS.

Würde mich über mehrere Tipps freuen.

Aber keine Fragen : Was willst du denn jetzt schon wieder damit !

Danke.

Gruss

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Bevor ich mit LFS/BLFS "mein" OS gefunden hab', hab' ich in C unter DOS 
mittels rhide und djgpp programmiert. Da braucht's aber mindestens einen 
'386 dazu. Fuer Telespiele werf' ich mal noch die Allegro-lib ins 
Rennen.

http://www.rhide.com/

Hups, das koennt's sogar noch geben...

Gruss
WK

von Peter B. (funkheld)


Lesenswert?

Hallo, danke für deine Info.

djgpp finde ich nicht nur dieses rhide

Gruss

: Bearbeitet durch User
von Dergute W. (derguteweka)


Lesenswert?

Moin,

Peter B. schrieb:
> Mir fehlt jetzt das wissen, wie ich das zb unter DOS (DOSBox) zum
> starten bekomme.

Weil meine djgpp/rhide Zeiten schon >20 Jahre her sind und ich auch 
schon lange kein DOS mehr gebootet hab', fehlt mir mittlerweile das 
Wissen auch.

Ich bin mir aber sicher, es mir durch intensives Studium der mit den von 
mir genannten Schlagworten oder gar durch Anklicken auffindbaren 
Websites wieder aneignen zu koennen. Und das traue ich dir auch zu.

Gruss
WK

von Olaf B. (Firma: OBUP) (obrecht)


Lesenswert?


: Bearbeitet durch User
von Peter B. (funkheld)


Lesenswert?

Danke, werde ich mal versuchen.

Gruss

von Bernd K. (prof7bit)


Lesenswert?

Programmierer schrieb:
> oder einer
> richtigen Spiele-Engine (z.B. Unreal Engine).

Vielleicht will er erstmal nur sowas wie Snake oder Tetris, das bekommt 
man auch mit Uralt-Compilern in ner DOS-Box hin, was komplexeres würd 
ich in dem Stadium auch noch gar nicht angehen wollen.

von Peter D. (peda)


Lesenswert?

Peter B. schrieb:
> Ich finde malloc nur innerhalb einer main bei den Lehrtexten.

Das ist Quatsch. Dann braucht man malloc nicht, sondern kann den 
Speicher direkt belegen.
Malloc benötigt man nur, wenn unterschiedliche Instanzen Speicher 
belegen und freigeben sollen. Daher darf auch jede Task malloc bzw. free 
aufrufen.
Z.B. ein Interrupt empfängt ein Datenpaket und legt es per malloc ab. 
Das Main parst das Datenpaket und gibt es per free wieder frei.

von Nick M. (Gast)


Lesenswert?

djgpp? Da kommt mir das Grausen!

Ich würde den Watcom Compiler verwenden. "Jetzt" als OpenWatcom zu 
finden.
Auch die Dokumentation dazu ist einfach nur hervorragend.

von Bernd K. (prof7bit)


Lesenswert?

Nick M. schrieb:
> djgpp? Da kommt mir das Grausen!
>
> Ich würde den Watcom Compiler verwenden.

Ich würde überhaupt keinen Compiler aus dem letzten Jahrtausend nehmen 
und auch kein Betriebssystem aus dem selbigen. Denn wozu? Warum?

von Nick M. (Gast)


Lesenswert?

Bernd K. schrieb:
> Denn wozu? Warum?

Weil es ihm Spaß macht?
Ich würde den auch nicht hernehmen, ausser ich hätte mir so ein 
Retro-Projekt in den Kopf gesetzt (was durchaus passieren könnte).

von Oliver S. (oliverso)


Lesenswert?

Immerhin hat er sich ja innerhalb von einer Woche von TC1.0 zu 3.x 
vorgearbeitet, da sollte er es bis zum Sommer zu einer einigermaßen 
aktuelle Compilerversion geschafft haben.

Oliver

von S. R. (svenska)


Lesenswert?

Oliver S. schrieb:
> Immerhin hat er sich ja innerhalb von einer Woche von TC1.0 zu 3.x
> vorgearbeitet, da sollte er es bis zum Sommer zu einer einigermaßen
> aktuelle Compilerversion geschafft haben.

Die wird aber mit Sicherheit nicht auf seinem 8086 laufen.
Aber gut, das tun DJGPP oder Watcom auch nicht.

von Nick M. (Gast)


Lesenswert?

S. R. schrieb:
> Die wird aber mit Sicherheit nicht auf seinem 8086 laufen.
> Aber gut, das tun DJGPP oder Watcom auch nicht.

Hmmm zumindest läuft eine OpenWatcom-Version auch unter DOS. Welches DOS 
genau und was der kleinstmögliche Prozessor ist, muss der TO selbst 
rausfinden.

Aber nochmal: Das djgpp ist einfach jämmerlich. Fragt mich bitte nicht 
wieso genau, das ist über 10 Jahre her. Seinerzeit hab ich dann wieder 
den OpenWatcom verwendet und der Spaß war wieder da. Ich hätte auch 
dafür bezahlt. So wie ich schon mal dafür > 1000 DM (nein, keine 
Reichsmark) gezahlt habe und das nie bereut habe.

von Bernd K. (prof7bit)


Lesenswert?

Nick M. schrieb:
> Bernd K. schrieb:
>> Denn wozu? Warum?
>
> Weil es ihm Spaß macht?

Ja, wenn man schon jahrelang programmiert und plötzlich einen 80er 
Flashback bekommt und dann auf nem ausgedehnten Retro-Trip ist, um in 
Nostalgie zu schwelgen oder was auch immer. Oder wenn man gezwungen ist 
so ein altes System weiterzupflegen oder am Laufen zu halten. Seh ich 
alles ein.

Aber OP will einfach nur C lernen!

Wenn ich lernen will wie man Auto fährt geh ich ja auch nicht ins Museum 
und leih mir einen Benz Patent-Motorwagen Nummer 1 aus zum Üben. Da geh 
ich in die Fahrschule und lern auf ner halbwegs aktuellen Karre. Erst 20 
Jahre später kauf ich mir vielleicht auch mal nen Oldtimer wenn mich das 
Retro-Fieber packt, aber bis dahin kann ich vermutlich schon fahren.

Obligatorischer Autovergleich Ende.

: Bearbeitet durch User
von Nick M. (Gast)


Lesenswert?

Bernd K. schrieb:
> Aber OP will C lernen!

Ja, mit einem selbstgewählten Projekt. Irgendwas was ihm Spaß macht 
und bei dem er sich vor niemanden rechtfertigen muss.

Er kann ja zur Übung OpenGL nachprogrammieren, nur da ist das Scheitern 
garantiert. Mit so DOS-Gedönsle im Bildschirmspeicher kommt aber auch 
ein Anfänger weiter. Jedenfalls ist die Aufgabe deutlich überschaubarer.

Alte Geschichte:
Ich hatte mit Pascal angefangen zu programmieren. Irgendwann stand C im 
Raum und ich hab's ausprobiert und es gehasst. Dann hab ich mir eine 
Aufgabe gestellt (Zeitauswertungs-SW) das sogar mit überlagerten 
Fenstern (selber implementiert) arbeitete. Das hat dann Spaß gemacht. 
Und ich hab mich mit C zusammengerauft und mag es seitdem sogar.
Das war übrigens vor dem kommerziellen Internet.

von Bernd K. (prof7bit)


Lesenswert?

Nick M. schrieb:
> Mit so DOS-Gedönsle im Bildschirmspeicher kommt aber auch
> ein Anfänger weiter.

Das kann er auch auf Windows 10 machen mit den aktuellen Visual-C 
Werkzeugen oder auch auf nem aktuellen Linux mit nem aktuellen gcc, 
dafür muss man nicht in der Steinzeit rumgraben und totgeglaubte Leichen 
exhumieren und wiederbeleben.

: Bearbeitet durch User
von Nick M. (Gast)


Lesenswert?

Bernd K. schrieb:
> Das kann er auch auf Windows 10 machen mit den aktuellen Visual-C
> Werkzeugen

Ich esse meine Leberkäsesemmeln nie mit Ketchup!
Leberkäs mit Ketchup gehört verboten. Das gehört so auf die 
Ketchupflaschen gedruckt und die Leute die Ketchup kaufen müssen das vor 
einer berechtigten Person eidesstattlich erklären. Jedes Mal! Gegen 
Gebühr!

Bei Zuwiderhandlung müssen sie sich deinen Senf 1 Monat lang anhören.

von vn nn (Gast)


Lesenswert?

Nick M. schrieb:
> Bernd K. schrieb:
>> Aber OP will C lernen!
>
> Ja, mit einem selbstgewählten Projekt. Irgendwas was ihm Spaß macht
> und bei dem er sich vor niemanden rechtfertigen muss.

Natürlich. Kann halt passieren, dass ihm dann keiner helfen will, wenn 
er auf obligatorische Probleme stößt.

Nick M. schrieb:
> Ich esse meine Leberkäsesemmeln nie mit Ketchup!
> Leberkäs mit Ketchup gehört verboten. Das gehört so auf die
> Ketchupflaschen gedruckt und die Leute die Ketchup kaufen müssen das vor
> einer berechtigten Person eidesstattlich erklären. Jedes Mal! Gegen
> Gebühr!
>
> Bei Zuwiderhandlung müssen sie sich deinen Senf 1 Monat lang anhören.

Mach dich nicht lächerlich. Also nicht noch mehr.

von cppbert (Gast)


Lesenswert?

Es gibt ja noch das "GCC IA 16 Projekt" - ist ein 6.3.x GCC der Code für 
den 8086 und höher erzeugt schön mit Segment und Offset usw.

https://github.com/tkchia/gcc-ia16

von SDL (Gast)


Lesenswert?

Nick M. schrieb:
> Er kann ja zur Übung OpenGL nachprogrammieren, nur da ist das Scheitern
> garantiert. Mit so DOS-Gedönsle im Bildschirmspeicher kommt aber auch
> ein Anfänger weiter. Jedenfalls ist die Aufgabe deutlich überschaubarer.

Klar, weil es so schwierig ist, eine Bibliothek einzubinden, die einem 
einen fertigen Framebuffer bereitstellt, quält man sich lieber mit 
Legacy-Kram herum, obwohl man noch nicht einmal die Programmiersprache 
beherrscht.

Es gibt beispielsweise zig Tutorials für SDL2 
(https://www.spieleprogrammierer.de/wiki/SDL-Tutorial), da wird sogar 
erklärt wie man Musik abspielt. Da kann man auch jede moderne IDE 
benutzen, hat jede Menge Ressourcen zur Verfügung und Debugging ist auch 
simpel. Einfacher gehts nicht...

von cppbert (Gast)


Lesenswert?

Das Blödgewäsch in diesem Forum ist manchmal echt auf sehr hohem Niveau 
- warum echauffieren sich hier so viele über seine Entscheidungen - 
lasst es doch einfach gut sein oder habt ihr ausser Gelaber einfach 
nichts zum wahren Inhalt dieses Post zu schreiben - Unglaublich -wer 
keinen Bock hat zu helfen lässt einfach die Finger von den Tasten - ist 
das soooo schwer?

von vn nn (Gast)


Lesenswert?

cppbert schrieb:
> oder habt ihr ausser Gelaber einfach
> nichts zum wahren Inhalt dieses Post zu schreiben

Und du so? Schon C und C++ auseinander halten können?

von S. R. (svenska)


Lesenswert?

cppbert schrieb:
> Es gibt ja noch das "GCC IA 16 Projekt" - ist ein 6.3.x GCC der Code für
> den 8086 und höher erzeugt schön mit Segment und Offset usw.

Und vollkommen überraschend läuft auch der nicht auf einem 8086.

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.