PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Explizite Typumwandlung in C++


aths
2003-03-10, 11:53:02
Grundsätzlich lehne ich C ja ab (wohingegen C++ imo die einzig wirklich brauchbare Programmiersprache ist, leider kann ich sie kaum) aber was mir an C gefällt ist das implizite Typecasting. Wieso wurde das eigentlich nicht in C++ übernommen?

Demirug
2003-03-10, 12:03:31
Man kann mit C++ die gleiche Typecast spiele wie in C machen und sich damit genauso gut in den Fuss schiessen (selbst schon oft genug gemacht).

Oder um hier mal jemanden zu zitieren:

Mit C ist es einfach sich in den Fuss zu schiessen. Mit C++ ist schon schwieriger aber wenn man es schaft ist das ganze Bein weg.

GloomY
2003-03-10, 12:22:02
Was ist an der impliziten Typenkonvertierung so schlecht?

Hier auch noch mal ein schönes Zitat: ;)
The C language is like a carving knife: simple, sharp, and extremely useful in skilled hands. Like any sharp tool, C can injure people who don’t know how to handle it.

Demirug
2003-03-10, 12:35:22
Originally posted by GloomY
Was ist an der impliziten Typenkonvertierung so schlecht?

Die implizite ist in der Regel problemlos kann aber auch schon mal probleme mache deswegen mag ich es schon wenn mich mein Compiler darauf hinweist wenn ich durch diese Typenkonvertierung an Genauigkeit verliere. Die Typekonvertierungen in einer Klassenhirachie sind dagegen eigentlich immer Problemloss.

Gefährlich sind ja auch eher die expliziten Typenumwandlungen die man leider viel zu oft einsetzten muss.

x-dragon
2003-03-10, 12:42:06
Kann ich mal eben kurz eine Erläuterung für die unterschiedlichen Begrifflichkeiten der Typenkonvertierung haben (implizit/explizit)?

Mit C funktioniert ist es wahrscheinlich etwas anders als mit Delphi, aber vielleicht kann ich ja trotzdem was damit anfangen :).

zeckensack
2003-03-10, 13:36:18
Originally posted by GloomY
Was ist an der impliziten Typenkonvertierung so schlecht?
Sie läuft automatisch und macht nicht immer das was man will ;)

http://www.forum-3dcenter.org/vbulletin/showthread.php?postid=647704#post647704
Originally posted by zeckensack
*jaul*

Es war im Endeffekt der implizite Konvertierungs-Operator. Der Compiler hat sich netterweise bei der Arithmetik öfter mal dazu entschieden, alles nach double zu konvertieren, anstatt umgekert mit voller Präzision zu arbeiten :bad1:

Mit 'implizit' meinte ich in diesem Fall, daß ich meiner Klasse einen Operator gegeben habe, mit dem der Compiler sie nach Bedarf automatisch in einen Basistyp umwandeln kann.

Das schreibt man zB alsclass
Something
{
public:
double operator double() {return(<...>); }
};
Dadurch wird folgender Code legal:
Something s;
double d=s; //automatische Typkonvertierung, ruft 's.operator double()' auf

'Explizit' sind die Fälle, wo man selbst einen cast machen muß, entweder mit einem C-Cast, einem der neuen C++ casts, oder (jedenfalls sehe ich persönlich das so), oder mit einem Member wie diesemclass
Something
{
public:
//der hier muß direkt aufgerufen werden, der Compiler 'findet' ihn nicht automatisch
double to_double() { return(<...>); }
};

x-dragon
2003-03-10, 16:26:59
Ah ja danke.

Wie schön das mir solche Probleme in Delphi noch nicht untergekommen sind. Naja mathematische Berechnungen halten sich bei meinen Programmen auch in Grenzen :).

liquid
2003-04-20, 21:14:12
*thread ausgrab*

Jetzt versucht man mal seinen Code etwas C++ konformer zu gestalten und was passiert? Man kriegt die dummen (aber halt nötigen) C-Typecasts net weg.

const char* const temp = static_cast<const char*>(glGetString(GL_EXTENSIONS));
const std::string extension_string(temp);

Also mir ist bekannt, dass glGetString immer ein C-Array mit GLubyte Elementen liefert. Alles schön und gut. Aber warum lässt sich dann nicht ganz einfach static_cast benutzen um das Array in char Form zu bringen? Ich meine die Datentypen sind verwandt. Das sind beides ein Byte Datentypen. Na gut, das GLubyte-Vieh ist unsigned, aber wen stört es? Anscheinend den Compiler, der meckert nämlich darüber, dass ich casten will.

Da bleibt mir eigentlich nur die Holzhammermethode C-Casting oder halt reinterpret_cast, und der Junge ist auch nicht besser. Geht das vielleicht auch irgendwie eleganter oder sollte ich lieber bei den stinknormalen C-Casts bleiben und mir die Arbeit mit den C++ cast Operatoren sparen?

cya
liquid

Demirug
2003-04-20, 21:28:54
OpenGL ist eben eine C API also geht man da auch mit C Verfahren ran.

grakaman
2003-04-21, 01:01:31
Originally posted by X-Dragon
Kann ich mal eben kurz eine Erläuterung für die unterschiedlichen Begrifflichkeiten der Typenkonvertierung haben (implizit/explizit)?

Mit C funktioniert ist es wahrscheinlich etwas anders als mit Delphi, aber vielleicht kann ich ja trotzdem was damit anfangen :).

Bei der impliziten Konvertierung wird quasi ein kleiner Wertebereich zu einen größeren konvertiert, was ja nicht schlimm ist, z.B. wenn du einen float einen integer zuweist. Umgedreht würde das aber Datenverlust heissen und der Compiler würde eine Fehlermeldung bringen. Mit dem Cast sagst Du deshalb explizit den Compiler, dass du weisst was du machst und es beabsichtigt ist.

MfG

aths
2003-04-21, 03:15:12
Originally posted by Demirug
OpenGL ist eben eine C API also geht man da auch mit C Verfahren ran. OT: Wir haben in diesem Semester "System- und Netzwerkschnittstellen" inkl. Systemprogrammierung in C.

Warum zum Teufel wurde dieser Irrweg nicht längst verlassen, warum nimmt man nicht längst C++? Da wird stur an irgendwelchen Dingen festhalten mit dem Argument "das war früher auch so".

Demirug
2003-04-21, 09:05:50
Originally posted by aths
OT: Wir haben in diesem Semester "System- und Netzwerkschnittstellen" inkl. Systemprogrammierung in C.

Warum zum Teufel wurde dieser Irrweg nicht längst verlassen, warum nimmt man nicht längst C++? Da wird stur an irgendwelchen Dingen festhalten mit dem Argument "das war früher auch so".

Es gibt eben noch unmengen von C Code da drausen. Zudem gibt es leider immer noch erhebliche Probleme in verbindung mit C++ und DLLs. Dazu kommen dann noch die alten Vorurteile wie C++ ist langsam und man kann keine Systemsoftware in C++ schreiben.

zeckensack
2003-04-21, 15:04:29
Originally posted by aths
OT: Wir haben in diesem Semester "System- und Netzwerkschnittstellen" inkl. Systemprogrammierung in C.

Warum zum Teufel wurde dieser Irrweg nicht längst verlassen, warum nimmt man nicht längst C++? Da wird stur an irgendwelchen Dingen festhalten mit dem Argument "das war früher auch so". Ich schließe mich Demirug hier nicht unbedingt an ...

C ist eine der wenigen Sprachen mit sauber definierter 'Linkage', dh daß C-Module sauber in allen Programmen eingebunden werden können.

Eine DLL die C++-Symbole exportiert (Klassen, pipapo) ist normalerweise nur mit dem gleichen Compiler wieder zu verwenden.

Siehe brot_core.dll. Wäre das C++, und hätte ich die DLL mit MSVC kompiliert, dann müßte der Client in MSVC geschrieben werden. Nichts anderes würde überhaupt funktionieren.
Mit C-Linkage kann ich erstens GCC und MSVC bunt mischen, und habe zweitens die Option auf in anderen Sprachen geschriebene Clients.
(wäre ich total wahnsinnig, könnte ich auch die DLL in Delphi implementieren, ohne den Client nochmal anfassen zu müssen)

Der Grund für diesen 'Wahnsinn' ist daß es keine einheitlichen Standards zu 'name decoration' in Verbindung mit Klassen gibt.

Eine (stdcall-)C-Funktion wird mit einem führenden Unterstrich, und am Ende einem '@' und der Größe (in Bytes) der Parameterliste dekoriert.

int __stdcall some_function(float a,int b);
=>
_some_function@8

Bei C++ funzt das nicht mehr, weil sich mit diesem einfachen Verfahren überladene Funktionen und Default-Argumente nicht mehr zufriedenstellend darstellen lassen. MSVC hängt an Klassenfunktionen eine Art Hash an (der einem MS-Produkt-Key recht ähnlich sieht). GCC habe ich mir noch nicht dahingehend angeschaut.

Demirug
2003-04-21, 15:21:27
zeckensack, was habe ich den anderes gesagt?

Zudem gibt es leider immer noch erhebliche Probleme in verbindung mit C++ und DLLs

Dein Post ist doch die ausführliche Erklärung dieses Problems.

Deswegen braucht ein modernes OOP System auch Metadata.

Exxtreme
2003-04-21, 15:41:59
Originally posted by aths
OT: Wir haben in diesem Semester "System- und Netzwerkschnittstellen" inkl. Systemprogrammierung in C.

Warum zum Teufel wurde dieser Irrweg nicht längst verlassen, warum nimmt man nicht längst C++? Da wird stur an irgendwelchen Dingen festhalten mit dem Argument "das war früher auch so".
Hmm, also C finde ich gar nicht so schlecht. Man kann damit hocheffizienten und schlanken Code erzeugen. Diese Programmiersprache ist und bleibt aber nur für Leute, die wissen was sie tun. Man kann damit ziemlich viel Mist bauen. WinDOS9x habe ich damit durch diverse Bugs schon oft abgeschossen. :)

Was ich noch an C gut finde, daß man tatsächlich sieht, wie der Computer den Code tatsächlich verarbeitet, da C nicht besonders abstrakt ist.

zeckensack
2003-04-21, 15:53:52
Originally posted by Demirug
zeckensack, was habe ich den anderes gesagt?



Dein Post ist doch die ausführliche Erklärung dieses Problems.

Deswegen braucht ein modernes OOP System auch Metadata. Das habe ich unglücklich formuliert :)
Wir sind uns natürlich in diesem Punkt einig.

Wo ich nicht mitgehe, sind die Punkte "Vorurteile gegen C++" und "Unmengen von C-Code da draußen". Das mag beides stimmen, aber es sind IMO in diesem Zusammenhang keine Argumente für C - allenfalls sind es schlechte Ausreden ;)
Die Linker-Probleme sind meiner Ansicht nach der einzige relevante Grund.

Demirug
2003-04-21, 16:06:37
Originally posted by zeckensack
Das habe ich unglücklich formuliert :)
Wir sind uns natürlich in diesem Punkt einig.

Wo ich nicht mitgehe, sind die Punkte "Vorurteile gegen C++" und "Unmengen von C-Code da draußen". Das mag beides stimmen, aber es sind IMO in diesem Zusammenhang keine Argumente für C - allenfalls sind es schlechte Ausreden ;)
Die Linker-Probleme sind meiner Ansicht nach der einzige relevante Grund.

Es ging mir auch nicht darum Argumente für C zu suchen ich bin ja selbst kein Freund davon sonder darum was von den Verfechtern von C gerne ins Feld geführt wird.

Und gerade "C++ ist zu langsam" musste ich mir schon sehr oft anhören. Ich kenne aber auch noch die Variante "C ist zu langsam". Die neusten Formen sind jetzt "Java ist zu langsam" und "C# ist zu langsam".

Aber das Linker Problem ist wie du schon sagst das grösste. Unter W32 löst man das mehr oder weniger elegant mit COM.

Die Linker sache ist übrigens einer der Punkte warum ich .Net so mag. Keine Linker probleme mehr, was ich private mache bleibt auch private und solange ich die Finger von den offentlichen Methoden lassen kann ich meine Klassen so oft umbauen wie ich möchte.

Demirug
2003-04-21, 16:13:59
Originally posted by Exxtreme

Hmm, also C finde ich gar nicht so schlecht. Man kann damit hocheffizienten und schlanken Code erzeugen. Diese Programmiersprache ist und bleibt aber nur für Leute, die wissen was sie tun. Man kann damit ziemlich viel Mist bauen. WinDOS9x habe ich damit durch diverse Bugs schon oft abgeschossen. :)

Also mit C++ geht das alles genausogut. Es gibt aber beispiele wo man sich mit C ein Bein ausreisen muss um die gleiche Effizienz zu erreichen wie mit C++.

Was ich noch an C gut finde, daß man tatsächlich sieht, wie der Computer den Code tatsächlich verarbeitet, da C nicht besonders abstrakt ist.

Wenn du sehen willst was der Computer macht musst du Assembler programmieren. Was moderne C/C++ Compiler so alles mit dem Code anstellen ist nicht mehr schön. Aus dieser Sicht ist C schon sehr abstrakt.

Grosse Projekte in reinem C sind einfach ein Alptraum aus diesem Grund hat man ja auch irgendwann angefangen mit Abstrakten Datentypen (ADT) zu arbeiten um die Übersicht nicht ganz zu verlieren.

peecee
2003-04-22, 18:20:50
Hi

Ich glaube die GNOME Leute haben sich eine Art Objekt Orientiertes System in C gebastelt.
Ist das mit ADT gemeint ?
Wie kann man sich so was vorstellen ?

mfg

Demirug
2003-04-22, 18:52:52
ADT ist eine Art vorläufer der moderen OOP welche mit jeder Prozeduaralen Programmiersprache einsetzbar ist.

Zuerst definiert man sich die Datentypen (in C structs) die man benötigt und mit Zeigertype dafür.



typedef void* DATE;

type struct _date
{
int jahr;
char monat;
char tag;
} date



Dann programmiert man eine Rheie von erzeugungsfunktionen

z.b:


DATE Date_Create (int jahr, char monat, char tag)
{
// Speicher anlegen und init
}


Eine Lösch Funktion


void Date_Delete (DATE this)
{
}


Zugriffsfunktionen:


void Date_Set_Year (DATE this, int year);
int Date_Get_Year (DATE this);


Operatoren


boolean Date_Equal (DATE Left, DATE right);


und was man sonst noch so braucht.

Eine erweiterte Version von ADT beschribt dann sogar noch wie man Vererbung und virtuelle Funktionen bauen kann.

Der erste C++ "Compiler" hat im Prinzip nichts anderes gemacht als erweiterten ADT sourcecode zu erzeugen welcher dann durch einen normalen C Compiler gejagt wurde.

Chris Lux
2003-04-25, 08:08:57
ich erweitere mal demirugs posting:

ADT = abstrakter datentyp (ausgesprochen gibt das schon viel auskunft was es ist ;))