C: Fragen zu memset, memcpy, malloc

[Sisor]

Das ist wohl richtig. Für c++ würde ich Makros auch nicht empfehlen.
Hier mal ein Auszug aus dem Arduino-Kern. Implementation von new und delete [new.cpp]:

#include <stdlib.h>

void *operator new(size_t size) {
  return malloc(size);
}

void *operator new[](size_t size) {
  return malloc(size);
}

void operator delete(void * ptr) {
  free(ptr);
}

void operator delete[](void * ptr) {
  free(ptr);
}

[Mxt]

Das sind spezielle Überladungen, die kommen bei normalem Anfordern von Speicher nicht zum Einsatz. Es handelt sich um sowas hier:
https://en.wikipedia.org/wiki/Placement_syntax

Man kann in C++ ja sowas machen

    #include <new>        // Must #include this to use "placement new"
    #include "Fred.h"     // Declaration of class Fred
    void someCode()
    {
      char memory[sizeof(Fred)];     // Line #1
      void* place = memory;          // Line #2
      Fred* f = new(place) Fred();   // Line #3 (see "DANGER" below)
      // The pointers f and place will be equal
      // ...
    }

das ist eine andere Baustelle.


Im übrigen ist es meist so, dass new und delete auf malloc und free zurückgreifen, oder auf die Betriebssystemfunktionen die diesese beiden verwenden.

Aber new und delete rufen auch Konstruktor und Destruktor der angelegten Objekte auf. Ein malloc würde nur Speicher anfordern, das Objekt darin aber nicht initialisieren. Ein free auf etwas mit new angefordertem würde einem Objekt den Speicher klauen, läuft doch später noch der Destruktor knallt es, usw.

[Sisor]

Interessant, schaue ich mir demnächst mal genauer an...

[Mxt]

Wichtig für dich ist nur, dass du dann auch wirklich C machst. Also einen C-Compiler verwenden und mit *.c Codedateien arbeiten.

C++ ist (und war immer) nur eine Schnittmenge zu C, es ist kein größeres C. Es gibt Sachen, die sind in C und C++ anders.

[HaWe]

das geht leider nicht:
in Arduino habe ich gar keinen Einfluss drauf (ist immer gpp) und auf den Raspi portiert auch nicht immer (wenn Fremd-Libs C++ verwenden, muss ich auch g++ verwenden, ansonsten nutze ich GCC beim Pi ntl wo immer es geht.

Meinen eigenen Code schreibe ich immer nur in ANSI C Syntax, das ist einfach clean + straight sozusagen.

[botty]

HaWe, das Du nur C++ in der Arduino IDE benutzen kannst ist nur bedingt richtig.
Der Sketch wird durch den eigenen Präprozessor gejagt und dann das CPP-File durch den (kastrierten) g++.
Wenn Du aber eine "*.c"-Datei dem Projekt hinzufügst, dann wird diese mit dem GCC und nicht dem g++ kompiliert. Bei *.cc *.cpp vice versa.
Dementsprechend müssen dann die Header "extern "C" { ... }" oder auch nicht enthalten, sonst produziert der Linker freudig Fehlermeldungen.

Gruß

[HaWe]

aha, wieder etwas schlauer geworden - so in die Tiefen und Untiefen der Arduino-IDE bin ich gar nicht vorgedrungen, ich nutze einfach die Standard-Libs (egal welcher Code, ich guck auch normalerweise nicht nach C oder C++ da drin - viele verwenden allerdings C++, das sieht man ja schon an Serial, Wire und SPI.
Auch .c Dateien schließe ich nicht ein, sondern ganz einfach nur 1 .ino Code - und soweit es mein eigener ist, verwende ich hier kein C++, sonden nur C code (plus Serial.print etc, Wire.begin etc., und die ganzen anderen unvermeidbaren automatisch eigebundenen Sketch-Klassen).

[Peter(TOO)]

Wenn Du aber eine "*.c"-Datei dem Projekt hinzufügst, dann wird diese mit dem GCC und nicht dem g++ kompiliert. Bei *.cc *.cpp vice versa.
Dementsprechend müssen dann die Header "extern "C" { ... }" oder auch nicht enthalten, sonst produziert der Linker freudig Fehlermeldungen.

Ein Unterschied zwischen C und C++ liegt darin, dass C die Namen für Funktionen direkt aus dem Quelltext übernimmt.
C++ erzeugt decoratet Labels, an den Funktionsnamen werden einfach noch Buchstaben angehängt, welche die Aufruf-Parameter angeben. Dadurch werden überladene Funktionen für den Linker unterschiedlich. Man braucht also keinen speziellen Linker für C++.

Zudem war C++ ursprünglich eigentlich nur eine Art Preprozessor. Ein C++-Programm wurde in ein C-Programm umgesetzt, welches dann mit dem C-Compiler übersetzt wurde.

MfG Peter(TOO)

[Wsk8]

genau so ist es (beide arrays sind eigentlich gleich groß) -
perfekt, danke!

nun noch eine allerletzte Frage, ebenfalls wieder zu memset:

für den Fall, dass ich meinen dynamischen buf initialisieren will mit 128 statt mit 0, dann wäre doch vermutlich dieser Befehl dann auch richtig...

memset( buf, 128, arrlen*sizeof(int16_t) );

...

Nur wenn du in JEDES Byte 128 schreiben willst. Wenn du in jedes Feld (2 Byte <-> int16) 128 schreiben willst, funktioniert das nicht mehr!

Und der Rückgabewert von malloc() wird für gewöhnlich nicht gecastet. http://stackoverflow.com/questions/6...sult-of-malloc

mfg

[HaWe]

stimmt, ich meinte eigentlich: in jedes int-Feld 128 reinschreiben -
ich war der Meinung durch den Parameter
arrlen*sizeof(int16_t)
würde memset automatisch "arrlen" mal den Wert 128 einfügen.
Gibt es denn eine schnelle Methode, alle Felder mit 128 zu füllen, außer einzeln, iterativ?

mit dem gecastet meintest du doch
(int16_t *) malloc ....
oder?
das hatte ich aus einer malloc Funktions-Definition ...:
http://www.cplusplus.com/reference/cstdlib/malloc/
(siehe Anwendungsbeispiel weiter unten mit (char *)malloc ! )