array = array ??
-
eben
-
Im Gegensatz zu einer Schleife?
Nein. Im Gegensatz zu std::memcpy. Aber danke der Nachfrage.
Aber ich habe ja diese sinnlose Abstraktion von strlen, strcpy, copy & Friends noch nie verstanden ... und das ist mein voller Ernst.
Naja, wäre die Abstraktion sinnlos, würde ich sie wohl auch nicht verstehen. Da sie das aber nicht ist...
Aber nach dieser Aussage ist jede weitere Diskussion irgendwie sinnlos. Man braucht ja schließlich irgendeinen gemeinsamen Einstiegspunkt.
-
Was heißt eigentlich "intrinsic"???
-
@MaSTaH
Darf ich dich an die Erfindung des Wörterbuchs erinnern?intrinsic - inner, immanent, innerhalb
immanent - einbegriffen, innewohnend
-
Original erstellt von HumeSikkins:
Darf ich dich an die Erfindung des Wörterbuchs erinnern?Darfst du
. Ich hab es hier im Forum das erste Mal gehört und dachte es sei irgendein Fachbegriff... Deswegen habe ich es nicht im Wörterbuch nachgeschlagen.
-
Original erstellt von MaSTaH:
Deswegen habe ich es nicht im Wörterbuch nachgeschlagen.*grml*
wenigstens googlen könnte man
-
Hab ich doch, aber der hat nur Mist gefunden. Erst dann habe ich gefragt...
-
-
Ich hab aber nur den Begriff ohne Functions eingegeben, daran lag es dass er nur Mist gegoogled hat
-
//keine Schleife, kein memcpy, kein std::copy template <class T,int S>struct StructWithOnlyArray{T array[S];}; #define COPY(src,dst,cnt) new(dst)StructWithOnlyArray<typeof(*dst),cnt>(*(StructWithOnlyArray<typeof(*src),cnt>*)src);[ Dieser Beitrag wurde am 22.03.2003 um 12:18 Uhr von klausmuell editiert. ]
-
das geht aber nur auf gcc und intern wird da sowieso so was wie memcpy benutzt
-
Original erstellt von Dimah:
das geht aber nur auf gcc und intern wird da sowieso so was wie memcpy benutztes wird genau das optimale verwendet. bei kleinen arrays ein paar direkte zuweisungen, bei größeren memcpy, aber wenn nichttriviale kopiersemantik vorliegt ne schleife mit copy-ctor, und das alles kostenlos und ohne schlimme #includes und mit voller compilermagie.
-
Naja, jedem das seine
-
Original erstellt von klausmuell:
bei kleinen arrays ein paar direkte zuweisungen, bei größeren memcpy, aber wenn nichttriviale kopiersemantik vorliegt ne schleife mit copy-ctor, und das alles kostenlos und ohne schlimme #includes und mit voller compilermagie.Erstens sind Templates nie kostenlos (so wie das bei vielen Compilern implementiert ist), zweitens trift der Compiler für mich fragwürdige Entscheidungen über mein Programm ohne Kenntnis der Umgebung (Wann ist den ein Array klein?), drittens habe ich eine natürliche Abneigung gegenüber magischen Vorlängen und zum Vierten braucht man beim GCC den Header <new> und die einzig mir bekannte Möglichkeit den einzubinden ist #include.
Original erstellt von HumeSikkins:
Naja, wäre die Abstraktion sinnlos, würde ich sie wohl auch nicht verstehen. Da sie das aber nicht ist...Eine komplizierte Lösung mit redundanten Details ist immer schlechter als eine Direkte Klare Einfache. Das finde ich zumindest einleuchtend, aber alle moderen Bücher die sich mit OOP und OOD beschäftigen erzählen mir fortwährend das Gegenteil.
-
erstens ist das forum buggy, weil es nur den text nach dem letzten quote quotet, statt alles ungeuotete.
zweitens ist es buggy, weil es mir beim registrieren nicht den benutzernamen Klaus gegeben hat, sondern meinen login, weil Klaus weg war und ich nun nicht selber zu Klausi oder so wechseln kann.Erstens sind Templates nie kostenlos (so wie das bei vielen Compilern implementiert ist),
also laufzeitkosten haben sie schonmal nicht.
zweitens trift der Compiler für mich fragwürdige Entscheidungen über mein Programm ohne Kenntnis der Umgebung (Wann ist den ein Array klein?),
wer sollte diese entscheidungen denn sonst treffen? die lib weiß ja nichtmal, auf welchen prozessor der code optimiert werden soll und ob du kleinen oder schnellen code haben willst.
drittens habe ich eine natürliche Abneigung gegenüber magischen Vorlängen
freust dich aber über ein intrinsic memcpy? memcpy ist bereits magisch und macht bei kleinen arrays und bekannter fester größe ne zuweisung, später evtl nur repne mov und noch später total tolle auf bestes alignment hin getrimmte duff-devices?
und zum Vierten braucht man beim GCC den Header <new> und die einzig mir bekannte Möglichkeit den einzubinden ist #include.
ok, das placement new. normalerweise ist eh was schon eingebunden, das wiederum <new> einband. aber wenn ichs mal brauche und nicht inkludieren mag, ich glaube, dies muss da stehen:
inline void* operator new(size_t,void* p){return p;}
-
Original erstellt von klausmuell:
zweitens ist es buggy, weil es mir beim registrieren nicht den benutzernamen Klaus gegeben hat, sondern meinen login, weil Klaus weg war und ich nun nicht selber zu Klausi oder so wechseln kann.Schreib ne Mail an Marc++us er kann sicherlich deinen nick ändern.
-
inline void* operator new(size_t,void* p){return p;}
Wofür du wiederum einen der Header einbinden musst, die size_t definieren
Ist aber auch egal. Solange in dem Code ein typeof steht und solange Standard-C++ kein typeof kennt, ist der Code hier sowieso falsch.Eine komplizierte Lösung mit redundanten Details ist immer schlechter als eine Direkte Klare Einfache. Das finde ich zumindest einleuchtend, aber alle moderen Bücher die sich mit OOP und OOD beschäftigen erzählen mir fortwährend das Gegenteil.
Tut mir leid ich kann dir nicht folgen. Ich sehe beim Besten Willen nicht was das mit OOP und OOD zu tun haben soll. Selbst gute Bücher von 1970 (da gab es meines Wissens noch keinen OOP-Hype) sagen: "Duplication is the root of all evil". Und 250-mal die selbe Schleife in einem Programm zu schreiben ist definitiv "duplication". Länger, fehleranfälliger, schlechter wartbar (da weniger kommunikativ) als eine simple Funktion.
Nicht nur, dass eine Schleife keine High-Level-Semantik besitzt, sie wird auch natürlich nicht nach einer solchen geprüft.
Also habe ich strcpy vielleicht 249mal richtig und einmal falsch implementiert. Toll. Passiert dir vielleicht nicht, mir schon.[ Dieser Beitrag wurde am 22.03.2003 um 18:12 Uhr von HumeSikkins editiert. ]
-
Original erstellt von HumeSikkins:
Selbst gute Bücher von 1970 (da gab es meines Wissens noch keinen OOP-Hype) sagen: "Duplication is the root of all evil". Und 250-mal die selbe Schleife in einem Programm zu schreiben ist definitiv "duplication". Länger, fehleranfälliger, schlechter wartbar (da weniger kommunikativ) als eine simple Funktion.Es ist weniger fehleranfällig Code in Funktionen zu schreiben, als anderswohin? Code wir besser wartbar, wenn ich ihn in eine Funktion packe? Und kürzer wird es auch noch? Ungeheuer praktisch solche Funktionen. WashatdasdenmitdemThemazutundasichangesprochenhatte?
Eine Lösung, die komplexer ist als sie sein müsste ist schlecht, können wir uns darauf einigen? Ein so seltenes Problem wie strcpy oder copy braucht man aber vielleicht 2x pro Projekt (ich habe hier man einige Quelltexte analysiert und von einigen wenigen Menschen, die »strcpy(dst, "")« schreiben, abgesehen kam strcpy 50 mal in ~78000 Zeilen Code vor. Verteilt auf die 10 Projekte bleiben 5 strcpy-Aufrufe pro Projekt, die ich aber hier nur in 2 Projekten wiederfinde.) So etwas ist ist überflüssig, weil 'normale' C++-Programme ungefähr nur aus for-Schleifen bestehen. Der aufmerksame Leser stellt fest, dass for also häufig getippt wird und erkennt die 'Duplicaltion'?
Original erstellt von klausmuell:
[Templates]
also laufzeitkosten haben sie schonmal nicht.Ja. Aber abgefahrene Compile-Zeiten, bei mir bekannten Compilern.
wer sollte diese entscheidungen denn sonst treffen?
Jemand der das Problem kennt. Also der Programmierer.
memcpy [...] macht bei kleinen arrays und bekannter fester größe ne zuweisung, später evtl nur repne mov und noch später total tolle auf bestes alignment hin getrimmte duff-devices?
Das ist mir egal. Wenn es darauf ankommt, dann sollte man das Programm direkt in Asm hacken.
-
Es ist weniger fehleranfällig Code in Funktionen zu schreiben, als anderswohin?
Aber 100%tig. Den Code für eine Funktion schreibe ich *einmal* und nicht tausendmal an zweihundert verschiedenen Stellen. Eine Funktion ist auch leichter zu testen als keine Funktion. Auch das reduziert die Wahrscheinlichkeit von Fehlern.
Code wir besser wartbar, wenn ich ihn in eine Funktion packe?
Aber 100%tig. Code wird übersichtlicher, leichter verständlich, kommunikativer.
Und kürzer wird es auch noch?
Ist das eine Art Quiz? Ich würde mal sagen, dass Code in den meisten Fällen durch die Verwendung von Funktionen kürzer wird. Vorallem, da ein Funktionsaufruf in einer Sprache wie C++ auf Quellcodeebene keinen wirklichen overhead hat.
Eine Lösung, die komplexer ist als sie sein müsste ist schlecht, können wir uns darauf einigen?
Keine Ahnung. Wohl eher nicht. Denn eine Lösung die für dich komplexer ist, scheint für mich *deutlich* einfacher und bestimmt gibt es auch Situationen wo dies genau andersherum ist.
Das ist genau der Grund, weshalb ich eine Diskussion für sinnlos halte. Ich kann mich in dieser Sache mit dir auf keinen gemeinsamen Ausgangspunkt einigen. Das Funktionen sinnvoll sind ist für mich so in Steingemeißelt, wie es die zehn Gebote einmal waren. Mein Geist ist nicht flexibel genug, als das ich da über Alternativen nachdenken könnte. Und mit jedem weiterem Buch über Softwaredesign/technik das ich lese wird mein Geist in dieser Richtung unflexibler.
[ Dieser Beitrag wurde am 22.03.2003 um 20:29 Uhr von HumeSikkins editiert. ]
-
Jemand der das Problem kennt. Also der Programmierer.
hmm in der regel wird der compiler trozdem mehr ahnung von optimierung haben als der programmierer selbst...
was auf nem intel x86 system gross ist ist vielleicht auf nem Vektorrechner garnimmer so gross und dann weis der entsprechende compiler sicher besser was zu tun ist als ich...