Blick in die Kristallkugel

interpreter

Klar ist nur die generelle Marschroute des "Mainstream": Weg von "technischen" Sprachen und hin zu problemorientierten Sprachen (siehe Entwicklung von Assembler zu C#). In 10-20 Jahren wird der Standardprogrammierer mit Sicherheit nicht mehr mit Pointern rumfummeln (hoffe ich zumindest )

SideWinder

Plattformunabhängigkeit ist erst erreicht, wenn es nur noch eine Plattform gibt.

@Artchi: Java und C# sind nicht wirklich mit C++ vergleichbar, die Sprachen verfolgen in ihrer Entwicklung komplett unterschiedliche Ziele. Außerdem bin ich der Meinung, dass sie auf verschiedenen Ebenen liegen. Java und C# sind highleveliger (Gibts dafür ein anderes Wort ) als C++. Je nach Einsatzzweck wird man wählen. Genauso wie Assembler für RAD ungeeignet ist, ist Java ungeeignet um auf einem Toaster Programme auszuführen, weil eben niemand daran interessiert ist JVMs für Toaster zu schreiben. Außer der Syntax und dem leichten Hang zur OOP haben die beiden Sprachen doch ziemlich wenig miteinander zu tun. Diese ewigen Diskussionen sind doch komplett sinnlos

Einzig und allein im Bereich der Anwendungsprogrammierung überschneiden sich die Sprachen. Hier wird man nach detaillierteren Kriterien vorgehen und die für den jeweiligen Zweck geeignetere Sprache suhcen. Doch das entscheiden meistens Projektleiter und Direktoren, der Programmierer sieht bloß zu.

MfG SideWinder

SideWinder

Weg von "technischen" Sprachen und hin zu problemorientierten Sprachen

Kommt ganz auf den Anwendungszweck drauf an, wenn du Treiber programmierst wirst du auch heute nicht um eine "technische" Sprache herumkommen. Doch der Teil der Programme der bestimmt welche Sprache nun Mainstream ist, sind offenbar GUI-Programme auf PC-Betriebssystemen. Dort ist eine problemorientierte Sprache derzeit die bessere Wahl, da man sich mehr auf die Aufgabe an sich, auf das Problem wie schon im Namen steckt, konzentrieren kann.

MfG SideWinder

interpreter schrieb:

(siehe Entwicklung von Assembler zu C#)

Ja, die Assembler haben sich wirklich erstaunlich entwickelt
Jetzt weiß ich auch, warum die Pakete bei C#.net Assemblies heißen.

interpreter

@SideWinder: Ich habe explizit vom Mainstream gesprochen.
@SeppSchrot: Ich habe von der Entwicklung der Sprachen geredet und nicht der Entwicklung einer Sprache.

SideWinder schrieb:

Java und C# sind highleveliger (Gibts dafür ein anderes Wort ) als C++.

Das würde ich nicht unbedingt sagen. C++ bietet einige Abstraktionsmöglichkeiten, die Java oder C# so nicht bieten. Insofern kann man mit C++ auch auf sehr hohem Level programmieren. Das Problem von C++ ist einfach nur die absolut unzureichende Standardbibliothek. Wenn C++ ein Äquivalent zur Standardbibliothek von Java hätte, dann würdest du Java oder C# sicherlich nicht mehr als "highleveliger" bezeichnen.

---> Wenn man von Kleinigkeiten, wie Unterstützung von Threads usw. absieht.

otze:

wenn du die stl nicht benutzen willst, ist das genauso wie wenn du das schlüsselwort "class" meidest.<<

hast mich überredet -
na gut, dann nehme ich ab jetzt class string statt char...[80] und wehe, in 20 Jahren kennt der Compiler die STL nicht mehr

Ansonsten: C++ ist wohl die sprache deiner wahl, da das kommitee nie irgendetwas rauswerfen wird.<<

Den Eindruck habe ich langsam auch gewonnen - hab mir gerade das Stroustroup-Paper
über die Entwicklung von C++0x durchgelesen, und Stroustroup schreibt dort
tatsächlich, daß die Gewährleistung der Compilierbarkeit von Standard ('98) C++-Quellen mit C++0x -Compilern vordere Priorität hat.

Bleibt noch das Risiko, daß die C-C++-Linie in Jahren abgelöst wird durch
eine ganz andere Art Programmiersprachen und C++0x nie die Bedeutung haben
wird, die C++ heute hat.

cacheline schrieb:

Ansonsten: C++ ist wohl die sprache deiner wahl, da das kommitee nie irgendetwas rauswerfen wird.<<

Den Eindruck habe ich langsam auch gewonnen...

???

void main?
iostream.h?

Warum steht das denn in den alten Büchern drin, wenn es nie korrekt war? Wer weiß schon, was als nächstes verändert wird? Es könnte zum Beispiel ein neues Schlüsselwort eingeführt werden, das ne Menge Code ungültig macht.

das war nie standard

Artchi

Gregor! Die .h-Header und void-main waren doch nie im Standard drin, also konnten sie auch nie rausfliegen. Und es wird sicherlich auch nichts rausfliegen, höchstens depricated gesetzt werden. Ist ja bei Java auch so: es kommt ein Ersatz für etwas altes, aber das alte kann immer noch verwendet werden. Aber ich glaube nicht das sowas in C++ passieren wird, weil die Standard-Lib einfach viel zu klein ist, im Gegensatz zur Java-Lib. Da gibts nicht viel raus zu schmeissen.

Gab es keinen C++ Standard vor 98?

Bei Java gibt es durchaus einige Dinge, bei neuen Versionen, die alten Code ungültig machen. ...zum Beispiel das neue enum-Schlüsselwort, das mit 5.0 kam. So gesehen bist du schon auf alte Compiler angewiesen, wenn du alten Javacode kompilieren möchtest. ...der Bytecode sollte dann allerdings auch auf aktuellen JVMs lauffähig sein.

iostream.h schrieb:

das war nie standard

Naja, ist eigenlich ziemlich egal, was es nun war. Vor 10 Jahren hat man es in C++ genutzt und jetzt geht es nicht mehr. Wie kann man da so sicher sein, dass soetwas nicht in Zukunft auch passiert?

Gab es keinen C++ Standard vor 98?

richtig

net 0

Gregor@Home schrieb:

Vor 10 Jahren hat man es in C++ genutzt und jetzt geht es nicht mehr.

oft geht's noch. man bekommt aber ein warning. bei java erscheinen ja auch die deprecated meldungen

Vor '98 gab es keinen C++ -Standard; die Standardisierung dauerte also fast 10 Jahre.

Gibt es eigentlich einen Java-Standard ?

Und wieso wird eigentlich C noch weiterentwickelt und neu standardisiert ?
Da Standard-C++ (also C++'98) die *damalige* Version von C als Untermenge enthält,
kann man doch in Schwierigkeiten laufen, wenn man etwa in C'99 programmiert und
eines Tages mit einem Standard-C++ Compiler übersetzen will..., oder ?

Artchi

Gregor@Home schrieb:

Gab es keinen C++ Standard vor 98?

Bei Java gibt es durchaus einige Dinge, bei neuen Versionen, die alten Code ungültig machen. ...zum Beispiel das neue enum-Schlüsselwort, das mit 5.0 kam. So gesehen bist du schon auf alte Compiler angewiesen, wenn du alten Javacode kompilieren möchtest. ...der Bytecode sollte dann allerdings auch auf aktuellen JVMs lauffähig sein.

Genau, es gab erst 1998 den ersten Standard. Davor hat halt jeder mehr oder weniger gemacht was er will.

Was ist denn mit enum in Java? Was macht es denn ungültig? enum ist doch in Java5.0 ganz neu und dadurch ist doch nichts raus geflogen. Ich habe jedenfalls nichts gefunden, was rausgeflogen ist. Man kann mit dem neuen JDK auch alte Projekte compilieren. Kein Problem.

Artchi

Cacheline schrieb:

Gibt es eigentlich einen Java-Standard ?

Java ist nicht in der ECMA oder ISO standardisiert. Sun macht da ihr eigenes Ding, weil die ja Geld verdienen wollen. Wer eine Java VM oder Java Compiler entwickelt, und ein Java-Logo drauf pappen will, muß es bei Sun zertifizieren lassen... natürlich gegen Geld. Deshalb heißen auch diese ganzen inoffiziellen Java-implementierungen Cafe oder so damit es ja keinen Ärger mit Sun gibt.

Cacheline schrieb:

Und wieso wird eigentlich C noch weiterentwickelt und neu standardisiert ?
Da Standard-C++ (also C++'98) die *damalige* Version von C als Untermenge enthält,
kann man doch in Schwierigkeiten laufen, wenn man etwa in C'99 programmiert und
eines Tages mit einem Standard-C++ Compiler übersetzen will..., oder ?

Ehm, was hat jetzt C und C++ miteinander zutun? C99 und zukünftiges C++ müssen nicht compatibel sein... sind sie ja jetzt schon nicht! Du kannst mit einem C++98 Compiler keinen C99-Code compilieren (wenn C99 voll ausgeschöpft wird), geht also jetzt schon nicht mehr! Aber das ist auch OK, weil das völlig zwei verschiedene Sprachen sind (wann begreifen das eigentlich die Leute?).

C wird deshalb noch entwickelt, weil es noch massiv eingesetzt wird, z.B. in der Autoindustrie. Deshalb verstehe ich nicht, warum hier immer gesagt wird, das C++0x auch weiterhin auf Toastern laufen muß? Schliesslich ist C eher dafür in der Industrie vertreten. naja, egal...

Du kannst mit einem C++98 Compiler keinen C99-Code compilieren (wenn C99 voll ausgeschöpft wird)<<

Eben - das ist aber ein entscheidender Punkt.
Zukunftssicherer C-Code sollte demnach wohl keine C'99-Erweiterungen enthalten
dürfen, denn C++0x soll voraussichtlich Standard-C++ als Untermenge enthalten,
also "nur" das in C++'98 enthaltene C'89.

Grüße

Artchi

Hallo???? Jemand zu Hause???? Was hat C++0x mit C-Code zu tun?????????????????

Shade Of Mine

Cacheline schrieb:

Zukunftssicherer C-Code sollte demnach wohl keine C'99-Erweiterungen enthalten
dürfen,

C und C++ sind unterschiedliche Sprachen. Und das C Standard Komitee hat beschlossen die beiden Sprachen mehr zu trennen.

denn C++0x soll voraussichtlich Standard-C++ als Untermenge enthalten,

Nein. C++0x wird C++98 erweitern. Nix untermenge oder so.

also "nur" das in C++'98 enthaltene C'89.

Sehe keinen Grund warum so sachen wie restrict nicht aufgenommen werden _könnten_ Viel eher will man nicht, weil man C und C++ etwas separieren will.

C ist etwas anderes als C++. Du hast mit echten C Anwendungen ja auch schon deine liebe not sie nach C++ zu portieren...