Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

VisualC++: Viele Fehler in System Dateien

Werbeanzeige

jokester

Treue Seele

Beiträge: 125

Wohnort: Mainz

  • Private Nachricht senden

31

25.06.2010, 22:47

Nur nebenbei: C kann unter gewissen Umständen auch langsamer als C++ sein. Allbekanntes Beispiel: Cs qsort vs. C++s std::sort. std::sort kann wegen templates statt function-pointer das Sortierkriterium inlinen.
"There is a theory which states that if ever anyone discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable. There is another theory which states that this has already happened" -- Douglas Adams.

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

32

25.06.2010, 22:51

Das C schneller wäre als C++ ist ein Mythos. Fakt ist dass du mit C++ genau gleich maschinennah programmieren kannst wie mit C. Abgesehen davon bietet C++ Dinge wie z.B. templates die im Endeffekt zu saubererem und auch schnellerem Code führen.
m4studios

Tobiking

1x Rätselkönig

Beiträge: 1 231

  • Private Nachricht senden

33

25.06.2010, 23:16

Man muss im Prinzip bei beiden Sprachen überlegen wie man etwas am performantesten Implementiert. Bei C++ gibt es viele Sprachfeatures, die keinerlei Overhead erzeugen, da sie statisch zur Compile ausgewertet werden können. Stroustrup geht da in seinem Buch auch oft drauf ein. Templates sind da ein gutes Beispiel, da diese wirklich komplett statisch ausgewertet werden, und zu keinerlei Overhead führen. Aber auch einfache Vererbung erzeugt keinen Overhead. Erst wenn man virtuelle Funktionen hat werden Funktionspointer eingesetzt, die einen Overhead erzeugen.

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

34

25.06.2010, 23:28

Templates sind aber natürlich kein Allheilmittel und können, falsch eingesetzt auch zu extremem codebloat führen und sich damit negativ auf die Performance auswirken.
m4studios

storage

Treue Seele

Beiträge: 138

Wohnort: Bad Salzungen

  • Private Nachricht senden

35

26.06.2010, 02:01

@Tobi

heisst das, dass abstrakte Klassen overhead erzeugen? Wenn ja welche alternativen gibt es?

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

36

26.06.2010, 02:17

Ja virtuelle Methoden haben einen kleinen Overhead. Meistens ist der aber vernachlässigbar.
Außerdem ist dieser Overhead konzeptioneller Natur und nicht wirklich verursacht durch C++. Z.B. in C würde man sich mit Funktionspointern eben selber ähnliche Systeme bauen wie der C++ Compiler verwendet. Ob und was für Alternativen es gibt hängt vom konkreten Fall ab...
m4studios

Tobiking

1x Rätselkönig

Beiträge: 1 231

  • Private Nachricht senden

37

26.06.2010, 03:05

Zitat von »storage«

heisst das, dass abstrakte Klassen overhead erzeugen? Wenn ja welche alternativen gibt es?

Zumindest bei VC gibt es __declspec(novtable) (http://msdn.microsoft.com/en-us/library/k13k85ky.aspx) das man bei abstrakten Klassen (nur pure virtual Funktionen) nutzen kann damit keine vtable erstellt und genutzt werden.

Bei kleinen Vererbungshierarchien gehört das sicherlich zur Microoptimierung, aber ich fand das ist ein gutes Beispiel für etwas wo ein C++ Sprachfeature auf etwas abgebildet wird, was dynamisch zur Laufzeit aufgelöst wird. Gerade weil bei der Vererbung sonst sehr viel zur Compilezeit erledigt wird. Ich teile ja auch die Meinung das man mit C++ genauso performant programmieren kann, allerdings muss man auch wissen was hinter der Sprache passiert, und gerade solche impliziten Sachen verschleiern oft was passiert. Bei C setzt man die Funktionszeiger bewusst ein.

Wobei schlimmer sind da wahrscheinlich noch so Stellen wie das Aufrufen des Kopierkonstruktor beim Zuweisen, die Standardinitialisierung bei Membervariablen und ähnliches. Bei großen Objekten merkt man das dann schon deutlich das man etwas falsch gemacht hat. Aber das ist alles nichts was man durch Sprachkenntnis nicht umgehen bzw. korrigieren kann.

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

38

26.06.2010, 03:19

Nur damit jetzt keiner auf den Gedanken kommt dass man mit novtable irgendwie magisch sämtlichen Overhead eliminieren kann: novtable verhindert nur dass für die abstrakte Basis eine eigene, unnötige vtable angelegt wird. Ohne vtable geht es am Ende deswegen trotzdem nicht, abgeleitete Klassen brauchen immer noch eine vtable, Laufzeitpolymorphismus funktioniert nunmal so...
m4studios

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »dot« (26.06.2010, 03:25)

LukasBanana

Alter Hase

  • »LukasBanana« ist der Autor dieses Themas

Beiträge: 1 097

Beruf: Shader Tools Programmer

  • Private Nachricht senden

39

26.06.2010, 11:22

Wie gesagt, ich werde wahrscheinlich meinen SoftwareRenderer irgendwann wie auf C++ umschreiben bzw, einen komplett neuen in C++ schreiben.

Aber um noch mal auf meinem Compiler- bzw. Linker Fehler zurück zu kommen. Das letzte Problem steht noch offen. Ich habe die PNG sources jetzt wieder in mein Projekt aufgenommen, damit man - wenn man meine Engine nutzt - nicht immer "libpng12.dll" und "zlib1.dll" mit kopieren muss.
Folgende Fehler meldungen treten auf:

C-/C++-Quelltext

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

Verknüpfen...
   Bibliothek "bin\Win32-vc\SoftPixelEngine.lib" und Objekt "bin\Win32-vc\SoftPixelEngine.exp" werden erstellt.
png.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "_crc32@12" in Funktion "_png_reset_crc".
png.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "_inflateReset@4" in Funktion "_png_reset_zstream".
pngpread.obj : error LNK2001: Nicht aufgelöstes externes Symbol "_inflateReset@4".
pngrutil.obj : error LNK2001: Nicht aufgelöstes externes Symbol "_inflateReset@4".
pngpread.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "_inflate@8" in Funktion "_png_process_IDAT_data".
pngread.obj : error LNK2001: Nicht aufgelöstes externes Symbol "_inflate@8".
pngrutil.obj : error LNK2001: Nicht aufgelöstes externes Symbol "_inflate@8".
pngread.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "_inflateInit_@12" in Funktion "_png_create_read_struct_2".
pngread.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "_inflateEnd@4" in Funktion "_png_read_destroy".
pngwrite.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "_deflate@8" in Funktion "_png_write_flush".
pngwutil.obj : error LNK2001: Nicht aufgelöstes externes Symbol "_deflate@8".
pngwrite.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "_deflateEnd@4" in Funktion "_png_write_destroy".
pngwutil.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "_deflateInit2_@32" in Funktion "_png_write_IHDR".
pngwutil.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "_deflateReset@4" in Funktion "_png_write_compressed_data_out".
bin\Win32-vc\SoftPixelEngine.exe : fatal error LNK1120: 9 nicht aufgelöste externe Verweise.


Die Dateien png.c usw. sind natürlich nicht von mir. Das kompilieren an sich funktioniert ohne Fehler, ohne Warnung. Das Problem liegt als beim Verlinken.
Weiß jemand in welcher .lib Datei die Funktionen "_crc32" usw. liegen? Oder muss ich jetzt auch die sources der ZLib mit dazu nehmen?
Mit GCC ging es ja auch mit den bisherigen sources.

EDIT:
Wenn ich "zlibwapi.lib" mit verlinke verlinkt er zwar richtig, aber dann muss ich wieder "zlibwapi.dll" mit liefern. Oder stört euch das nicht, wenn ihr eine 3D Engine benutz, noch mehrere dlls mit zu kopieren?
Wie ist das denn bei der Irrlicht Engine. Die braucht doch auch keine extra dlls oder? Zumindest keine, die nicht schon standard mäßig bei Windows dabei sind.
Mein YouTube Channel
Mein Twitter Profil
Meine Projekte auf github.com
Meine Projekte auf bitbucket.org

LukasBanana

Alter Hase

  • »LukasBanana« ist der Autor dieses Themas

Beiträge: 1 097

Beruf: Shader Tools Programmer

  • Private Nachricht senden

40

26.06.2010, 12:11

Ich hab die sources der zlib zu meinem Projekt jetzt neu hinzugefügt und endlich ist die Compilation und Verlinkung fertig =)

Jetzt gehn die Probleme natürlich in den Beispiel Projekten zu meiner Engine weiter xD.
Aber zum Glück lange nicht mehr so viele.

Ich habe in ein paar Klassen statische Member:

C-/C++-Quelltext

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// In meiner eignene lib:

class SP_EXPORT MyClass
{
    public:
        static inline bool getTextureIntern()
        {
            return isTextureIntern_;
        }
    private:
        static bool isTextureIntern_; // Dieses statische Member wird natürlich in der cpp Datei richtig angelegt -> "bool MyClass:isTextureIntern_;"
};

// In meinem Beispiel Programm:

// Wird gar nicht auf gerufen ^^ aber die Fehler meldung lautet:

main.obj : error LNK2001: Nicht aufgelöstes externes Symbol ""private: static bool sp::scene::ModelSaverSPM::isTextureIntern_" (?isTextureIntern_@ModelSaverSPM@scene@sp@@0_NA)".
Mein YouTube Channel
Mein Twitter Profil
Meine Projekte auf github.com
Meine Projekte auf bitbucket.org

Werbeanzeige

Ähnliche Themen