Programiersprache für Anfänger

DEvent schrieb:

Im Destruktor sollte man keine externe Resourcen freigeben, denn Destruktor kann nichts im Fehlerfall machen.

das machen c++ progger aber schon seit generationen so. und sie glauben auch nicht, dass dabei was schiefgehen kann. und wenn, dann ist es ihrer meinung nach auch egal.

berniebutt

@ Alle hier: Eure vielschichtige Diskussion hilft dem Fragesteller nicht weiter. Er will nur wissen, mit welcher Programmiersprache er einsteigen soll.
@ Fragesteller: Wähle irgendeine Programmiersprache, für die Du einen Compiler hast. Suche Dir kleine überschaubare Übungsaufgaben und bringe diese zum Laufen. Ein Buch für Anfänger kann sehr hilfreich sein. Sobald Du etwas Erfahrung hast, kannst Du immer noch umsteigen. Auch wenn der Einstieg mit C/C++ anfangs etwas schwierig erscheint, lohnt dies auf Dauer immer.

DEvent

hustbaer schrieb:

DEvent, du solltest nicht über Dinge schreiben von denen du nixe verstehst.

Dann erleuchte mich. Wenn ich Bloedsinn schreibe, dann bitte korregieren, denn nur so lerne ich.

@berniebutt @Fragesteller

Ich wuerde C empfehlen. Ist leicht, hat eine eindeutige Syntax, man lernt was Speicherverwaltung, Abstraktion, Low-Level und OOP bedeutet.

DEvent schrieb:

Ich wuerde C empfehlen. Ist leicht, hat eine eindeutige Syntax, man lernt was Speicherverwaltung, Abstraktion, Low-Level und OOP bedeutet.

die syntax von C ist für anfänger überhaupt ziemlich hart. und oop lernt man mit C auch nicht.

~fricky schrieb:

und oop lernt man mit C auch nicht.

Doch, durch C lernt man erst die Vorzüge & Nachteile einer OOP zu schätzen
und man weiß, warum es sich lohnen kann, sich die OOP anzutun.

Und für den Programmiereinstieg ist eine Prozedurale Sprache immer noch
besser als eine OOP Sprache, weil die prozedurale Sprache weniger Overhead mit sich bringt und der Anfänger viel einfacher sieht, wo das Programm entlang geht.

C is besser schrieb:

~fricky schrieb:

und oop lernt man mit C auch nicht.

Doch, durch C lernt man erst die Vorzüge & Nachteile einer OOP zu schätzen
und man weiß, warum es sich lohnen kann, sich die OOP anzutun.

erzähl doch nicht so'n quatsch. du kannst viele jahre in c programmieren, ohne überhaupt zu ahnen, dass es sowas wie OOP gibt.

DEvent

~fricky schrieb:

C is besser schrieb:

~fricky schrieb:

und oop lernt man mit C auch nicht.

Doch, durch C lernt man erst die Vorzüge & Nachteile einer OOP zu schätzen
und man weiß, warum es sich lohnen kann, sich die OOP anzutun.

erzähl doch nicht so'n quatsch. du kannst viele jahre in c programmieren, ohne überhaupt zu ahnen, dass es sowas wie OOP gibt.

Man kann auch viele Jahre in C++ programmieren ohne zu wissen was OOP ist. Ausserdem, aus mehreren Gruenden, die ich bestimmt nicht nochmal erleutere, kann man in C viel einfacher und sauberer OO programmieren als in C++.

Bashar

DEvent schrieb:

Ausserdem, aus mehreren Gruenden, die ich bestimmt nicht nochmal erleutere, kann man in C viel einfacher und sauberer OO programmieren als in C++.

Dann gib mal bitte ein Link darauf, wo du das schonmal erläutert hast. Dass du in C OOP betreiben kannst, stimmt schon nur für sehr eingeschränkte Vorstellungen von OOP, aber dass das dann sauber ist, kann ich mir gar nicht vorstellen.

DEvent schrieb:

Ausserdem, aus mehreren Gruenden, die ich bestimmt nicht nochmal erleutere, kann man in C viel einfacher und sauberer OO programmieren als in C++.

es hat hier auch mal einer erzählt (übrigens, ein user mit einer 5-stelligen beitragszahl), dass Java kein 'richtiges' OOP unterstützt, auch mit dem hinweis, dass er auf fragen diesbezüglich nicht antworten wird. ich bin wahrlich kein freund von C++, aber dass man in C einfacher OO-programmieren kann, als in C++, halte ich für ein gerücht.

muemmel

Hi,

was spricht eigentlich gegen Delphi als Anfängersprache? Ist doch um einiges einfacher als C++ und ähnliche und wenn man damit klar kommt ists mit C++ auch keine große Hürde mehr. Der Vorteil gegenüber C# und Java ist, daß Delphi eine sich wesentlich mehr von C++ unterschiedende Syntax hat und daher weniger zu verwechslungen beim Umstieg führt.

Gruß Mümmel

DEvent

Bashar schrieb:

DEvent schrieb:

Ausserdem, aus mehreren Gruenden, die ich bestimmt nicht nochmal erleutere, kann man in C viel einfacher und sauberer OO programmieren als in C++.

Dann gib mal bitte ein Link darauf, wo du das schonmal erläutert hast. Dass du in C OOP betreiben kannst, stimmt schon nur für sehr eingeschränkte Vorstellungen von OOP, aber dass das dann sauber ist, kann ich mir gar nicht vorstellen.

Bitte:
http://www.mathematik.uni-ulm.de/sai/ws96/seminar/neher/
http://home.comcast.net/~fbui/OOC.html

Ein Beispiel, wo man ein Feature von OOP sauberer in C programmieren kann als in C++: Kapselung.
In C schreibe ich die oeffentliche Schnittstelle so:

extern const void *STRING;

void *createString();
void deleteString(void* self);
void* copyString(void* self);
char* getString(void* self);
void setString(void* self, char* str);

In C++ sieht das so aus:

class String {
    public:
        String();
        ~String();
        String copyString();
        char* getString();
        void setString(char* str);
// man koennte denken, dass dies genuegen wuerde, aber nein
    protected:
// viele schoene protected Methoden
    private:
// noch mehr Hilfs-Methoden, die im Interface ueberhaupt nichts verloren haben
}

Im Gegensatz zu dem Beispiel mit C ist das oeffentliche Interface "beschmutzt" durch private Methoden und Attribute. Das hat zur Folge, dass der C++ Compiler dir zwar eine Fehlermeldung ausgibt, wenn du versuchst auf diese zuzugreifen, aber du musst trotzdem jedesmal dein gesammtes Programm neu uebersetzen, wenn du irgendwas an den nicht oeffentlichen Teil veraenderst. Ein stabiles oeffentliches Interface muss man sich in C++ durch abstrakte Klassen erkaufen, was virtuelle Methoden erzwingt.

tntnet

DEvent schrieb:

Im Gegensatz zu dem Beispiel mit C ist das oeffentliche Interface "beschmutzt" durch private Methoden und Attribute. Das hat zur Folge, dass der C++ Compiler dir zwar eine Fehlermeldung ausgibt, wenn du versuchst auf diese zuzugreifen, aber du musst trotzdem jedesmal dein gesammtes Programm neu uebersetzen, wenn du irgendwas an den nicht oeffentlichen Teil veraenderst. Ein stabiles oeffentliches Interface muss man sich in C++ durch abstrakte Klassen erkaufen, was virtuelle Methoden erzwingt.

Schon mal was von Pimpl gehört?

Badestrand

DEvent schrieb:

Im Gegensatz zu dem Beispiel mit C ist das oeffentliche Interface "beschmutzt" durch private Methoden und Attribute.

Das stört mich auch seit langem (Heißt aber nicht, dass ich "OOC" besser finde :))

edit @tntnet: Pimpl ist aber auch nicht ohne Aufwand und Einbußen zu haben.

Christoph

DEvent schrieb:

http://www.mathematik.uni-ulm.de/sai/ws96/seminar/neher/
http://home.comcast.net/~fbui/OOC.html

Dazu passt noch:
http://www.cs.rit.edu/~ats/books/ooc.pdf .

asc

DEvent schrieb:

Im Gegensatz zu dem Beispiel mit C ist das oeffentliche Interface "beschmutzt" durch private Methoden und Attribute.

Dafür ist es in C dadurch beschmutzt, das jeder nach belieben auf deinen String zugreifen kann. Und davon abgesehen hat jeder bei C++ die Möglichkeit Funktionen im Anonymen Namensraum in der Sourcedatei zu deklarieren.

Und ansonsten Verweise auch ich auf das Handle-Body Idiom, alias Pimpl.

Badestrand

asc schrieb:

Und ansonsten Verweise auch ich auf das Handle-Body Idiom, alias Pimpl.

Wenigstens die letzten 3 Posts kann man sich ja noch durchlesen

DEvent schrieb:

In C++ sieht das so aus:

class String {
    public:
        String();
        ~String();
        String copyString();
        char* getString();
        void setString(char* str);
// man koennte denken, dass dies genuegen wuerde, aber nein
    protected:
// viele schoene protected Methoden
    private:
// noch mehr Hilfs-Methoden, die im Interface ueberhaupt nichts verloren haben
}

^^ spontan fallen mir zwei möglichkeiten ein, um das zu umgehen:
1. mach dir ne basisklasse mit den hilfsfunktionen. dann sieht man zwar noch, dass die klasse erbt, aber nicht die funktionen selber.
2. freie funktionen mit nem 'static' davor, die man dann aber mit einem 'this' versorgen muss. dann sieht man garnix mehr von den hilfsfunktionen.

Badestrand

~fricky schrieb:

2. freie funktionen mit nem 'static' davor, die man dann aber mit einem 'this' versorgen muss. dann sieht man garnix mehr von den hilfsfunktionen.

Ist aber wertlos, weil du ja keinen Zugriff auf die privaten Variablen hast.

asc schrieb:

Dafür ist es in C dadurch beschmutzt, das jeder nach belieben auf deinen String zugreifen kann.

Wenn das ein Problem darstellt, dann wird es nicht durch die geschickte Wahl einer Programmiersprache gelöst.

sothis_

Ist aber wertlos, weil du ja keinen Zugriff auf die privaten Variablen hast.

die man dann aber mit einem 'this' versorgen muss

:xmas1: