POLL (Programmiersprachen)

[Artchi]

2009 schon, da hat man sich dann aber schnell geeinigt drauf. Dauert ja nur noch 2 Jahre um eine offenbar fertige Erweiterung zu standardisieren. Ist ja auch kein Problem, was sind schon 2 Jahre in der IT-Welt. Erstmal Kaffee holen...

Na, dich zwingt ja keiner so lange zu warten. Kannst ja eine andere moderne Sprache benutzen. Also, ich meine nur, mir ist das doch schnuppe, was jeder benutzt. Du mußt wirklich nicht noch bis 2009 warten. Ehrlich. Ich halte dich nicht auf.

[Gast]

SideWinder schrieb:

TactX schrieb:

SideWinder schrieb:

Ich warte eigentlich nur noch darauf, dass Adobe auf C# und .NET umsteigt damit die Jünger der Gläubigen hier nicht dauernd ihr Paradebeispiel rauswerfen können.

Naja, was zeigen würde wie brauchbar Java für Desktopanwendungen ist. Aber bloss aufpassen, dass die nicht auf das komplexe C++/CLI umsteigen, gell?

Java und C#/.NET sind andere Namen für das Gleiche.

Echt?

[nep]

Ist mal wieder so sinnlos das ganze. Naja 2 Punkte von mir:

Visual Assist X vs Eclipse:
Das Visual Assist X nichts kann ist schon ziemlich daneben. Das kann schon einiges, aber perfekt ist es eben auch nicht, und es reicht tatsächlich nicht an Eclipse ran. Aber ich persönlich finde, dass es für viele alltägliche Dinge doch sehr gut funktioniert und dadurch schon sehr nahe an Eclipse kommt.

Bibliotheken:
Also das Argument von Leuten, dass man keine zusätzlichen Bibliotheken einbinden will (z.B. Boost), weil dadurch z.B. die Programme größer werden oder sonst was, ist ja mal sowas von daneben. Das ist doch in Java nicht anders, nur dass man hier nicht mal die Wahl hat, sondern dass man automatisch oft "Ballast" mitschleppt den man so gar nicht benötigt. Und um nicht falsch verstanden zu werden, ich finde das auch nicht sonderlich schlimm, nur kann man doch dann nicht C++ ankreiden, dass man hier im Prinzip die freie Wahl hat...

Und ich stell jetzt mal ne These auf, auch wenn sie noch so blöd ist:
Wenn C++ eine komplett neue Sprache wäre, und nicht C kompatibel wäre (was ja aber natürlich schon gut ist), dann gäbe es solche Threads wie diesen hier gar nicht. Den "Frickel"-Ruf hat C++ doch nicht zuletzt deswegen, weil eben immer wieder veraltete C Konstrukte eingesetzt werden, anstatt die moderneren C++-Mittel zu verwenden. Und das nicht nur von Anfängern, sondern auch im professionellen Bereich. Liegt einfach auch daran, dass man nicht gezwungen ist, sich mit den ganzen C++-Sachen auseinanderzusetzen, merke ich ja auch selbst manchmal bei mir.

[SideWinder]

@Artchi: Keine Sorge, im Gegensatz zu manch anderen hier oder sonstwo (thomas001 im Chat zB) stelle ich zuerst fest welche Aufgabe ansteht, dann welche Umweltbedingungen (vorhandener Code, etc.) ich habe und erst dann welche Programmiersprache ich dafür benutze. Danach welche Libraries ich verwende (Logging, DB-Anbindung, etc.).

Manche hier sind aber von vornherein auf jeden Fall von C++ überzeugt, überlegen dann wie sie die Aufgabe umdichten können damit sie optimal passt. Fangen erst einmal an das Logging-System oder das Konfiguration-System zu schreiben. Arbeiten sich bei Minimalproblemen stark ins detail und übersehen dann, dass ihr ehrgeiziges Projekt bereits tot ist bevor es richtig angefangen hat.

@TactX: Nein, nicht unencht.

MfG SideWinder

[THX 1138]

SideWinder schrieb:

THX 1138 schrieb:

Natürlich kannst du das in C++ machen, siehe Traits-Klassen.

Sample für std::vector und std::list bitte, danke.

Einfach mal google verwenden und selbst nachlesen bitte, danke.

[SideWinder]

Und ich stell jetzt mal ne These auf, auch wenn sie noch so blöd ist:
Wenn C++ eine komplett neue Sprache wäre, und nicht C kompatibel wäre (was ja aber natürlich schon gut ist), dann gäbe es solche Threads wie diesen hier gar nicht. Den "Frickel"-Ruf hat C++ doch nicht zuletzt deswegen, weil eben immer wieder veraltete C Konstrukte eingesetzt werden, anstatt die moderneren C++-Mittel zu verwenden. Und das nicht nur von Anfängern, sondern auch im professionellen Bereich. Liegt einfach auch daran, dass man nicht gezwungen ist, sich mit den ganzen C++-Sachen auseinanderzusetzen, merke ich ja auch selbst manchmal bei mir.

Da steckt viel Wahres drin. Leider ist in dem Fall die Hybridität absolutes Problem statt Vorteil. Da man in C++ zu nichts gezwungen ist kann man kaum Leute einsetzen die sich nur halb oder wenig auskennen. Hier im Forum findet man ja maximal 50 Leute denen man einen Job im C++-Bereich geben sollte ohne das Projekt in schlimme Probleme zu reiten.

MfG SideWinder

[otze]

SideWinder schrieb:

otze schrieb:

gibt es denn einen sinnvollen grund, wieso container polymorph sein müssen, wenn die sprache ein funktionierendes iteratorkonzept(also nicht sowas wie in java) unterstützt?

Z.B. kann ich je nach Einstellung zur Laufzeit entscheiden welche konkrete Implementierung ich verwenden will. Meine Funktion verarbeitet Daten in einer Liste. Ob sich jetzt für eine ArrayList entschieden wurde oder eine LinkedList ist abhängig von dem wie der Benutzer die Daten einfügen konnte. Was ist übrigens deiner Meinung nach am Java-Iteratorkonzept soviel schlecheter als am C++-Konzept?

java iteratoren sind nicht vergleichbar, man kann also nicht zwischen 2 iteratoren hin und her iterieren. Geht halt maximal bei ner list, wenn man start und end index kennt, aber jede operation auf dem container(wie zb remove) würde die indices ungültig machen(was zb bei C++ nicht unbedingt sein muss). dazu kommt halt noch, dass man die rückgabewerte immer casten muss, aber da bin ich wohl zu sehr C++ verwöhnt, da passt das alles irgendwie besser, wirkt ntürlicher.

[SideWinder]

Rückgabewerte casten? Du redest von <= 1.4.2 und wir sind bei 1.6. Da kannst du nichtmal mehr mit TRs kommen. 1.5 ist mehr als nur Standard. Es ist bereits 1.7 in Entwicklung. Selbst die letzte Entwicklungsumgebung hat schon auf 1.5 umgestellt.

for(Entity e : c)
    e.doSmth();

// oder von mir aus das:
Iterator iter = c.iterator();
while(iter.hasNext())
{
    Entity e = iter.next()
    e.doSmth();
}

Das soll "nicht natürlich" wirken im Gegensatz zu:

list_iter iter = c.begin();
while(iter != c.end())
    iter->doSmth();

Junge junge...

MfG SideWinder

[SideWinder]

Oder gar extröm:

std::list<Entity>::iterator iter = list.begin();
const std::list<Entity>::const_iterator ende = list.end();
while(iter != ende)
    iter->doSmth();

Jippie.

MfG SideWinder

[Artchi]

Ab C++2009 wird das so aussehen:

auto iter = list.begin();
auto ende = list.end();
while(iter != ende)
    iter->doSmth();

Aber stimmt ja, so lange kannst du ja nicht warten.

[SideWinder]

Artchi schrieb:

Ab C++2009 wird das so aussehen:

auto iter = list.begin();
auto ende = list.end();
while(iter != ende)
    iter->doSmth();

Aber stimmt ja, so lange kannst du ja nicht warten.

Beim iterieren interessiert mich der Containertyp nicht wirklich, deswegen scheint mir das auto nicht so unpraktisch. Aber der Inhaltstyp wär schon interessant. Was hat eigentlich gegen die Einführung einer foreach-Schleife gesprochen? Alles was Iterable implementiert kann in der foreach angewandt werden und schwups wärs noch kürzer und noch schöner geworden:

for(Entity e : c)
    e.doSmth();

MfG SideWinder

[Artchi]

SideWinder schrieb:

Rückgabewerte casten? Du redest von <= 1.4.2 und wir sind bei 1.6. Da kannst du nichtmal mehr mit TRs kommen. 1.5 ist mehr als nur Standard. Es ist bereits 1.7 in Entwicklung. Selbst die letzte Entwicklungsumgebung hat schon auf 1.5 umgestellt.

Stimmt, aber die IBM-Webspheres gurken leider noch auf 1.4 rum, so das die RMI-Java-Binary-Kompatibilität mit dem Client >1.4 nicht stimmt. Ergo muß der Client noch 1.4 laufen. Aber wenigstens sind vor knapp 2 Jahren die Serverfarmen von IBM von 1.3 auf 1.4 migriert worden. Müssen wir wenigsten keine 1.3-Clients mehr benutzen.

[Artchi]

SideWinder schrieb:

Artchi schrieb:

Ab C++2009 wird das so aussehen:

auto iter = list.begin();
auto ende = list.end();
while(iter != ende)
    iter->doSmth();

Aber stimmt ja, so lange kannst du ja nicht warten.

Beim iterieren interessiert mich der Containertyp nicht wirklich, deswegen scheint mir das auto nicht so unpraktisch. Aber der Inhaltstyp wär schon interessant. Was hat eigentlich gegen die Einführung einer foreach-Schleife gesprochen? Alles was Iterable implementiert kann in der foreach angewandt werden und schwups wärs noch kürzer und noch schöner geworden:

for(Entity e : c)
    e.doSmth();

MfG SideWinder

foreach soll auch drin sein, kenne deren Syntax aber nicht... sieht aber glaub ich so aus wie deine gepostete. In Kombination mit den Concepts müsste das dann auch funktionieren.

[SideWinder]

Kannst ja einen Proxy mit 1.4.2 vorschalten. Bzw. anderen AppServ verwenden. Selbst JBoss ist ja schon bei 1.5 angelangt

MfG SideWinder

[SideWinder]

BTW: Schonmal überlegt auf WebServices umzusteigen, dann fällt dir das mit den Versionen raus. RMI ist ja in der Hinsicht nicht gerade das Gelbe vom Ei Oder gibts da zuviele Performanceprobleme bzw. zu wenig Kapital zur Umsetzung?

MfG SideWinder

[Artchi]

WebServices habe ich in meinem Vorletzten Projekt gemacht. Bei den RMI-Projekten handelt es sich um Altprojekte, wohlgemerkt Plural (es geht nicht um eine Mittelständige Firma). WebServices sind sozusagen für neue Projekte vorgeschrieben. Altprojekte müssen erstmal Budget auftreiben, da alles in Production ist. Den Switch kann man nicht so ebend machen.

Performanceprobleme gibt es in wenigen Projekten, mit RMI dauern die Antwortzeiten schon im Minutenbereich. (kein Witz) Die werden sich das zweimal überlegen.

[Phoemuex]

SideWinder schrieb:

Oder gar extröm:

std::list<Entity>::iterator iter = list.begin();
const std::list<Entity>::const_iterator ende = list.end();
while(iter != ende)
    iter->doSmth();

Jippie.

MfG SideWinder

Da sieht man wieder, wie gut die Leute sich mit C++ auskennen, die immer meckern. Wo wird denn der Iterator in der Schleife bitte verändert?

Ich finde an C++ allerdings auch die fehlenden Bibliotheken nervig... Wenn man für GUIs, Sockets, Threads usw. jeweils eigene Bibliotheken verwenden muss, die miteinander nicht kompatibel sind und die nicht die Standard-Bibliothek verwenden, nervt das schon. Das hat aber mit der Sprache an sich erstmal nichts zu tun. Von der SPRACHE an sich (unabhängig von Tools, Bibliotheken, etc.) finde ich C++ nämlich weitaus eleganter und schöner als Java, das aber halt einige nette Tools und Bibliotheken mehr hat.

Just my 2 Cents zu diesem Flamewar der Extraklasse

Felix

[Apollon]

Das ist kein Flamewar mehr. Das ist ein Chat.

[Artchi]

Ja, man hätte ein Typedef nutzen können, wäre kürzer geworden. Oder am besten gleich std::for_each oder std::transform.

Ich finde an C++ allerdings auch die fehlenden Bibliotheken nervig... Wenn man für GUIs, Sockets, Threads usw. jeweils eigene Bibliotheken verwenden muss, die miteinander nicht kompatibel sind und die nicht die Standard-Bibliothek verwenden, nervt das schon.

Haben wir schon mehrmals angesprochen: es gibt Lösungen die sich nach der Stdlib richten. Wenn man natürlich Qt oder so benutzt, wird das nichts. Aber Sockets z.B. sind mit Boost.asio schon mal ein sehr guter Schritt und ist auch für TR2 vorgeschlagen. Basis-Threads und neues Speichermodell für Threads kommen in den C++2009 rein (wer dann immer noch motzt, kann ich nicht helfen) und ne größere Thread-Lib kommt wohl in den TR2.

GUIs wirst du aber NIE in der Stdlib sehen. Das müssen sich die Leute einfach aus dem Kopf streichen. Dazu hat sich das Komitee schon geäussert. Da kann niemand was dran ändern.

[SideWinder]

Eventuell wärs nicht blöd die Standardbibliothek überhaupt zu streichen, C++ als Sprache schön zu definieren und keine halben Sachen zu veranstalten.

Dann erfinde ich ein Package-System ähnlich wie bei Linux und verwende was gut ist

Irgendwie merkt man nämlich schon Mängel an der Standard-Bibliothek, sonst würde man ja gar nicht auf die Idee kommen Boost in den Standard zumindest teilweise aufzunehmen

MfG SideWinder