Threads!

Super cool! und vielen Dank! obwohl mir doch jeden Tag klarer wird was jave doch für eine schöne Standardisierte Sprache ist.

Mal noch eine Frage: Warum wird den in der ganzen Kernel Ecke und wenn es um Systemnahe Funktionen wie Threads geht immer noch mit diesem fürchterlichen c-Krams rumgemacht. Es ist wohl noch ein wenig performanter als c++ und keiner hat wohl Lust den gesammten Linux Kernel umzu schreiben, aber langsam könnte man sich doch mal der OOP Richtung zu wenden. Wenn ich so ein langen c code Anschauen muss wird es mir in der Magengegend doch ein wenig übel. Wie schlecht der code alleine schon lebar ist alles durcheinander da keine gekapseten Objekte, viel mehr code als in einer Hochsprache, keine Schachtelungen von Funktionen => absolut ungeschmeidig. Und das schlimmste daran ist: Die Leute sn der Uni fahren total drauf ab: Statt mit Objekten und so genialen Errungenschafften wie streams etc. zu arbeiten wird lieber Systemnahe programmiert.

Sorry fürs abschweifen aber das musste einfach mal raus.

rüdiger

Naja der Kernel ist schon ganz sauber programmiert IMHO, in der Kernel Mailinglist FAQ steht aber warum C anstelle C++

Martin G

Original erstellt von <heiner>:
**Super cool! und vielen Dank! obwohl mir doch jeden Tag klarer wird was jave doch für eine schöne Standardisierte Sprache ist.

Mal noch eine Frage: Warum wird den in der ganzen Kernel Ecke und wenn es um Systemnahe Funktionen wie Threads geht immer noch mit diesem fürchterlichen c-Krams rumgemacht. Es ist wohl noch ein wenig performanter als c++ und keiner hat wohl Lust den gesammten Linux Kernel umzu schreiben, aber langsam könnte man sich doch mal der OOP Richtung zu wenden. Wenn ich so ein langen c code Anschauen muss wird es mir in der Magengegend doch ein wenig übel. Wie schlecht der code alleine schon lebar ist alles durcheinander da keine gekapseten Objekte, viel mehr code als in einer Hochsprache, keine Schachtelungen von Funktionen => absolut ungeschmeidig. Und das schlimmste daran ist: Die Leute sn der Uni fahren total drauf ab: Statt mit Objekten und so genialen Errungenschafften wie streams etc. zu arbeiten wird lieber Systemnahe programmiert.

Sorry fürs abschweifen aber das musste einfach mal raus.**

Das gehört zwar eigentlich nicht in diesen Thread, aber da du dieses Thema schon mal angesprochen hast: Ich habe schon jede Menge in ANSI-C programmiert (sowohl hardware-nahe Programme als auch völlig systemunabhängige Berechnungsprogramme) und mir von einiger Zeit mal C++ und Java angeschaut. Ich kann (für die Programme, die ich schreibe) beim besten Willen nicht den Vorteil entdecken. Was ist z.B. an

System.out.println("Hello!");

einfacher als an

printf("Hello!\n");

Oder was ist an

len = mein_string.length();

besser lesbar als

len = strlen(mein_string);

Umgekehrt ist bei ANSI-C ziemlich klar, was der Compiler aus dem Quelltext macht. Aber was passiert, wenn man bei C++ dynamisch neue Objekte anlegt, die auch Funktionen enthalten? Wird dann neben dem Speicher für die Variablen innerhalb der Objekte auch Speicher für die Funktionen neu belegt, ist also die gleiche Funktion dann mehrfach im Speicher vorhanden?

Nebenbei bemerkt kann man auch mit ANSI-C objektorientiert programmieren. Die GUI-Bibliothek libxview z.B. ist in Standard-C (nicht einmal ANSI-C) geschrieben und trotzdem objektorientiert, d.h. jedes grafische Element - ob Fenster oder Button - ist ein XView-Objekt (alle vom Typ "Xv_object") mit Grundeigenschaften (z.B. Position) und speziellen Eigenschaften (z.B. Fußzeile beim Fenster).

Sicher, für Betriebssystemunabhängige Programme ist Java sicher die bessere Lösung, aber wenn ich bei meinem Linux bleibe, ist mir ANSI-C noch am liebsten.

Martin

rüdiger

die Funktionen werden nicht immer wieder kopiert! Mit C kann man auch OO programmieren, aber versuch das mal in C hinzubekommen

template<class T> class basic_class
{
  T test_;
public:
  inline basic_class(const T& obj) : test_(obj) { }
  inline basic_class(const basic_class<T>& obj) : test_(obj.test_) { }
  inline virtual ~basic_class() { }
  inline const T &test(void) const { return test_; }
  inline void test(const T& obj) { test_=obj; }
  template<class charT, class traits=std::char_traits<charT> > 
  inline virtual basic_ostream<charT,traits> &print(basic_ostream<charT,traits> &out) const 
  { return (out << test_); }
};

template<class T>
basic_class<T> operator+(const basic_class<T>& obj, const basic_class<T>&op)
{
  return basic_class<T>(obj.test()+op.test());
}

template<class T, class A> class derived_class : public basic_class<T>
{
  A atest_;
public:
  derived_class(const A& obja, const T& objt) : basic_class(objt), atest_(obja) { }
  inline void atest(const A& obj) { atest_=obj; }
  inline const A &atest(void) const { return atest_; }
  inline virtual basic_ostream<charT,traits> &print(basic_ostream<charT,traits> &out) const 
  { return (out << atest_ << test_); }
}

template<class A, class T>
derived_class<A,T> operator+(const derived_class<A,T>& obj, const derived_class<A,T>&op)
{
  return basic_class<A,T>(obj.atest()+op.atest(),obj.test()+op.test());
}

C++ hat schon vorteile!

blauton.com

Original erstellt von Martin G:
**
System.out.println("Hello!");

einfacher als an

printf("Hello!\n");

Oder was ist an

len = mein_string.length();

besser lesbar als

len = strlen(mein_string);

**

Schlechtes Beispiel. Schreibe mal den Ansi c-code auf welcher zu diesem Ausdruck äquivalent ist:

string substr = "Hallo";

cout << "Länge des Teilstrings: " << mein_string.substring(mein_string.find(substr), substr.length()) << endl;

Ist zwar auf den ersten Blick nicht einfach zu lesen aber doch absolut vertändlich. String manipulationen zu implementieren ist mit c eine sehr langwierige geschichte, IMHO völlig unakzeptabel.

Oder was hälst du von str1 + str2; //kurz, absolut naheliegend, Perfekt!

Ich weiss nicht warum du gerade ein bsp mit strings genommen hast. Die String Behandlung ist wohl eines der allergrößten Mankos von c.

[ Dieser Beitrag wurde am 10.01.2003 um 16:27 Uhr von blauton.com editiert. ]

[ Dieser Beitrag wurde am 10.01.2003 um 16:31 Uhr von blauton.com editiert. ]

rüdiger

außerdem kann std::string ziemlich genial implementiert werden, so dass es für n gleiche Strings nur 1 Kopie im Speicher gibt! Außerdem sind die Container Klassen super praktisch und Templates generell!

Mr. N

Original erstellt von <heiner>:
obwohl mir doch jeden Tag klarer wird was jave doch für eine schöne Standardisierte Sprache ist.

:o

java ist NICHT standardisiert, ganz im Gegensatz zu C und C++

Solaris'dUKe

Original erstellt von Mr. N:
java ist NICHT standardisiert, ganz im Gegensatz zu C und C++

Wer Standardisiertes Multithreading verwenden möchte kann zu Ada95 greiffen...
Threads sind in Ada ein Sprachbestandteil...
daher -> einmal schreiben, übersetzen unter Windoof, Unix, bis hinunter zum Motorola..

nman

Shit - "Stromausfall" beim Schreiben hat meinen letzten Post zunichte gemacht, also nochmal:

Original erstellt von kingruedi:
außerdem kann std::string ziemlich genial implementiert werden, so dass es für n gleiche Strings nur 1 Kopie im Speicher gibt!

Aber nur bei singlethreaded Anwendungen.

Außerdem sind die Container Klassen super praktisch und Templates generell!

Ja, auch so unscheinbare Dinge wie vernünftige "const"s sind recht praktisch; und den Vorteil der Verwendung von Klassen wird wohl auch niemand leugnen...

Dennnoch: Der größte Teil des Linux-Kernels ist wirklich schön - perfekt dokumentiert, kleine spezialisierte Funktionen, aussagekräftige Namen; sowas liest sich einfach wie von selbst wenn man an den "richtigen" Stellen beginnt.
(Obwohl ein LinuxKernel im "schönen standardisierten" Java sicher noch besser wäre... :p)

rüdiger

const gibt es auch in C :p

nman

Original erstellt von kingruedi:
const gibt es auch in C :p

Ja aber ziemlich verstümmelt, darum habe ich auch geschrieben "vernünftige consts".

rüdiger

Was ist an denen schlecht?

nman

Naja, zB sowas:

temp.c

int main(void)
{
        const int size = 16;
        int anArray[size];

        return 0;
}

nman: ~ > gcc -o /dev/null -ansi -pedantic temp.c
temp.c: In function `main':
temp.c:4: warning: ANSI C forbids variable-size array `anArray'
nman: ~ >

rüdiger

-ansi prüft wohl nach dem alten C89 Standard. Benutz lieber -std=c99

nman

Oh, das wusste ich nicht; ich programmiere so gut wie nie in C.
Allerdings erkennt mein gcc -std=c99 nicht:

nman: ~ > gcc -o /dev/null -std=c99 -pedantic temp.c
cc1: unknown C standard `c99'
temp.c: In function `main':
temp.c:4: warning: ANSI C forbids variable-size array `anArray'
nman: ~ >

Laut info:gcc sollte es zumindest so gehen:

gcc -o /dev/null -std=iso9899:1998 -pedantic temp.c

,das resultiert aber in der gleichen Fehlermeldung...

rüdiger

Welche Version hast du den (gcc -v)? Ich würde mal eine neuere installieren

nman

*g* Ich brauche keine Compilerausgabe, um zu wissen, dass ich noch immer gcc-2.95.3, (gentoo-revision 8 ) habe, ich stelle mein System erst mit KDE-3.1 stable komplett auf gcc3.2 um, immerhin muss ich dann sowieso alles rekompilieren und ich möchte nicht schon wieder ein 3.0.5er KDE kompilieren wenn 3.1 schon so nahe ist...
Aber ich dachte, dass auch der 2.95er gcc C99 kann, der ist immerhin 1999 rausgekommen und C99-Drafts hats damals auch schon gegeben, oder?

rüdiger

wahrscheinlich unterstützt der noch nicht alle Features so gut. gcc 3x lohnt sich auf jeden Fall!

nman

Original erstellt von kingruedi:
wahrscheinlich unterstützt der noch nicht alle Features so gut. gcc 3x lohnt sich auf jeden Fall!

Eh, ich freu mich ja auch schon ziemlich drauf, schon alleine wegen der besseren Einhaltung des ISO-C++-Standards und der tollen Optimierung, aber momentan habe ich leider keine Zeit, alle Fehler zu beheben, die beim "emerge -e world" wahrscheinlich auftreten werden...