Funktionen und...

HumeSikkins

@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.

PAD

@_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 25

Diesem 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.

Walli

@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.

PAD

@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).

Walli

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 ).

Shade Of Mine

PAD schrieb:

Dies ist entnommen dem Buch
C++ entpackt
Herbert Schildt
mitp-Verlag
ISBN3-8266-0731-7
Seite 25

Diesem 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++);
  }
}

PAD

@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.

Shade Of Mine

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#SchildtAny

schildt 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

PAD

@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.

Shade Of Mine

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)

Daniel E.

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.

PAD

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

Shade Of Mine

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.

CarstenJ

Bist du der Meinung, dass man beide Sprachen nicht parallel nutzen kann?

Shade Of Mine

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.

PAD

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ügung

Es 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

Shade Of Mine

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.

PAD

Ich meinte damit nicht den eigentlichen Funktionsaufruf sondern eher was passieret wenn ich eine Instanz eines Objects erzeuge, das Durchlaufen der zugehörigen Klasenhierachie bis ich den engültigen Konstruktor gefunden habe, das erkennen der richtigen überladenen Funktion und ähnliche Punkte. Die höhere Abstraction hat definitiv eine Auswrikung auf die zeitliche Leistungsfähigkeit des Systems, wegen des höheren Verwaltugsaufwandes.
Das wird in der allgemeinen Programmierung bei weitem nicht so ins Gewicht fallen wie bei hardwarenaher Pogrammierung.

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.

Das ist der Punkt den ich anzweifele, speziell da du ja selber sagst, das jeder C++ Programmierer das bestätigt.

Wie sieht es bei denen aus die von C kommen, sagen die das gleiche?
Was sagen Leute die sich damit beschäftigen und keinem der beiden Lager angehören?

HumeSikkins

das erkennen der richtigen überladenen Funktion und ähnliche Punkte.

class Bar {};
int  foo(int);
char foo(Bar b);

template <bool b> struct static_assert;
template <> struct static_assert<true>{};

int main()
{
static_assert<sizeof(foo(Bar())) == sizeof(int)> s;
}

Na, fällt dir vielleicht was auf?
Macht keinen Sinn, deine Aussage.

wenn ich eine Instanz eines Objects erzeuge, das Durchlaufen der zugehörigen Klasenhierachie bis ich den engültigen Konstruktor gefunden habe

Da nicht gesucht werden muss, dauerts auch nicht bis gefunden wird. Wenn du natürlich tiefe Hierarchien und Objekten mit nicht trivialen Konstruktoren hast, werden dementsprechend viele Konstruktoren aufgerufen. Nur vergleichst du jetzt schon wieder Birnen mit Orangen. Ist ja nicht so, dass C++ Vererbung erzwingen würde. Und wenn es sinn macht eine Hierarchie zu basteln, dann wirst du im C Programm eine ähnliche Komplexität haben und auch dort wirst du an irgendeinem Punkt Daten initialisieren müssen.

Die höhere Abstraction hat definitiv eine Auswrikung auf die zeitliche Leistungsfähigkeit des Systems, wegen des höheren Verwaltugsaufwandes.

Käse. Erstens gibt es keine inhärent höhere Abstraktion und zweiten führt Abstraktion in C++ nicht automatisch zu Geschwindigkeitseinbußen.