mikrocontroller.net

Forum: PC-Programmierung Wo wird physikalisch new und malloc gespeichert


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Kadse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

ich habe hier ( https://www.geeksforgeeks.org/malloc-vs-new/ ) gelesen, 
dass bei Malloc auf dem Heap gespeichert wird.
Sprich also auf dem RAM.

Bei new wird auf den "free store" gespeichert. Wo liegt dieser dann?

Gruß
Kadse

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kadse schrieb:
> Bei new wird auf den "free store" gespeichert. Wo liegt dieser dann?

Druckfehler. Beides landet auf dem Heap, irgendwo im Innern von new 
werkelt unter der Haube auch ein malloc()

Autor: Bonzo N. (jetztnicht)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Malloc und New sind eigentlich daselbe. Nur ist bei New ein Typ 
implizit, waehrend bei Malloc nach Byte Groessen alloziert wird. 
Bedeutet, Malloc ist einen Level tiefer wie New.

Autor: Michael B. (laberkopp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bonzo N. schrieb:
> Malloc und New sind eigentlich daselbe.

Na ja, new ruft halt, nach dem malloc der Klassenstruktur, sämtliche 
Konstruktoren auf (und delete vor dem free sämtliche Destruktoren).

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bonzo N. schrieb:
> Malloc und New sind eigentlich daselbe. Nur ist bei New ein Typ
> implizit, waehrend bei Malloc nach Byte Groessen alloziert wird.

Wenn man das Frontend von new betrachtet.  Das "Backend" von new kann 
man selbt implementieren, in dem man operator new überlädt:
void* operator new (size_t);
void* operator new[] (size_t);

Dies geht auch innerhalb einer Klasse, so dass klassenlokal spezielle 
Aktionen erfolgen können (das static ist implizit).
class A
{
    static void* operator new (size_t s)
    {
        // Do some magic
        return ::operator new (s);
    }
};

Und für delete:
void operator delete (void*);
void operator delete[] (void*);

: Bearbeitet durch User
Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Es ist zwar gängige Praxis, aber new muss nicht zwingend auf malloc
aufbauen, weswegen sich beide auch nicht zwingend aus demselben
Memory-Pool bedienen müssen. Die explizite Unterscheidung dieser Pools
in "Heap" und "Free Store" scheint auf Herb Sutter zurückzugehen:

  http://www.gotw.ca/gotw/009.htm

Um die eigentliche Frage zu beantworten: Physikalisch liegen natürlich
beide (wie auch Stack und Global/Static) im RAM.

Autor: nfet (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Um die eigentliche Frage zu beantworten: Physikalisch liegen natürlich
> beide (wie auch Stack und Global/Static) im RAM.

Naja, also um genau zu sein, kann man das im Linkerscript einstellen.

Autor: nfet (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh voreilig veröffentlicht.
Mir viel ein, dass nicht das Linkerscript allein verantwortlich ist, 
sondern die Implementierung von new daran natürlich einen noch größeren 
Anteil hat.
Und auch das Betriebssystem kann noch am wo herum pfuschen. Ebenso, wie 
die Hardware selbst. Durchaus denkbar ist, dass der Heap deines 
Programms den Cache des Prozessors niemals verlässt.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"free store" ist eine Bezeichnung, die im C++-Standard verwendet wird 
für den Bereich, der für new verwendet wird. "heap" ist weder in C, noch 
in C++ ein offizieller Begriff für einen Speicherbereich. Diese 
Bezeichnung kommt eher aus den Implementierungen der Sprache. Der 
Bereich für malloc() hat in C keinen speziellen Namen, soweit ich weiß. 
Das Wort "heap" kommt im C-Standard nicht vor.
In der Praxis hängt es vom Compiler ab.

Autor: Michael B. (laberkopp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nfet schrieb:
> Oh voreilig veröffentlicht.
> Mir viel ein, dass nicht das Linkerscript allein verantwortlich ist,
> sondern die Implementierung von new daran natürlich einen noch größeren
> Anteil hat.
> Und auch das Betriebssystem kann noch am wo herum pfuschen. Ebenso, wie
> die Hardware selbst. Durchaus denkbar ist, dass der Heap deines
> Programms den Cache des Prozessors niemals verlässt.

Ach wie schrecklich...

Auch malloc und der Stack sind genau so betroffen, das ist also keine 
Auszeichnung speziell für new.

Autor: georg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nfet schrieb:
> Physikalisch liegen natürlich
>> beide (wie auch Stack und Global/Static) im RAM.
>
> Naja, also um genau zu sein, kann man das im Linkerscript einstellen.

Welchen Sinn sollte es denn haben, mit new reservierten Speicher im ROM 
anzusiedeln?

Georg

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
georg schrieb:
> Welchen Sinn sollte es denn haben, mit new reservierten Speicher im ROM
> anzusiedeln?

Keinen. Trotzdem kann man im Linkerskript einstellen, wo dieser 
Speicherbereich liegen soll.

Autor: Frank O. (fop)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf M. schrieb:
> georg schrieb:
>> Welchen Sinn sollte es denn haben, mit new reservierten Speicher im ROM
>> anzusiedeln?
>
> Keinen. Trotzdem kann man im Linkerskript einstellen, wo dieser
> Speicherbereich liegen soll.

Oder wie mein Kollege immer gerne sagt : Kannste so machen, aber dann 
wird's halt Kacke.

Beitrag #5899852 wurde von einem Moderator gelöscht.
Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach Leute, wieso versteift ihr euch so auf die Idee, den Speicherbereich 
für malloc in den ROM zu legen, nur um dann zu postulieren, dass das 
unsinnig ist. Das ist sicherlich jedem hier klar.
Im Linkerskript ist einstellbar, wo im Adressraum verschiedene 
Speicherbereiche - darunter auch der/die für malloc und new liegen. Das 
hat erstmal überhaupt nichts damit zu tun, ob das nun ROM oder RAM ist. 
Damit wäre theoretisch auch möglich, das in den ROM zu legen, was aber 
in der Praxis natürlich keiner macht. Ein Tool wird nicht unsinnig, nur 
weil es theoretisch auch möglich wäre, damit unsinnige Dinge zu tun.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.