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!

Visual C++ 6?

Werbeanzeige

Anonymous

unregistriert

11

24.06.2006, 23:07

Na gut, da fundierte Antworten gewünscht wurden, hier ein Vergleich zwischen VC++6 und VC++8 (2005 Express)

IDE und Editor
VC++6: Seiner Zeit (1997 rum) eine Revolution! Aber wir leben im Jahre 2006 und da will man etwas viel mehr als nur fehlerhaftes darstellen von Klassen/Funktionen/Parametern/Variablen/Makros usw. :arrow: Veraltet

VC++8: Marktführer in der IDE und im Editor, absolut freie Wahl des Designs (Drag'n Drop), absolut freie Wahl der Tastaturbefehle, absolut freie Wahl der Makroabläufe. Dank Intelli Sense kein Problem mehr mit fehlerhaften Darstellungen egal wovon. Was er nicht kennt, wird nach dem Kompilieren hinzugefügt.

Die IDE kann ebenfalls auf für C#, WebDeveloper, J#, VB.NET und viele mehr benutzt werden!

Compileroptimierung
VC++6: Damals Top, heute Flopp. Er kann einfach nicht mehr so gut. Ist klar: Heute gibt es neue Auslagerungen, neue Ideen, neue Techniken als vor fast 10 Jahren!

VC++8: Auch hier neben dem Intel-Compiler Marktführer. Beste Optimierung die geht und noch immer freie Möglichkeit die Optimierung zu beeinflussen mit eigenem Assemblercode vor der Kompilierung. Auch der Linker hilft mehr als in VC++6.

Standards
VC++6: Wir coden alle nach dem C++99 Standard, VC++6 kannte den noch nicht, da er noch nicht existierte. VC++6 hatte schon mit dem damaligen C++ Standard Probleme! Ich sag nur Scope-Bug bei for-Schleifen und verschachtelte Templates sowie Metaprogrammierung. Da war gnadenlos Ende. Heutige Features der STL sind auf diesem Compiler absolut unmöglich! Hashmaps sind auf VC++6 dank veraltetem Standards lam bis zum geht nicht mehr!

VC++8: Boost hat es bewiesen: VC++8 hat weniger Probleme mit dem aktuellen Standard als GCC, Intel, Borland, IBM, Bloodsheet uvm. Microsoft hat hier wieder nur die Besten der Besten dazu gesetzt. Bei der Entwicklung und einhaltung des Standards war nicht nur Microsoft von der Party, sondern auch das ISO-Komitee und Scott Meyers haben es auf Herz und Nieren geprüft! Ergo: Bester Compiler am Markt.

Makrofertigkeit
VC++6: Makros waren hier ein absoluter Graus, ähnelten mehr an Excel Visual Basic als an ein richtiges Makro. Lausiger Debugger für Makros und total umständlich.

VC++8: Dank C#, Managed C++ und VB gibt es hier keinerlei Probleme. Auch externe Programme können als Makro benutzt werden! 1a Debugger und total Benutzerfreundlich.

Component Object Model
VC++6: Aktuelle COM-Objekte können nicht mehr benutzt werden, meist auch fehlerhafte COM-Objekte waren in VC++6 enthalten.

VC++8: Ein Traum für COM! Grenzen bei COM? Keine mehr.

Debugger
VC++6: Mit diesem Teil zu arbeiten, war schon ein Drama. Benutzerunfreundlich, schäbbig und absolut Fehlerhaft!

VC++8: Mal wieder eines: Marktführer! Benutzerfreundlich, schnell, korrekt und unglaublich Flexibel! Dazu noch Ausbaufähig durch den User!

Secure Code
VC++6: Ein Traum :lol:

VC++8: sprintf und co wurden durch sichere Funktionen ersetzt! Pufferüberläufe sind unmöglich geworden bei diesen Funktionen. Auch Stack Canarians wurden eingebaut um zu prüfen ob es Probleme im Stack gab. und und und!

Specials
VC++6: Gibt es keine Nennenswerten.

VC++8: Anbindung ans Microsoft Office 2003 Visio! Ergo: UML Diagramme aus dem Code heraus erzeugen und aus dem UML-Diagramm Code erzeugen! Das selbe gillt auch für PAPs. Direktanbindungen an Microsoft SQL 2005 Server und viele andere Microsoftprodukte, die das Coding mehr als nur erheblich erleichtern können!!

Also stellt sich hier ganz einfach die Frage: Ein Relikt benutzen oder den kostenlosen Marktführer? Also ich fahr auf edle Qualität ab, und das ist bei mir VC++8.

- Patrick

john

Alter Hase

Beiträge: 786

Beruf: Schüler

  • Private Nachricht senden

12

24.06.2006, 23:51

Ob das jetzt Leute überzeugen kann ? ;)

DarkRaider
Ich finde nicht unbedingt dass die Wahl des Compilers Geschmackssache ist.
( Ähnliches wurde hier schonmal gesagt. )

Ich selber habe übrigens die 7er Standard Version und 8er Express drauf ...^^
mfg
john

Anonymous

unregistriert

13

25.06.2006, 00:15

Wieso sollte das keine Geschmackssache sein?

David Scherfgen

Administrator

Beiträge: 10 382

Wohnort: Hildesheim

Beruf: Wissenschaftlicher Mitarbeiter

  • Private Nachricht senden

14

25.06.2006, 10:28

Zitat von »"DarkRaider"«

Wieso sollte das keine Geschmackssache sein?

Weil es ja offensichtlich eine ganze Reihe von Argumenten gibt, die für die neue kostenlose Version sprechen.
David Scherfgens Website | Konzentrationstest Polizei

Anonymous

unregistriert

15

25.06.2006, 10:44

David Scherfgen
Dazu ist es noch der Beste in jeder Hinsicht für diesen Preis! Wer da noch BCC55, VC++6 oder DevC++ benutzt ist wirklich selber Schuld.

john

Alter Hase

Beiträge: 786

Beruf: Schüler

  • Private Nachricht senden

16

25.06.2006, 10:45

Genau das meinte ich. Hinzu kommt das meiner Meinung nach höchstens so etwas wie Benutzeroberfläche etc. Geschmackssache sein können, aber der Compiler an sich.. ;)
mfg
john

Anonymous

unregistriert

17

25.06.2006, 11:08

Und was ist wenn jemand den alten C++ Standard lieber mag? Und wenn
er lieber mit VC 6 arbeitet als mit 2005? Meiner Meinung nach ist das
Geschmackssache und so wie ich das mitbekommen habe gab es wesentlich
mehr, die Probleme hatten VC 2005 einzurichten als VC 6. (In den meisten
Büchern wird ja auch noch mit VC 6 gearbeitet, warum eigentlich? Wird ja auch
wenn es noch recht neue sind)

Phili

unregistriert

18

25.06.2006, 11:42

@nix da
Also so überragend find ich die Optimierung wirklich nicht.
Das tolle ist: Weil ich keine Ahnung hab, hab ichs einfach mal ausprobiert.
Hab nämlich ne kleine Funktion für die berüchtigte Wurzel geschrieben-mit dem Heron-Verfahren. Klar das die miserabel abgeschnitten ist-das hatte ich mir schon gedacht.
Aber dann hab ichs nochmal versucht und hab die (vermeindlich langsame) sqrt Funktion von math.h mit einer Leeren Funktion verglichen, die nur ihren Parameter zurückgibt. Ratet mal, welche Funktion schneller war?

C-/C++-Quelltext

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

#include <iostream>
#include <iomanip>
#include <math.h>
#include <windows.h>
#include <time.h>
using namespace std;


double Heron(double a)
{
    return a;
}





int main()
{
    double w;
    double Wert=432.456;
    int a=timeGetTime();
    for(int i=0; i<1000000; i++)
        w=sqrt(Wert);
    a=timeGetTime()-a;
    cout<<a<<endl;
    cout<<setprecision(25)<<w<<endl;
    a=timeGetTime();
    for(int i=0; i<1000000; i++)
        w=Heron(Wert);
    a=timeGetTime()-a;
    cout<<a<<endl;
    cout<<setprecision(25)<<w<<endl;


    system ("PAUSE");
    return 0;
}


Ich kann mir gut denken, das es jetzt heißt, der Test sei nichtssagend, oder unzuverlässig. Aber mir gibt das zu denken...

Anonymous

unregistriert

19

25.06.2006, 12:11

DarkRaider
Du fährst auch lieber mit einer Kutsche als mit einem Auto. Sorry, "lieber mögen" ist in der heutigen Zeit absolut kein Argument mehr. Hier geht es um ein Stück technologie und nicht um ein Kunstwerk. Hier hat lieber mögen absolut nichts zu tun!

Außerdem wurde der alte Standard aberkannt und Benutzung ist nicht mehr legal! <iostream.h> und co. gibt es zum glück ja nicht mehr! Diese perversion *kotz* Wie kann man nur so etwas lieber mögen? Da muß man ja echt einen Schuss haben. Wie gut, das diese Header immer mehr verschwinden, da der alte Standard im gegensatz zum heutigen eines ist: Scheiße!

Phili
Dieser Test ist weniger als nichts aussagend. Dazu hast Du weder angegeben, welche Compilierungsrate und Optimierungsrate du angegeben hast, dazu verwendest Du absolut alten Standard (huhu? math.h und time.h gibt es nicht mehr! Seit über 8 Jahren bald!) und sqrt ist nicht langsam unter Windows. Optimierungen und Auslagerungen in DLLs mit ISSE zeigen nichts langsames mehr.

Dazu wird die for-Schleife sowieso wegoptimiert, da diese absolut Sinnlos ist. Für Zeitausgaben würde ich ebenfalls nicht die <iostream> benutzen, da diese sehr langsam ist. Vorallem hier noch mit Prezisionen rumhantieren, streams manipulieren uvm. So kann man keinen Performance Tests durchführen, nicht mal ansatzweise!

- Patrick

Phili

unregistriert

20

25.06.2006, 12:30

@nix da
Okay, diesmal nehm ich ausnahmsweise alles zurück. Ich hatte das ganze im Debug erstellt. Im release hat es offenbar wirklich die Schleife komplett entfernt-mein lob, hatte Microsoft wohl doch unterschätzt. :o :oops:

Werbeanzeige