4. Welche IDE außer dem Builder?

Welche IDE außer dem Builder?

  • Z

    Das von ein Moderator wird mir zu blöd!

    Falls ich irgendeine URL brauche komme ich zu dir!

    0
  • ?

    Jansen schrieb:

    murphy schrieb:

    auch für linux gibt es bereits projekte die dotnet auf linux lauffähig machen werden

    Selbst wenn Mono einmal richtig funktionieren sollte bleibt doch zu hoffen, dass es sich unter den Linux/Unix-Programmierern nicht durchsetzen wird.

    Das hoffe ich auch.
    .NET und C# sind doof

    Jansen schrieb:

    win32 [...] seit fast 20 jahren im einsatz

    War nicht Win3.x das erste "32bit"-System von MS? Das gab's jedenfalls erst Anfang der 90er.

    1. Das erste 32-Bit-Sytem vom Micro$oft war Windows 95.
    2. vor 20 Jahren war grad mal Windows 1.03 draußen.

    Zur Frage:
    VisualWx + wxWindows + MinGW = 🙂

    0
  • J

    Zeus schrieb:

    Falls ich irgendeine URL brauche komme ich zu dir

    Gern. Aber vorher bitte die FAQ und die Suchfunktion benutzen! 😉

    so_!@H schrieb:

    Das erste 32-Bit-Sytem vom Micro$oft war Windows 95.

    Und das war auch nur ein DOS-Aufsatz! 🙂
    Aber ca. 1993 gab es schon WindowsNT (3.1), und das war von Anfang an 32bit.
    Windows 1.0 erschien erst 1985, vor 20 Jahren war MS-DOS 2.0 aktuell.
    http://members.fortunecity.com/pcmuseum/windows.htm
    http://www.michael-prokop.at/computer/windows.html

    0
  • ?

    hallo,

    @zeus: ich brauche kein prophet zu sein um 1+1=2 zu berechnen!
    du sagtest das der schwachpunkt der vcl wäre das er nicht in c++
    geschrieben wurde. man könnte sowas wie die vcl überhaupt nicht
    in standardisiertem c++ schreiben. oder glaubst du die leute von
    borland haben die sprache der vcl per mi, ma, mau ausgesucht?
    C# ist sehr nah an c++ angelegt, aber unterstüzt eben auch dinge
    die benötigt werden um eben die von dir so propagandierte RAD-Um-
    gebung überhaupt erst zu ermöglichen.
    ich weiss dass man über sprachen nicht streiten braucht, das artet
    immer in so eine art relitionskrig aus, aber man sollte sich doch
    davor hüten immer gleich mit dem spruch "das ist doch ein scheiss"
    über andere sprachen zu urteilen. und dotnet ist mitlerweile schon
    in der zweiten runde, und hat wieder ein loch gestopft, es unterstüzt
    nun auch eine art templates.
    managed c++ (visual c++.net) ist nur eine übergangsgeschichte, auf
    kurz oder lang wird sich dies nicht halten können genauso wenig
    wie die mfc...

    der prophet
    murphy

    0
  • Z

    murphy schrieb:

    hallo,

    @zeus: ich brauche kein prophet zu sein um 1+1=2 zu berechnen!

    Sinnloser Satz, ich bin andere Meinung, deswegen kann ich also nicht 1+1 rechen!! Ja Toll!

    murphy schrieb:

    du sagtest das der schwachpunkt der vcl wäre das er nicht in c++
    geschrieben wurde. man könnte sowas wie die vcl überhaupt nicht
    in standardisiertem c++ schreiben. oder glaubst du die leute von
    borland haben die sprache der vcl per mi, ma, mau ausgesucht?

    Die VCL würde in Object Pascal geschrieben, da diese Spache über Features Unterstützt die C++ nicht hat ist klar, dass man Sie nicht in ANSI C++ schreiben kann. Das selbe ist wenn ich ein Framework in C++ schrieben würde und nach Delphi tansportieren würde. Dann muss man Object Pascal erweitern.

    murphy schrieb:

    C# ist sehr nah an c++ angelegt, aber unterstüzt eben auch dinge
    die benötigt werden um eben die von dir so propagandierte RAD-Um-
    gebung überhaupt erst zu ermöglichen.

    Von der Syntax sind sie sich ähnlich, aber nicht von der Konzepte.

    murphy schrieb:

    ich weiss dass man über sprachen nicht streiten braucht, das artet
    immer in so eine art relitionskrig aus, aber man sollte sich doch
    davor hüten immer gleich mit dem spruch "das ist doch ein scheiss"
    über andere sprachen zu urteilen.

    Mach ich nicht! Professionale Entwickler entscheiden den Einsatz einer Sprache nach den Problem , der gestellt ist und nicht nach seine Lieblingssprache. Deswegen wird C/C++ nicht austerben.

    murphy schrieb:

    managed c++ (visual c++.net) ist nur eine übergangsgeschichte, auf
    kurz oder lang wird sich dies nicht halten können genauso wenig
    wie die mfc...

    managed c++ wird auch nicht aussterben, da .NET so ausgelegt ist, dass man mit jeder Objekt-orientierte Programmiersprache mit .NET arbeiten kann.
    PHP.NET, VB.NET, C#, Managed C++, JAVA.NET und alle andere.

    0
  • Z

    Warum C++/MFC nicht wegen C#/.NET aussterben wird!

    Spieleprogrammierung
    systemnahe Programmierung
    Systemprogrammierung (es werden keine Treiber mit GC geben)
    Programme, die allgemein effizient und sparsam programmiert werden mussen!

    MFC bietet Document/View-Architektur! Viele Programme haben diese Architektur!

    0
  • ?

    hallo,

    doc/view ist aber auch sehr eng mit mdi verbunden, und mdi wird kaum mehr eingesetzt...

    mfg
    murphy

    0
  • J

    murphy schrieb:

    doc/view ist aber auch sehr eng mit mdi verbunden

    Halte ich eher für ein Gerücht...

    -junix

    0
  • J

    Zeus schrieb:

    Warum C++/MFC nicht wegen C#/.NET aussterben wird!

    Spieleprogrammierung
    systemnahe Programmierung
    Systemprogrammierung (es werden keine Treiber mit GC geben)
    Programme, die allgemein effizient und sparsam programmiert werden mussen!

    MFC bietet Document/View-Architektur! Viele Programme haben diese Architektur!

    Spieleprogrammierung: ich glaub mit der MFC komsmte da nicht weit.
    Systemnahe Programmierung: Es soll nciht die Aufgabe eines Frameworks sein, systemnah zu sein (natürlich möglichst) aber nichts destotrotz sollte ein Framework das darunterliegende System möglichst abstrahieren. Dieser Punkt erfüllt die MFC definitv NICHT
    Systemprogrammierung (Treiber): Auch hier wirst du kaum mit der MFC arbeiten, sondern eher mit der passenden System API. Ausserdem sind Treiber doch auch recht häufig in C verfasst.
    Programme, die [...bla schwall schlagwortgehampel...]: Dann verzichtet man sowieso auf ein Framework da das grundsätzlich OVerhead mit sich bringt. Auch da ist die MFC fehl am Platz
    Und Doc/View ist ebenfalls kein Argument für die MFC. Das kann jedes andere Framework auch oder es lässt sich bequem "nachrüsten" (siehe meinen Doc/View mit VCL Artikel).

    ...das nur so by the way...

    -junix

    0
  • Z

    Welche Aufgabe hat ein Framework?

    0
  • Z

    junix schrieb:

    Spieleprogrammierung: ich glaub mit der MFC komsmte da nicht weit.
    Systemnahe Programmierung: Es soll nciht die Aufgabe eines Frameworks sein, systemnah zu sein (natürlich möglichst) aber nichts destotrotz sollte ein Framework das darunterliegende System möglichst abstrahieren. Dieser Punkt erfüllt die MFC definitv NICHT
    Systemprogrammierung (Treiber): Auch hier wirst du kaum mit der MFC arbeiten, sondern eher mit der passenden System API. Ausserdem sind Treiber doch auch recht häufig in C verfasst.
    Programme, die [...bla schwall schlagwortgehampel...]: Dann verzichtet man sowieso auf ein Framework da das grundsätzlich OVerhead mit sich bringt. Auch da ist die MFC fehl am Platz
    Und Doc/View ist ebenfalls kein Argument für die MFC. Das kann jedes andere Framework auch oder es lässt sich bequem "nachrüsten" (siehe meinen Doc/View mit VCL Artikel).

    ...das nur so by the way...

    -junix

    Entschulidung für meine unpräzise Aussage ich meinte:
    C/C++ WinAPI/MFC/ATL/VCL/Directx SDK und Co.

    0
  • Z

    junix schrieb:

    Und Doc/View ist ebenfalls kein Argument für die MFC. Das kann jedes andere Framework auch oder es lässt sich bequem "nachrüsten" (siehe meinen Doc/View mit VCL Artikel).

    Wo ist der Artikel?

    0
  • J

    Zeus schrieb:

    Welche Aufgabe hat ein Framework?

    Abstraktion einer API und Vereinfachung des Handlings derselben.

    (Was z.B. die MFC nicht wirklich erfüllt)

    Zeus schrieb:

    Wo ist der Artikel?

    Noch nicht ganz fertig und daher nur halb publik:

    http://www.junix.ch/bcb/help/doc_view/

    Wer einen alten BCB hat, der sollte eine neue Anwendung erstellen mit dem selben Namen und die Projektdateien (ausser BPR) überscheiben. Anschliessend alle Dateien dem Projekt hinzufügen.

    Anregungen etc. sind willkommen.

    -junix

    0
  • Z

    junix schrieb:

    Zeus schrieb:

    Welche Aufgabe hat ein Framework?

    Abstraktion einer API und Vereinfachung des Handlings derselben.

    (Was z.B. die MFC nicht wirklich erfüllt)
    -junix

    Stimmt MFC wird nicht als Framework bezeichnet! Dennoch scheint MFC leider eine Zukunft zu haben, die Borland mit der VCL im C++ Bereich nicht zu haben scheint!

    0
  • J

    Die Zukunft der VCL steht im Moment wirklich noch in den Sternen....

    -junix

    0
  • ?

    aber die der mfc ganz gewiss auch. und visual cpp.net ist nix als ein zwitter, ein notnagel und bestehendes nicht ganz übern haufen werfen zu müssen. meint jemand im ernst, die mfc wird nach dotnet übersetzt????

    da sieht es mit der vcl ganz anders aus, die ist nämlich bereits nach dotnet übersetzt worden, nicht für den builder wohl aber für delphi (octance) das demnäxt mit der 8er rauskommt und da noch win32 und dotnet unterstützt.

    mfg
    murphy

    0
  • Z

    murphy schrieb:

    aber die der mfc ganz gewiss auch. und visual cpp.net ist nix als ein zwitter, ein notnagel und bestehendes nicht ganz übern haufen werfen zu müssen. meint jemand im ernst, die mfc wird nach dotnet übersetzt????

    MFC nach dotnet bist du den verrückt! Ich will mit der MFC native Programme in C++ schreiben! Wenn du managed C++ als zwitter muss du doch zwangsweise VCL/C++ auch als Zwitter bezeichnen.

    murphy schrieb:

    da sieht es mit der vcl ganz anders aus, die ist nämlich bereits nach dotnet übersetzt worden, nicht für den builder wohl aber für delphi (octance) das demnäxt mit der 8er rauskommt und da noch win32 und dotnet unterstützt.

    Noch mal die VCL ist Object Pascal geschrieben, die gleiche die in C++Builder 6 verwendet wird. Nicht umsonst ist der Delphi Compiler mit drin!

    .NET ist sprachneutral! VCL.NET ist wahrscheinlich eine Kapselung von .NET-Framework, damit der gleiche Sourcecode funktioniert! Eine HelloWorld-Anwendung ist ja im Speicher 11 MB groß. Bin mal gespannt wie gross Sie in VCL.NET ist!

    Übrigens (ca.):
    C++/VCL 5 MB
    C++/MFC 3 MB

    0
  • J

    Zeus schrieb:

    Übrigens (ca.):
    C++/VCL 5 MB
    C++/MFC 3 MB

    ? Was soll das für ne Angabe sein?

    -junix

    0
  • ?

    hallo,

    mit zwitter meinte ich eigentlich nix halbes und nix ganzes, eben visual c++.net. vcl/cbuilder ist durchaus was ganzes. es ist doch wurscht in welcher sprache die bibliothek ist, das ist ja sogar ein grundsatz der oop (kapeslung), das man klassen die funktionieren verwenden kann, ohne dass man weiss/wissen muss wie sie implementiert sind. man programmiert ja nicht die bibliothek um sondern verwendet sie um programme die mit c++ code geschrieben sind zu entwickeln. und du kannst dir absolut sicher sein, das die mfc die wie allgemein bekannt lausig object orientiert ist auch sehr viele stellen verwendet die mit standard c++ nicht das geringste zu haben.
    im endeffekt ist es eh gleich ob pascal oder c++ der prozessor macht da keinen unterschied.

    mfg
    murphy

    0
  • Z

    Definiere doch mal, was du mit Zwitter meinst. Welche Kriterien sind anzusetzten und was genau zwitterartig ist. Du benutzt den Begriff "visual c++.net" das für mich eher nur die IDE darstellt!

    C++/VCL 5 MB
    C++/MFC 3 MB

    "Der Speicherverbrauch"

    es ist doch wurscht in welcher sprache die bibliothek ist, das ist ja sogar ein grundsatz der oop (kapeslung),

    Du verwechselts Eigenschaften von Programmiersprache mit Compiler/Linker -Technik!
    Zum Beispiel: Java ist OOP, allerdings bis zur Erscheinen von JNI koennte man kein Nativen Code verwenden! Jetzt ist es nur von C/C++ moglich!

    Wie lange hast du MFC programmiert?

    Bei der MFC muss man die Implementation der Objekte auch nicht kennen! Ich habe schon beschrieben, dass MFC keine hoche Abstraktion hat. MFC verwendet auch Sprachfeature's von C/C++ , die nicht greade OOP-Typisch sind, aber dadürch ist MFC nicht schlechter! Mann muss die Bibliotheke nach seine Entwicklungsziele(Ziele, die sich der Entwickler, der Bibliotheke gesetzt hat) bewerten. Persönlich kann man eine Bibliotheke lieben oder hassen, aber dies hat nicht mit einer sachliche Diskussion zu tun.

    Und DotNet wird nicht der Mittelpunkt der Informatikerwelt

    0
Anmelden zum Antworten