Funktionen und...
-
PAD schrieb:
Un da C++ zum ersten komplett auf C aufbaut, dürfte das nicht zur Sinnlosigkeit führen
Das ist kein Argument. C++ ist mit C so verwandt wie Kuchen mit Brötchen!
-
PAD schrieb:
Wenn ich sicherstellen will das der übergebene Paramter nich verändert werden kann mach das mehr als Sinn.
Schau dir im klassischen C mal die functionchar *strcpy( char *strDestination, const char *strSource );
an da sieht man deutlich wan es sinn macht einen paramter als const zu deklarieren
Un da C++ zum ersten komplett auf C aufbaut, dürfte das nicht zur Sinnlosigkeit führen
Hier gehts doch um Call per Value. Bei Zeigern kann ein const natürlich sehr förderlich sein wie Deine aufgeführte Funktion zeigt.
-
@PAD
Super. Vergleicht man erstmal Äpfel mit Elefanten, dann kann man natürlich zu ganz lustigen Ergebnissen kommen.char *strcpy( char *strDestination, const char *strSource );
Fein, nur wir reden hier von der Konstrukten wie:
char *strcpy( const char* strDestination, const char* const strSource );
Der *Pointer* wird per value übergeben. Die zusätzliche const-Deklaration des
*Pointers* ist also überflüssig und verwirrend.
Die const-Deklaration des *Pointees* hat mit der Diskussion überhaupt nichts zu tun.
-
Ich deklariere auch nur Parameter die ich byRef übergebe als const. Ich seh auch keinen Sinn darin, normale Parameter als const festzulegen.
-
@_red das Stücken Code war so unvollständig, das ich es fehlinterpretiert habe. Bei Call by Value ist das nicht nötig
@MaSTaH
Das ist kein Argument. C++ ist mit C so verwandt wie Kuchen mit Brötchen!
Wie Sie vielleicht wissen, baut C++ auf der Grundlage C auf. Tatsächlich enthält C++ die gesamte Sprache C,
und alle C-Programme sind (mit wenigen Aussnahmen) auch C++ Programme. Bei der Entwicklung von C++ diente
die Sprache C als Ausgangspunkt, dem einige neue Strukturen und Erweiterungen hinzugefüg wurden, die das
objektorientierte Programmieren (OOP) unterstützen sollten. Dennoch wurden die C-artigen Aspekte von C++
niemals abgeschft, und der ANSI/ISO Standardist das Basisdokument für C++.
Um C++ zu verstehen,müssen Sie daher zuerst einaml C verstehen.Dies ist entnommen dem Buch
C++ entpackt
Herbert Schildt
mitp-Verlag
ISBN3-8266-0731-7
Seite 25Diesem Text und seiner Meinung schließe ich mich voll an.
Herbert Schildt war/ist Mitglied des/der ANSI/ISO Komitees die C und C++ standardisiert haben.
@HumeSikkins Mir ist mehrfach folgendes pasiiert
int funca(char *a,char *p) { while (*p !=0) *s++=to_upper(*p++); }
Das anschliesend p auf das Ende vom String zeigte und nicht mehr auf den Anfang (und das bei unterschiedlichen Compilern) deswegen ist mit das const wichtig, denn dann passiert so was nicht.
-
@PAD: Da redet doch keiner von. C ist sicher der "Vorgänger" (wenn man es so nennen will) von C++ aber deine Begründung war einfach nur schlapp. Es macht Sinn weil es in C auch so gemacht wurde? Ich benutze auch kein malloc mehr weil es in C so gemacht wurde.
-
@MaSTaH
Ich glaube du hast den Inhalt des Textes nicht richtig verstanden, C und C++ sind derselbe Teig um in deiner Sprechweise zu bleiben。Interessant ist auch deine Ablehnung von C, die ich nicht verstehen kann. Sie ist mir allerdings in vielen Aritkeln unf Büchern begegnet die sich speziell auf den jeweils neuesten Hype werfen und nur noch das gut finden.
ich habe inzwischen gelernt, das nicht alles ''alte'' unbedingt schlecht ist, und je mehr ich von C++ verstehe desto mehr fließt davon auch in meinen Beruf ein. Denoch bei Systemen die ein sinnvolles Realtimeverhalten haben sollen und mit Hardware kommunizieren sind die Methoden der sich C++ bedient manchmal von ihrem zeitlichen Ablauf
nicht nachvollziehbar (speziell nicht wiederholbar).
-
Worüber redest du eigentlich? Ich lehne weder C ab noch stürze ich mich auf die neuesten Hypes und finde alles alte schlecht. Ich wollte dir nur klar machen, dass man C und C++ nicht in einen Topf werfen kann weil es zwei völlig verschiedene Sprachen sind. C++ programmiert man anders als C (von einigen Leuten vielleicht abgesehen ).
-
PAD schrieb:
Dies ist entnommen dem Buch
C++ entpackt
Herbert Schildt
mitp-Verlag
ISBN3-8266-0731-7
Seite 25Diesem Text und seiner Meinung schließe ich mich voll an.
Herbert Schildt war/ist Mitglied des/der ANSI/ISO Komitees die C und C++ standardisiert haben.
Aeh... ich wuerde Schildt nicht zitieren - das kommt nicht gut
@HumeSikkins Mir ist mehrfach folgendes pasiiert
int funca(char *a,char *p) { while (*p !=0) *s++=to_upper(*p++); }
Das anschliesend p auf das Ende vom String zeigte und nicht mehr auf den Anfang (und das bei unterschiedlichen Compilern) deswegen ist mit das const wichtig, denn dann passiert so was nicht.
ein syntax fehler?
ja, sowas passiert mir auch manchmal...ne, mal im ernst.
jetzt stell dir vor du haettest folgendes gemeint:void funca(char* const a, char const* const p) { while(*p) { *a++=to_upper(*p++); } }
dann waere das const zuviel... denn dann muesste man es so schreiben:
void funca(char* const a, char const* const p) { char* t1=a; char const* t2=p; while(*t2) { *t1++=to_upper(*t2++); } }
ne, ne, ne
da schreib ichs lieber so:void funca(char* a, char const* p) { while(*p) { *a++=to_upper(*p++); } }
-
@Shade Of Mine
Aeh... ich wuerde Schildt nicht zitieren - das kommt nicht gut
Warum nicht?
Zu deiner Lösung, das letzte Codestück wäre ja meine richtige Lösung.
Ich hatte meine Funktion ohne das const geschrieben um auf das mögliche Problem hinzuweisen.
Die Stücke dazwischen sind mir unverständlich.
Syntaxfehler kommen meistens, wenn man etwas schreibt ohne es zu testen und ich hatte es nur hier runtergeschrieben.
-
char const* p;
und
int const i;sind nicht aequivalent. (Begruendung: siehe Humes Post auf seite 1)
wenn du das gelesen hast, sollte mein beitrag auch klar sein.
Zu Schildt:
siehe zB:
http://www.cs.technion.ac.il/users/yechiel/CS/BadBooksC+C++.html#SchildtAnyschildt hat keinen guten ruf in der C/C++ Community
irgendwo im usenet habe ich auch mal gelesen
'woran erkennt man einen c lamer?'
daran, dass er Schildt Buecher empfiehlt
-
@Shade Of Mine
Danke für die Information.
Habe gerade oben genanntes Buch gelesen und fand es nicht schlecht.
Besonders die Evolution aus dem C heraus und der Übergang zu C++ ist gut herausgearbeitet. Hat sehr viel mit meinem realen Arbeitsumfeld zu tun.Was ist die ACCU (die Page habe ich schon besucht), was für einen Ruf hat die?
Wer ist Francis Glassborow und was ist seine Qualifikation?Interessanterweise hat Schildt an beiden Standards aktiv mitgearbeitet, was für eine gewisse Qualifikation sprechen sollte.
Ich kann mir allerdings sehr gut vorstellen das sein evolutiuonärer Ansatz vielen C++ Gurus aufstößt.
Was nicht OOP ist kann nicht sein oder ähnliches, hab solches von etlichen gehört die im Studium stehen, oder gerade fertig waren.
Sie mußten dann aber feststellen das sie nicht alleine auf einer grünen Wiese standen und alles neu erfinden konnten. Sobald dann die Zusammenarbeit mit bestehenden SW-Teilen kam haben einige kläglich versagt, weil sie zwar das hohe Lied singen konnten, aber der Bezug zum Boden völlig fehlte.PS: Der Hinweis auf Seite 1 war gut.
-
PAD schrieb:
@Shade Of Mine
Interessanterweise hat Schildt an beiden Standards aktiv mitgearbeitet, was für eine gewisse Qualifikation sprechen sollte.was du mit ACCU meinst ist mir nicht klar.
ich meinte den weiterfuehrenden link auf
http://www.faqs.org/faqs/C-faq/learn/16: Why do many experts not think very highly of Herbert Schildt's
books?Ich kann mir allerdings sehr gut vorstellen das sein evolutiuonärer Ansatz vielen C++ Gurus aufstößt.
evolutionaer?
nein.der weg ueber C zu C++ ist nicht evolutionaer sondern mies.
der umnstieg von C auf C++ ist recht schwer, deshalb ist es bloedsinn zuerst C zu lernen um dann C++ zu lernen.glaub mir, ich habe das durchgemacht und kann immer noch kein ordentliches C++
evolutionaer soll Accelerated C++ - das geht einen neuen weg (und nicht den ganz alten)
-
PAD schrieb:
Interessanterweise hat Schildt an beiden Standards aktiv mitgearbeitet, was für eine gewisse Qualifikation sprechen sollte.
Wobei man 'aktiv mitgearbeitet' als 'hat für seinen Platz im Komitee bezahlt, war aber nie anwesend' lesen muss.
-
Durch deinen Link bin ich da gelandet
http://www.accu.org/bookreviews/public/reviews/t/t001453.htm
Ich muß halt den miesen Weg gehen, da ich schon länger im Geschäft bin als es C++ gibt, und meine Arbeiten typischerweise harwarenah sind.
Das der Umstieg von prozudural nach OOP nich einfach ist, ist offensichtlich
-
PAD schrieb:
Durch deinen Link bin ich da gelandet
http://www.accu.org/bookreviews/public/reviews/t/t001453.htm
ne, ich meinte den link der da drueber stand.
Herbert Schildt: Any Book on C or C++ .
Ich muß halt den miesen Weg gehen, da ich schon länger im Geschäft bin als es C++ gibt, und meine Arbeiten typischerweise harwarenah sind.
Punkt 1 ist klar, Punkt 2 musst du mir erklaeren.
warum kann man C++ nicht hardware nahe einsetzen?Das der Umstieg von prozudural nach OOP nich einfach ist, ist offensichtlich
eben. deswegen sollte man nicht unnoetigerweise C vor C++ lernen.
-
Bist du der Meinung, dass man beide Sprachen nicht parallel nutzen kann?
-
CarstenJ schrieb:
Bist du der Meinung, dass man beide Sprachen nicht parallel nutzen kann?
was heisst parallel?
gleichzeitig in einem projekt: nein (dh, können schon, ist aber mies)
gleichzeitig in 2 verschiedenen projekten: durchaus möglich wenn man bei 2 projekten den überblick behalten kann.
gleichzeitig lernen: ne, da kommt man nur durcheinander.das problem ist:
C und C++ sind verschiedene sprachen, doch leider ist die syntax identisch und teilweise die library, das macht es schwer diese beiden sprachen voneinader zu trennen.
-
Ich nutze beide Sprachen parallel. Der derzeitige Schwerpunkt ist C.
Alle alten Projeke werden in C bleiben und für die nächsten 10-20 Jahre auch in C gewartet
Aktuelle Projekte werden in einem Mischmasch erstellt (siehe unten).
Neue Projekte hoffe ich dann vielleicht reinrassig in C++ zu erstellen, falls es Sinn macht.Da ich mit einer Gruppe von Programmieren arbeite, muß ich erst dafür sorgen das wir alle auf einem Stand sind
(das wird noch etwas dauern).Momentan nutzen wir die reine C-Syntax, allerdings haben jetzt schon die Files die Endung cpp, so das sie mit dem C++-Compiler übersetzt werden.
Die Libraries die ich zur Verfügung stelle sind derzeit großteils in C, bestehende Libraries werden auch nicht umgestellt.
An den Stellen an denen mir die Objekt Orientierierung jetzt schon sinnvoll erscheint, stelle ich die Libraries als C++ zur VerfügungEs stimmt schon die beiden grundlegen Denkweisen von C (procedural) und C++ (Objekt orientiert) sind sehr verschieden, ich meine aber das man bei Testständen das beste aus beiden Welten nehmen kann.
warum kann man C++ nicht hardware nahe einsetzen?
Durch die Methodik die in C++ eingesetzt wird ist imho zum einen der Overhead pro Funktion größer
und zweitens glaube ich das zeitverhalten nicht so eindeutig wie in C ist. Ich lasse mich aber gerne vom Gegenteil überzeugen.eben. deswegen sollte man nicht unnoetigerweise C vor C++ lernen.
Deinem unnötigerweise wiederspreche ich.
Erstens, ich programmiere schon langer als es C++ gibt (das ist abe Nebensache)
Zweitens bin ich der Auffassung das nur wenn man beide Ansätze beherrst (oder zumindest kennt) die bessere Entscheidung trifft bei der Softwareanalyse. Man sollte erst dann Fahrrad fahren lernen wenn man laufen kann.
Drittens In meinem Arbeitsbereich arbeiten wir teilweise noch bis aud Assemblerebene, un da gibts keine Objekt orientierung.Dazu habe ich mich schon einmal ausgelssen unter http://www.c-plusplus.net/forum/viewtopic.php?t=43273 Seite 5
-
C++ hat bei einer Funktion sicher keinen Overhead gegenueber C
uU machen schlechte compiler mit objekten langsameren code als ohne - kann ich leider nicht beurteilen da ich nur Compiler fuer einen PC kenne.
Wenn man C schon kann, kann man es logischerweise vorher nicht verlernen bevor man C++ lernt.
aber wenn man kein C kann, dann ist es nicht sinnvoll zuerst C zu lernen und dann erst C++.
das wird dir nahezu jeder C++ Programmierer bestaetigen koennen.