vergesst C++ ...

[Power Off]

Kevinus schrieb:

Was wer sagt was gegen Schröder, denkste Trottel wie Stoiber oder Merkel oder sonst jemand würden in diesem verkorksten Land etwas ändern??? Das land kannste eigentlich vergessen... aber zum Thema c++ forever.

Tja ... der Fisch stinkt halt vom Kopf her.

[Walli]

O'Rakl schrieb:

Putzig: Da muß ich euch noch sagen, wie C++ hieß, bevor es "C++" hieß.

Um es mit den Worten des wohl größten Denkers unserer Zeit zu sagen: Ja nee, is klar!

[O'Rakl]

Also beenden wir diese Diskussion mit dem Resumé:

Soll jeder mit seiner bevorzugten Programmiersprache glücklich werden.

[ChockoCookie]

Klar, das ist eh die allgemein gültige Maxime. Nur glauben manche Leute ihre Lieblingssprache sei der Weisheit letzter Schluss und versuchen andere davon zu überzeugen alles andere aufzugeben.

[ewr]

Optimizer schrieb:

Oder nen XmlSerializer mit Konstruktor XmlSerializer(System.Type) und Serialize(Stream, Object) anstatt nen XmlSerializer<Type>.

Seh ich nicht so. Das man bie dieser Klasse ein System.Type angeben muss, ist schon gut überlegt. Hier ein Generic zu verwenden, würde die Möglichkeiten der Serialisierung unnötig beschränken. Stell dir vor, du kennst nur den Namen der Klasse als String oder CLSID oder zur Laufzeit ist noch nicht genau bekannt, was für ein Typ überhaupt serialisiert werden soll ...

[Jockelx]

ewr schrieb:

Optimizer schrieb:

Oder nen XmlSerializer mit Konstruktor XmlSerializer(System.Type) und Serialize(Stream, Object) anstatt nen XmlSerializer<Type>.

Seh ich nicht so. Das man bie dieser Klasse ein System.Type angeben muss, ist schon gut überlegt. Hier ein Generic zu verwenden, würde die Möglichkeiten der Serialisierung unnötig beschränken. Stell dir vor, du kennst nur den Namen der Klasse als String oder CLSID oder zur Laufzeit ist noch nicht genau bekannt, was für ein Typ überhaupt serialisiert werden soll ...

Was soll denn der Mist jetzt ?!?

Wir wollen doch bitte schön unsachlich bleiben. Schreib doch lieber,
was du schon tolles programmiert hast, oder beleidige andere User!
Was anders will ich in einem "vergesst C++" - Thread in einem C++-Forum
nicht sehen!

Jockel

[Gast]

ewr schrieb:

Optimizer schrieb:

Oder nen XmlSerializer mit Konstruktor XmlSerializer(System.Type) und Serialize(Stream, Object) anstatt nen XmlSerializer<Type>.

Seh ich nicht so. Das man bie dieser Klasse ein System.Type angeben muss, ist schon gut überlegt. Hier ein Generic zu verwenden, würde die Möglichkeiten der Serialisierung unnötig beschränken. Stell dir vor, du kennst nur den Namen der Klasse als String oder CLSID oder zur Laufzeit ist noch nicht genau bekannt, was für ein Typ überhaupt serialisiert werden soll ...

Guter Einwand. Muss mal rausfinden, ob man generische Typen mit einem System.Type instanzieren kann. Wenn nicht, wäre es tatsächlich ne Einschränkung. Wenn doch, ist es IMHO besser, einen generischen Serializer zu haben, weil der Cast beim Deserialisieren affig ist.

[kartoffelsack]

Das könnte man auch automatisieren, in dem man ein kleines Tool baut, das einem den entsprechenden Code baut. Einfach angeben, welche Klassen mit boost::serialize implementiert werden sollen -> fertig.

soweit ich mich entsinne hat gSoap sowas dabei, das man auch unabhängig von den Soap-Sachen zur Serialisierung verwenden kann. Ist aber halt ein eigenes Tool, das man drüberlaufen lassen muss. Das ist während der Entwicklung, wo sich dauernd noch kleinigkeiten ändern nervig. Bei der Wartung, wenn schon lang nix mehr mit der Projekt gemacht wurde und es wieder ausgegraben wird und am besten, der ders gemacht hat, nicht mehr verfügbar ist, eine ziehmliche Hürde.

dann musst du halt deinen modularen aufbau überdenken
wenn du an der implementierung eines moduls was änderst ohne das interface zu ändern musst du ja nur das eine modul neu übersetzen

Ach komm. Wie oft muss man dem Compiler sagen 'Projekt bereinigen und alles neu erzeugen' weil er rumspinnt. Membervariablen und private Funktionen gehören auch zur Implementierung. Sind aber in C++ teil des Interfaces (nur der Zugriff ist verboten). Und wenn ich an einem Projekt entwickle, dann ändert sich hier und da was. Mir wird die Funktion zu lang. Denk ich mir, da könnt ich ne eigene draus machen, schnell ne neue private Funktion -> schwups n haufen Zeug muss neu kompiliert werden. Die einzige Möglichkeit ist pimpl. Aber das kannste auch nur da machen, wo ein wirklich eindeutiger Schnitt zu einem anderen Systemteil ist, weil sonst wirste völlig blöde.

Man muss wirklich aufpassen wie ein wilder. Und der Erfolg ist lediglich, dass ich nicht bedenkenlos einen Cafe trinken gehen kann sondern ichs mir jedesmal überlegen muss, ob sichs rentieren würde.

[volkard]

kartoffelsack schrieb:

Die einzige Möglichkeit ist pimpl.

naja, und rimpl (reference to impl).

Aber das kannste auch nur da machen, wo ein wirklich eindeutiger Schnitt zu einem anderen Systemteil ist, weil sonst wirste völlig blöde.

ich hab keine probleme mit langen compilezeiten. aber ich hatte mal und hab mit proxies für members gespielt. der compiler braucht nur die größe und das alignment des members, um das klassenlayout zu berechnen. das geb ich ihm.

#ifndef FOOFWD_H
#define FOOFWD_H

#include "BarFwd.h"

#ifdef RELEASE//steht natürlich in BarFwd.h, hier nur mal als demo
#include "Bar.h"
#endif

class Foo{
   Attribute<Bar> bar;
   ...

und Attribute kriegt natürlich nen op-> und op*, fühlt sich fast wie ein zeiger an, nur daß es die daten selber besitzt.

und dann hat man freiheit, im debug-mode pimpl zu machen und im release-mode echtes layering. die details, was ich da gebaut hab, weiß ich gar nicht mehr. aber mein compilezeitproblem wurde voll überkompensiert.

ich will jetzt nicht in abrefe stellen, daß man sich sowas zur recht allgemeinen verwendung auch mal bauen könnte, wenn es das hauptproblem von c++ wäre. dauert aber 5 tage, wenn man es wirklich hübsch machen will.

[groovemaster]

O'Rakl schrieb:

Hört, hört. -- ja, und ? was willst du uns damit sagen ?

Genau das, was dort steht. Aber nicht uns, sondern nur dir.

O'Rakl schrieb:

Nein. C++ und C sind nicht voneinander unabhängig

Doch, das sind sie. Schmeiss den C Standard weg, jeglichen C Code und alle C Compiler. C++ wird trotzdem weiter existieren, auch wenn die C Kompatibilitätsgeschichten nicht mehr nutzbar wären. Immerhin leben wir im Jahre 2005 und nicht mehr 1979. Seit "C with Classes" hat sich einiges geändert. Das ist aber nicht der springende Punkt, da C++ eben lange nicht standardisiert und mehr oder weniger eine freie Entwicklung war. Der springende Punkt ist einfach, dass C++ seit Beginn Klassen und somit ein OO Konzept hatte. Genau deshalb entwickelte Stroustrup ja C++. Es ging nicht darum, C eine Klassenerweiterung zu spendieren, sondern eine eigene OO Sprache zu entwickeln. Welche Sprache man als Basis nehmen konnte, war erst die nächste Frage.

O'Rakl schrieb:

C++ hieß ursprünglich "C with classes", das kann dir gefallen oder nicht, es ist nun mal so.

Genau das drückt doch mehr als deutlich aus, dass OO die Grundlage von C++ war und kein "Add-on".

Power Off schrieb:

Tja ... der Fisch stinkt halt vom Kopf her.

Wobei es nicht immer der Kopf sein muss, wenn's nach Fisch stinkt.

O'Rakl schrieb:

Also beenden wir diese Diskussion mit dem Resumé:

Soll jeder mit seiner bevorzugten Programmiersprache glücklich werden.

Ist das jetzt ein Fake? Kann man bei Unregs immer so schlecht beurteilen.

edit:
Kein Grund ausfallend zu werden, Bubi. Immerhin war ja nicht alles falsch.

[Power Off]

(hat sich erledigt)

[ZX81 BASIC]

Ich bin viel besser als C++ und Python zusammen. Bäh! :p

[...]

das amüsante ist ja (habe aber nur ab Seite 15 gelesen):
fast alle versuche, gegen den Standpunkt unseres Orakelchens anzup*ssen,
mündeten in unfreiwillige Belege dafür, daß er im grunde recht hat:
STL+boost (vs. Eleganz), Fehlermeldungen mit 10-zeilen-langen Typbezeichnungen
(vs. Einfachheit), Herkunft von C (vs. originäre OOP-Sprache) ...

[Gast]

... schrieb:

STL+boost (vs. Eleganz)

Ich spreche zwar kaum C++, aber mich würde trotzdem interessieren was in diesem Fall gegen Eleganz spricht.

[part1]

Embedding Python in C/C++: Part I

http://www.codeproject.com/useritems/embedpython_1.asp

[Perl_master]

freakz schrieb:

Perl ist schwer erweiterbar.

nimm ein Perl Programm was ca. 3000-5000 zeilen hat ( was ein anderer geschrieben hat ) und versuch das zu erweitern

Da ist Python wesentlich besser, aber auch das ist bei grösseren Projekten ( ab 5 Entwickler ) zu vergessen.

Wer ein Perlprogramm mit 5000 Zeilen schreibt, gehört schon fast erschossen...
es gibt include files, funktionen oder die OO-Möglichkeiten...

Es liegt am Programmierer selber ob er sauber programmiert oder nicht.

[ronny]

wie lange wollt ihr euch eigentlich noch trollen

bis jetzt wissen wir, das sowohl das vergessen, auch das überloben von c++ ein fehler ist

c++ hat einen platz in der welt des programmierens, wo es noch einige zeit bleiben wird

es einfach so durch python ersetzen zu wollen ist größenwahn in richtung python

ich habe bis jetzt einige sprachen gelernt, und bin der meinung, das c++ sehr gut für bestimmte probleme zu verwenden ist

man muss daran denken, das c++ eine effektivsprache ist, in der man sehr leistungsfähige software schreiben kann, man sollte auf keinen fall auf sie idee kommen sie mit produktivsprachen zu vergleichen
(man sollte aber sehr wohl auf die idee kommen libs zu verwenden, die die produktivität steigern)

da es aber nicht besonders viele produktivitätsframeworks für c++ muss man damit leben, das der line-count für gewisse sachen ganz einfach höher ist

außerdem muss man sich selbst schützen, da übermäßiger schutz durch die sprache laufzeit kosten würde

das ist je nach lage als vor- oder nach-teil anzusehen

aber je nach lage würde ich auch c++ einsetzen, oder nicht

[alex89ru]

Ich schlage mal folgendes vor:
Wir nutzen C/C++ fröhich weiter , und du nutzt pzhon weiter...und wr Bcok auf python hat , soll es nutzen ...wie wär's wenn wir zur Abwechslung mal nicht entscheiden würden , was besser ist...

[ronny]

[............]

aber die C'ler sollen dann bitte nicht irgendwann zu C++ rüberwechseln. gibt nur murks.