Sprachliche Unterschiede zwischen C und C++?
-
volkard schrieb:
ich erinnere nur mal an die alten nullterminierten strings. heute darf man zwei zeiger nehmen. man braucht nicht mehr im string zu hudeln, wenn man einen tokenizer baut. die ewig-lästigen aufrufe von strlen fallen weg. irgendwie ist das dichter an der maschine (am prozessor) als nullterminierte strings.
wie meinste das? irgendwie muss das ende doch erkannt werden. ob man nun eine 0 ans ende packt oder irgendwo die länge speichert. beides ist 'nah an der maschine'
btw: ein weiterer grund warum c++ auf 'embedded' nicht so beliebt ist, ist dass man dessen erweiterte features kaum einsetzen kann. so'n stl-kram der willkürlich 'new'd' und 'deleted' ist kaum zu gebrauchen auf'nem controller mit z.b. 8k ram. ausser das man variablen irgendwo hinschreiben kann und die bessere typüberprüfung von c++ hat es sonst keine vorteile gegenüber c
-
net schrieb:
ausser das man variablen irgendwo hinschreiben kann
... was in C99 auch geht (aber widerlich ist) ...
und die bessere typüberprüfung von c++ hat es sonst keine vorteile gegenüber c
Es gibt, soweit ich das jetzt überblicke, keine bessere Typenprüfung in C++.
C hat eine bewußt eingefügte Lücke -- die Geschichte, daß man einen void* an einen anderen anderen Zeiger zuweisen kann --, aber sonst?
-
net schrieb:
wie meinste das? irgendwie muss das ende doch erkannt werden. ob man nun eine 0 ans ende packt oder irgendwo die länge speichert. beides ist 'nah an der maschine'
sprach ich von anfang und länge?
ich meine anfang und ende. und ein zwei-zeiger-großes objekt wird immer übergeben, nicht mehr nur ein zeiger.btw: ein weiterer grund warum c++ auf 'embedded' nicht so beliebt ist, ist dass man dessen erweiterte features kaum einsetzen kann. so'n stl-kram der willkürlich 'new'd' und 'deleted' ist kaum zu gebrauchen auf'nem controller mit z.b. 8k ram. ausser das man variablen irgendwo hinschreiben kann und die bessere typüberprüfung von c++ hat es sonst keine vorteile gegenüber c
reicht das nicht? und den embedded-programmier-sklaven sagt man, sie sollen code bauen, der euf embedded system gut rennt.
es wird dort nur deswegen kein c++ eingesetzt, weil die chefs gar keine ahnung haben, was c++ ist. daß man da nicht std::string nehmenb MUSS, ist nämlich mein geheimnis.
-
Das Beziehen der Adresse hat absolut nichts mit einer Referenz zu tun!
-
volkard schrieb:
net schrieb:
wie meinste das? irgendwie muss das ende doch erkannt werden. ob man nun eine 0 ans ende packt oder irgendwo die länge speichert. beides ist 'nah an der maschine'
sprach ich von anfang und länge?
ich meine anfang und ende. und ein zwei-zeiger-großes objekt wird immer übergeben, nicht mehr nur ein zeiger.naja, da nehm ich doch besser einen pointer und eine längenangabe (int). ist in vielen fällen irgendwie sparsamer und 'maschinennäher' als 2 pointers
-
net schrieb:
naja, da nehm ich doch besser einen pointer und eine längenangabe (int). ist in vielen fällen irgendwie sparsamer und 'maschinennäher' als 2 pointers
und übergibst auch 2*sizeof(void*)? dann isses recht egal, was man nimmt.
-
volkard schrieb:
net schrieb:
naja, da nehm ich doch besser einen pointer und eine längenangabe (int). ist in vielen fällen irgendwie sparsamer und 'maschinennäher' als 2 pointers
und übergibst auch 2*sizeof(void*)?...
wozu sollte ich?
btw: auch wenn man's mal gebrauchen könnte, muss man '2*sizeof(void*)' nicht übergeben, weils konstant ist
-
net schrieb:
eine längenangabe (int)
dafür gibt es doch size_t
bzw. std::size_t, wenn wir schon bei C und C++ unterschieden sind 
-
net schrieb:
wozu sollte ich?
weil's einfach schneller ist, du weihnachtsmann. stell dir vor, du mappst ein file ins ram, macht davon mit nem tokenizer lauter zeilen, machst aus den zeilen mit noch nem tokenizer key-value-paare. ist ein string durch anfangs- und ende-zeiger oder anfang und länge gegeben, geht das ganz harmonisch ohne einmal daten der datei kopieren zu müssen.
btw: auch wenn man's mal gebrauchen könnte, muss man '2*sizeof(void*)' nicht übergeben, weils konstant ist
ach, red einfach nicht mit.
-
kingruedi schrieb:
net schrieb:
eine längenangabe (int)
dafür gibt es doch size_t
bzw. std::size_t, wenn wir schon bei C und C++ unterschieden sind klar, aber size_t ist manchmal richtig gross. wenn man nur kurze strings hat kann man auch 'ne ein-byte-längenangabe nehmen. dagegen spricht wieder, dass ints oft von der maschine einfacher verarbeitet werden können als bytes. egal wie man's macht - es ist immer nur ein kompromiss
volkard schrieb:
ach, red einfach nicht mit.
und du formulier' mal nicht so'n kauderwelsch. bei deinen texten muss man manchmal echt raten was du meinst...
-
net schrieb:
klar, aber size_t ist manchmal richtig gross.
Woah, das ist so groß, wie es für die Maschine gerade passt und bei einem 8Bit - Mikrocontroller ist es auch nicht 512 Bit groß. Außerdem wird das ganze Zeugs eh aligned, bei nem Array sparst du vielleicht was mit nem kleineren Typ, das halte ich aber für eher unwahrscheinlich für ne lokale oder Membervariable.
Am Ende braucht es doch wieder so viel Platz wie size_t und muss aber nach jeder arithmetischen Operation abgeschnitten werden.
-
Optimizer schrieb:
net schrieb:
klar, aber size_t ist manchmal richtig gross.
Woah, das ist so groß, wie es für die Maschine gerade passt und bei einem 8Bit - Mikrocontroller ist es auch nicht 512 Bit groß.
Aber 16
Programmier mal den 8051 in Assembler, dann lernst du diesen Unterschied kennen
-
Gibt es in C++ eigentlich _irgendein_ System bei den Größen der verschiedenen Typen?
-
Jo.
1 Byte <= char <= short <= int <= long
int >= 16 Bit
long >= 32 Bit
-
Michael E. schrieb:
Jo.
1 Byte <= char <= short <= int <= long
int >= 16 Bit
long >= 32 BitWobei char = 1Byte, denn ein Byte ist die in C++ zugrunde liegende Speicher-
einheit und ein char der kleinste adressierbare Typ.Wieviel Bits ein Byte hat, ist allerdings nicht spezifiziert.
mfg
v R
-
Na, das kenn ich auch. Das kann aber (fast) _alles_ bedeuten. Sollte jetzt auch nicht so furchtbar ernstgemeint sein, wie man an den Smileys möglicherweise erkennen kann.
Wenn ich weiß, welchen Code mein Compiler für meine Plattform erzeugt, ist mir der Rest herzlich egal. Ich finde die Spezifikation halt Unsinn (man beachte nur mal "von -127 bis +127"). Es gibt zu wenige Dinge, auf die man sich hier verlassen kann (z.B. wie ne Division abzulaufen hat). Aber damit will ich jetzt nicht weiter anfangen, ignoriert mich einfach.
-
Ohne diesen "Unsinn" wär es unmöglich, C effizient auf einem System mit Einerkomplementdarstellung zu implementieren.
-
volkard schrieb:
es wird dort nur deswegen kein c++ eingesetzt, weil die chefs gar keine ahnung haben, was c++ ist. daß man da nicht std::string nehmenb MUSS, ist nämlich mein geheimnis.
Jetzt nicht mehr.
net schrieb:
klar, aber size_t ist manchmal richtig gross
IdR nicht. Da size_t sozusagen das unsigned Gegenstück zu ptrdiff_t ist, kann man davon ausgehen, dass size_t nicht mehr Speicher braucht als ein Zeiger.
-
groovemaster schrieb:
net schrieb:
klar, aber size_t ist manchmal richtig gross
IdR nicht. Da size_t sozusagen das unsigned Gegenstück zu ptrdiff_t ist, kann man davon ausgehen, dass size_t nicht mehr Speicher braucht als ein Zeiger.
das meinte ich mit 'richtig gross' (sorry, ich drücke mich nicht immer so klar aus).
-
Woher weisst du bei einer Laengenangabe eigentlich, wieviel Bytes du nun
interpretieren musst, um die Laengenangabe korrekt interpretieren zu koennen? Oder
willst du dafuer auch noch eine Angabe vorsehen?mfg
v R