expertenaustausch > microsoft.* > microsoft.vc

Rudolf Meier (05.02.2009, 12:16)
Hallo zusammen

malloc und new... was der Unterschied ist, ist mir klar... aber eine kleine
Frage habe ich noch... new ruft ja den Konstruktor auf von den neuen
Elementen... daher jetzt die Frage: Gibt es einen Unterschied zwischen

malloc(23);

und

new BYTE[23];

?? ... ist eines zu bevorzugen oder ist das exakt genau das gleiche? ...
gibt's überhaupt einen Konstruktor für ein BYTE? ... ist eines effizienter
als das andere? ... ich tippe mal auf malloc, weil new intern auf malloc
zurückgreift, was 2 calls zur Folge hat gegenüber einem einzelnen... aber
verliere ich Flexibilität? ... :-) ... ok, ist vielleicht spitzfindig die
Frage...

Gruss
Rudolf
Karsten Schulz (05.02.2009, 12:27)
Hallo Rudolf,

>>malloc(23);
>>und
>>new BYTE[23];


es ist identisch, will man einen Constructor ausführen geht auch das mit dem
Preacessor von new, genannt (Placement New) das sieht dann so aus:

BYTE tmp[4711];

typedef class Test
{
public:
Test(){m_leer=4711;}

int m_leer;
}TEST;

TEST *tst = (TEST *)&tmp[0];
new(tst)TEST();//placement new

oder auch tst->Test(); // ist aber nur mit jammer zu ertragen

printf("%d",tst->m_leer);

gruß
Karsten Schulz

"Rudolf Meier" <meiru> schrieb im Newsbeitrag
news:1252
[..]
Ulrich Eckhardt (05.02.2009, 12:53)
Rudolf Meier wrote:
> malloc und new... was der Unterschied ist, ist mir klar... aber eine
> kleine Frage habe ich noch... new ruft ja den Konstruktor auf von den
> neuen Elementen... daher jetzt die Frage: Gibt es einen Unterschied
> zwischen
> malloc(23);
> und
> new BYTE[23];
> ?? ... ist eines zu bevorzugen oder ist das exakt genau das gleiche?


Beide sind zu vermeiden, std::vector<BYTE> ist das Mittel der Wahl.

> gibt's überhaupt einen Konstruktor für ein BYTE?


Nein.

> ... ist eines effizienter als das andere? ... ich tippe mal auf malloc,
> weil new intern auf malloc zurückgreift, was 2 calls zur Folge hat
> gegenüber einem einzelnen...


Richtig. std::vector initialisiert sogar mit BYTE(), was ein garantiertes
Null ergibt. Aber, kannst Du den Unterschied auch messen? Ich vermute in
den meisten Faellen ist der so klein dass es keinen wirklichen Unterschied
macht.

> aber verliere ich Flexibilität?


std::vector raubt Dir ein paar Moeglichkeiten Fehler zu machen. ;)

Uli
Volker Bartheld (05.02.2009, 13:01)
Servus!

> [Unterschied zwischen]
> malloc(23);
> und
> new BYTE[23];
> ?? ... ist eines zu bevorzugen oder ist das exakt genau das gleiche? ...
> gibt's überhaupt einen Konstruktor für ein BYTE? ... ist eines effizienter
> als das andere? ... ich tippe mal auf malloc, weil new intern auf malloc
> zurückgreift, was 2 calls zur Folge hat gegenüber einem einzelnen... aber
> verliere ich Flexibilität?


Wenn Du wirklich dynamisch allozieren mußt (und die STL Dir mit ihren
containern std::string, std::vector, std::list, ... aus irgendwelchen
Gründen nicht genügt), dann würde ich new verwenden - einfach weil es
automatisch die richtige Speichergröße alloziert (malloc(23) sollte
eigentlich malloc(23*sizeof(BYTE)) heißen), den Konstruktor aufruft und
bei delete/delete[] eben auch den *Destruktor* der Elemente - was bei
komplexeren Objekten durchaus hilfreich ist.

Den Performanceunterschied kannst Du quasi in der Pfeife rauchen (schreib
lieber performante Algorithmen) außer Du hast vor, in GB-großen Blöcken
(womöglich als MMF) mit einem Numercruncher herumzutoben. Dann kann sich
eine Performanceanalyse wie die obige evtl. lohnen - selbst da hätte ich
aber meine Zweifel.

2ct,
Volker
Karsten Schulz (05.02.2009, 14:04)
> Beide sind zu vermeiden, std::vector<BYTE> ist das Mittel der Wahl.

LOL

"Ulrich Eckhardt" <eckhardt> schrieb im Newsbeitrag
news:fln1
[..]
Ulrich Eckhardt (05.02.2009, 15:14)
Karsten Schulz wrote:
>> Beide sind zu vermeiden, std::vector<BYTE> ist das Mittel der Wahl.

> LOL


"The wise programmer is told about Tao and follows it. The average
programmer is told about Tao and searches for it. The foolish programmer is
told about Tao and laughs at it."

'nuff said.
Rudolf Meier (05.02.2009, 16:39)
Kleine Episode aus dem Altag eines Programmierers bei uns...

Er war immer der Meinung, dass Standard-Libraries gut sind und man die
verwenden soll, so oft es geht... die sind optimiert, schnell, fehlerfrei,
sagte er.
Dann kamen wir an einen Punkt, an dem wir nicht sicher waren, auf welche Art
ein Problem gelöst werden soll. Deshalb entschieden wir uns für eine Art
Wettbewerb. Er arbeitete mit den Standard Libraries... als wir das Zeug
gegeneinander antretten liessen... oh welche Wunder... seine Ausführung
dauerte ca. 3 mal so lange wie die andere... Grund? Eine Klasse der Standard
Libraries, die er verwendet hatte (scheinbar brauchte die über 30 mal so
lange wie das Konkurrenzprodukt unseres Programmierers)... dann
programmierte er die in 10 Minuten selber und siehe da... seine Ehre war
gerettet, aber seither verwendet er keine Standard Libraries mehr... :-)

Gruss
Rudolf

"Ulrich Eckhardt" <eckhardt> schrieb im Newsbeitrag
news:gln1
[..]
Christoph Conrad (05.02.2009, 17:41)
Hallo Rudolf,

* Rudolf Meier <meiru> schrieb:

> Kleine Episode aus dem Altag eines Programmierers bei uns...
> [...]
> aber seither verwendet er keine Standard Libraries mehr... :-)


Ich nehme an, Du leitest daraus keine allgemeine Empfehlung her, keine
Standardlibraries zu verwenden. Geschwindigkeit ist nicht alles,
Robustheit und Ausgereiftheit zählen ebenso. Und das spricht
normalerweise sehr für Standardlibraries, genauso wie Wartbarkeit bei
wechselnden oder mehreren Programmierern an einem Projekt.

Auch eine Anekdote: In einer früheren Firma wurde ausgiebig in einem
Projekt die STL von MSVC++ 6 verwendet. Die ist bekanntermassen sehr
buggy. Nach einigem Profilen und Optimieren konnte sowohl der
Speicherplatzverbrauch der Anwendung deutlich verringert wie die
Geschwindigkeit und Stabilität beträchtlich erhöht werden.

In derselben Zeit wäre niemals mit dem gleichen Aufwand zumindest der
Teil der STL neu kodiert worden, der verwendet wurde.

Freundliche Grüße,
Christoph
Volker Bartheld (05.02.2009, 19:04)
Hi!

On Thu, 5 Feb 2009 15:39:34 +0100, Rudolf Meier wrote:
> Er arbeitete mit den Standard Libraries... als wir das Zeug
> gegeneinander antretten liessen... oh welche Wunder... seine Ausführung
> dauerte ca. 3 mal so lange wie die andere... Grund? Eine Klasse der Standard
> Libraries


Und was genau willst Du uns damit bedeuten? Daß man lieber
void MachGross1(unsigned char* p)
{
while(*p) *p=toupper(*p);
}
als
void MachGross2(std::string& s)
{
std::transform(s.begin(), s.end(), s.begin(), (int(*)(int)) toupper);
}
verwenden sollte?

Laß es mich mal ganz offen sagen: Ein Faktor 3 (wenn es ihn denn gibt),
wäre mir - aus Sicht eines Entwicklers - wohl einigermaßen schnurz,
angesichts der Gefahr von irgendwelchen Overflows und anderen Lustigkeiten,
die ich potentiell aus Code entfernen müßte. Code von Leuten, die mit
Pointerjongliererei, malloc(), memcpy() & Co. einen Geschwindigkeitsvorteil
erreichen wollten. Und dem User ist es spätestens dann ebenfalls Banane,
wenn er zum x-ten Mal seine Daten neu eingeben muß, weil die Applikation
abgeraucht ist.

Aber das wird akademisch. Keiner empfiehlt Dir, das Datenmanagement einer
HDV-Schnittumgebung mit STL-Strings zu coden.

> dann programmierte er die in 10 Minuten selber


Jupp. Insbesondere so Dinge wie std::vector, std::queue, std::map,
std::iostream, ... hat man in 10 Minuten locker hingerotzt. Und genau das
ist das Produkt dann auch wert. Mit genau diesem NIH [1] Approach eines
belarussischen Entwicklers (der seinen Code so cool und selbsterklärend
fand, daß er über Seiten unkommentiert blieb) darf ich mich aktuell
herumstressen. Besten Dank dafür.

> und siehe da... seine Ehre war
> gerettet, aber seither verwendet er keine Standard Libraries mehr... :-)


[X] Daumen hoch. Ganz toll.

Ciao,
Volker

[1]
Christoph Conrad (05.02.2009, 22:23)
Hallo Volker,

* Volker Bartheld <dr_versaeg> schrieb:

> eines belarussischen Entwicklers (der seinen Code so cool und
> selbsterklärend fand, daß er über Seiten unkommentiert blieb) darf ich
> mich aktuell herumstressen. Besten Dank dafür.


Kenn ich auch, mein Beileid. Eine Anekdote: Vor zwanzig Jahren besuchte
ich eine Firma, die einen Entwickler für einen damals sehr erfolgreichen
schnellen Basic-Interpreter suchte. Dieses Produkt hatte genau eine
Person in Assembler entwickelt. Ohne einen Blick in den Quellcode wollte
ich nicht zusagen. Seitenweise kaum dokumentierter Assemblercode. Nö,
bin ich wieder gefahren.

Freundliche Grüße,
Christoph
Eberhard Schefold (06.02.2009, 21:17)
Rudolf Meier wrote:

> siehe da... seine Ehre war gerettet, aber seither verwendet er keine
> Standard Libraries mehr... :-)


Und die Ausführungsgeschwindigkeit ist, wie jeder gute Entwickler weiß,
das einzige Kriterium für guten Code. Ob die entsprechende Stelle
überhaupt performancekritisch ist, ist ohne Belang. Der gute Entwickler
ignoriert Überlegungen zu Robustheit, Pflegbarkeit, Selbstdokumentation,
Allgemeinverständlichkeit, Verläßlichkeit, Testbarkeit; kurzgesagt
jegliche ökonomische Überlegungen über die Produktzyklen hinweg sind zu
unterlassen. Hauptsache, der Code ist SCHNELL, koste es, was es wolle.
Und wenn jemand mit einer bestimmten Bibliothek in einem Fall weniger
SCHNELLEN Code hergestellt hat, ist diese Bibliothek damit grundsätzlich
weniger SCHNELL und sollte nicht verwendet werden. Das selbst erfundene
Rad ist immer SCHNELLER und daher grundsätzlich besser.
Rudolf Meier (07.02.2009, 01:21)
> Und die Ausführungsgeschwindigkeit ist, wie jeder gute Entwickler weiß,
> das einzige Kriterium für guten Code. Ob die entsprechende Stelle
> überhaupt performancekritisch ist, ist ohne Belang. Der gute Entwickler


na ja, 's hatte mit Caching zu tun... ist das performancekritisch genug?

> ignoriert Überlegungen zu Robustheit, Pflegbarkeit, Selbstdokumentation,
> Allgemeinverständlichkeit, Verläßlichkeit, Testbarkeit; kurzgesagt
> jegliche ökonomische Überlegungen über die Produktzyklen hinweg sind zu


hat das jemand gesagt?

> unterlassen. Hauptsache, der Code ist SCHNELL, koste es, was es wolle.


nein, nicht so ganz... aber, wenn ich das Zeug genug vereinfacht habe... ja,
dann kann ich mir schon vorstellen, mal eine Schleife sogar in Assembler zu
schreiben... wieso auch nicht? wozu sind wir Informatiker denn da? ... und
wieso glaubt jeder, dass dies im Chaos endet? ... das Chaos kommt nicht von
der Optimierung... das Chaos kommt daher, dass man sich zu wenig Gedanken
macht über die Vereinfachung vom Code... einfach, schön und schnell, das ist
oftmals das gleiche...

> Und wenn jemand mit einer bestimmten Bibliothek in einem Fall weniger
> SCHNELLEN Code hergestellt hat, ist diese Bibliothek damit grundsätzlich
> weniger SCHNELL und sollte nicht verwendet werden. Das selbst erfundene
> Rad ist immer SCHNELLER und daher grundsätzlich besser.


na ja, bei Faktoren grösser 10 ... ja, doch... dann finde ich das schon
irgendwie besser, das selbst GEBAUTE Rad... nicht erfunden... erfunden wurde
das nicht neu... bloss mal richtig rund gebaut...

Gruss Rudolf

PS: ist mir schon klar, dass wir jetzt wieder in den Bereich
"Religionskrieg" abgedriftet sind... daher steigert euch bitte nicht so
hinein in die Sache...nehmt's locker... Hakuna Matata... und noch 'n schönen
Tag wünsche ich allen... :-)
Eberhard Schefold (07.02.2009, 10:38)
Rudolf Meier wrote:

>> Und die Ausführungsgeschwindigkeit ist, wie jeder gute Entwickler
>> weiß, das einzige Kriterium für guten Code. Ob die entsprechende
>> Stelle überhaupt performancekritisch ist, ist ohne Belang. Der gute
>> Entwickler

> na ja, 's hatte mit Caching zu tun... ist das performancekritisch genug?


Keine Ahnung. Selbst in einer "Caching"-Komponente gilt die 80/20-Regel.
Flaschenhälse können ganz verschieden ausfallen, Speichergröße, I/O,
globale Ressourcen, Synchronisationsobjekte, CPU. Ohne Messen ist da
keine Aussage möglich.

>> ignoriert Überlegungen zu Robustheit, Pflegbarkeit,
>> Selbstdokumentation, Allgemeinverständlichkeit, Verläßlichkeit,
>> Testbarkeit; kurzgesagt jegliche ökonomische Überlegungen über die
>> Produktzyklen hinweg sind zu

> hat das jemand gesagt?


Wenn besagter Entwickler wie berichtet die C++-Standardbibliothek
aufgrund dieses einen Erlebnisses grundsätzlich nicht mehr verwendet
hat, und der Rest des Teams damit bestätigt sah, was es eh immer schon
gewußt hat, gibts da noch Zweifel? Nicht "schnell" genug, also tschüß,
keine weiteren Fragen. So hast Du es erzählt.

> nein, nicht so ganz... aber, wenn ich das Zeug genug vereinfacht habe...
> ja,
> dann kann ich mir schon vorstellen, mal eine Schleife sogar in Assembler zu
> schreiben... wieso auch nicht? wozu sind wir Informatiker denn da? ... und
> wieso glaubt jeder, dass dies im Chaos endet? ... das Chaos kommt nicht von
> der Optimierung... das Chaos kommt daher, dass man sich zu wenig Gedanken
> macht über die Vereinfachung vom Code... einfach, schön und schnell, das
> ist
> oftmals das gleiche...


Wenn Ihr gemessen habt, dass fragliche Stelle einen entscheidenenden
CPU-Flaschenhals darstellt, und vor allem auch gemessen habt, dass die
Assembler-Lösung tatsächlich einen Vorteil bringt, der den höheren
Entwicklung- und Test-Aufwand, die schlechtere Verständlichkeit, Test-
und Wartbarkeit und das höhere Fehlerrisiko rechtfertigt, dann nur zu.

Derartige Fälle sind in jeder Art von Applikation aber sicherlich die
Ausnahme.

> na ja, bei Faktoren grösser 10 ... ja, doch... dann finde ich das schon
> irgendwie besser, das selbst GEBAUTE Rad... nicht erfunden... erfunden
> wurde
> das nicht neu... bloss mal richtig rund gebaut...


Als Entwickler muss ich ganz wesentlich auch ökonomisch denken. Zu
diesen Überlegungen gehört u.U. /auch/ die (gemessene, nicht die
gefühlte) CPU-Performance des Codes, aber sie ist ganz sicher nicht im
allgemeinen das wesentliche Kriterium. Ein mächtiges
Entwicklungswerkzeug wegen einer einzigen Anekdote grundsätzlich links
liegen zu lassen, und dafür prinzipiell selbstgestrickten Code zu
bevorzugen, erscheint mir sehr kurzsichtig.

Volker hat das NIH-Syndrom bereits erwähnt. Offensichtlich nicht
totzukriegen.
Martin Richter [MVP] (08.02.2009, 20:04)
Hallo Rudolf!

>> Und die Ausführungsgeschwindigkeit ist, wie jeder gute Entwickler
>> weiß, das einzige Kriterium für guten Code. Ob die entsprechende
>> Stelle überhaupt performancekritisch ist, ist ohne Belang. Der gute
>> Entwickler

> na ja, 's hatte mit Caching zu tun... ist das performancekritisch genug?


Und! Auch hier kann man genug Fehler machen. Da genügt es schonmal ein
Referenz Zeichne zu vergessen und schon hat man einen Copy Vorgang zuviel.

>> ignoriert Überlegungen zu Robustheit, Pflegbarkeit,
>> Selbstdokumentation, Allgemeinverständlichkeit, Verläßlichkeit,
>> Testbarkeit; kurzgesagt jegliche ökonomische Überlegungen über die
>> Produktzyklen hinweg sind zu

> hat das jemand gesagt?


Ja! Weil Du als Lehre ein Beispiel anwendest von einem Entwickler, der
nie weider die STL verwendet weil er evtl. bei der Nutzung der STL
selbst schon einen Fehler gemacht hat.

>> unterlassen. Hauptsache, der Code ist SCHNELL, koste es, was es wolle.

> nein, nicht so ganz... aber, wenn ich das Zeug genug vereinfacht habe...
> ja,


Und genau darin liegt das Problem: Vereinfachen kan man auf mehrere
Arten. Und das geht auch unter Verwendung von Standards.

> dann kann ich mir schon vorstellen, mal eine Schleife sogar in Assembler zu
> schreiben... wieso auch nicht? wozu sind wir Informatiker denn da? ... und
> wieso glaubt jeder, dass dies im Chaos endet? ... das Chaos kommt nicht von
> der Optimierung... das Chaos kommt daher, dass man sich zu wenig Gedanken
> macht über die Vereinfachung vom Code... einfach, schön und schnell, das
> ist
> oftmals das gleiche...


Geschwindigkeit ist nicht immer kritisch. Dieses Beispiel finde ich
dennoch auch daneben.
Mal ganz ehrlich: von 20MB Code. Wieviel schätzt Du als geschwindigkeits
kritisch ein? ;)
Sicher: "Kommt auf die Anwendung an!" Nur lehr mich meine Erfahrung: Wir
vergeuden Zeit an Stellen, an denen wir es nichtvermuten, und es ist
seltenst eine Standard-Klasse die das verursacht.

> na ja, bei Faktoren grösser 10 ... ja, doch... dann finde ich das schon
> irgendwie besser, das selbst GEBAUTE Rad... nicht erfunden... erfunden
> wurde
> das nicht neu... bloss mal richtig rund gebaut...


Ich schließe mit Dir eine Wette ab. Der Algorithmus war bzgl der STL
falsch gewählt, wenn es nur um eine Containerklasse ging.

Zugeben will ich gerne, dass I/O mit der STL lahm ist. ;)
Martin Richter [MVP] (08.02.2009, 20:07)
Hallo Eberhard!

> Volker hat das NIH-Syndrom bereits erwähnt. Offensichtlich nicht
> totzukriegen.


Es gibt noch die härtere Variante im eigenen Team:
Ich habe den Code nicht geschrieben folgerichtig
a. enthält er Fehler
b. kann er nicht gut sein
c. werde ich ihm nicht vertrauen
d. werde ich meinen eigenen Code schreiben...

;)
Ähnliche Themen