3. Verleitet C++ zum komplizierteren denken?

Verleitet C++ zum komplizierteren denken?

  • ?

    pointercrash() schrieb:

    ,fricky schrieb:

    kein normales messer, sondern so eins: http://www.swiss-army-knife-wenger.co.uk/wenger_giant_swiss_army_knife_2.jpg

    Wenistens ist der Hersteller so ehrlich, zuzugeben:

    it is just TOO BIG for practical use.

    tja, passt doch. *fies grins*
    🙂

    0
  • A

    knivil schrieb:

    Hier in Potsdam gibt es das HPI, wo vorwiegend nur mit Java und C# programmiert wird.

    Hihi, ich bin Schüler in Potsdam und wollte nächstes Schuljahr im HPI etwas Info machen. Bitte sag nicht, dass die kein C++ und nur C#/Java machen!! 😞 NAAAAIIN!!!!

    0
  • V

    Ad aCTa schrieb:

    Hihi, ich bin Schüler in Potsdam und wollte nächstes Schuljahr im HPI etwas Info machen. Bitte sag nicht, dass die kein C++ und nur C#/Java machen!! 😞 NAAAAIIN!!!!

    Finde es selber raus.
    http://www.hpi.uni-potsdam.de/studium/lehrangebot.html
    Aber ist egal. An Hochschulen hat man immer ein seltsames Gemisch von Vorlesungen, manche sind aktuell, manche vermitteln Stoff, der seit 30 Jahren nicht mehr aktuell ist. Du mußt Dich selber um viele Sachen außerhalb der Hochschule kümmern, das Programmieren-Lernen gehört schon immer zu diesen Sachen. Am besten vor dem Studium.

    0

  • Ich finde eher, dass alle OO-Programmiersprechen mehr zum vereinfachten Denken verleiten, da spielt es keine Rolle ob C++ C#, Delphi oder Java.
    Ich habe jahrelang in Assembler (6502, 68000, 8086), CBM Basic V2, Pascal und C programmiert, alles Sprachen, die noch kein OO beherrschten (ok, TP6 konnte das, aber das hab ich seinerzeit nie benutzt). Der Umstieg auf C++ war für mich schwierig, weil ich meine bis dahin erworbene Vorgehensweise nach ca. 12 Jahren teilweise umstellen musste, aber es hat sich gelohnt, denn vieles hat sich dadurch erheblich vereinfacht. Die ganze Verwaltung ist wesentlich einfacher zu implementieren.
    Wer das nicht glaubt, braucht ja nur mal mit der WINAPI in C zu arbeiten. All die ganzen Datenstrukturen, Handles, usw. die man mühevoll immer mitschleppen muss, kann man wunderbar in Klassen kapseln, was u.a. ja auch die ganzen Klassengerüste wie VCL, MFC, usw. eindrucksvoll beweisen.

    Bei einen Microcontroller reicht es ja auch meistens aus, diesen in Assembler oder C zu programmieren, weil man solch hohe Anforderung an diesen meist gar nicht stellt. Warum sollte ich mir ein kompliziertes Klassengerüst erstellen, um z.B. nur mal 8 Eingangssignale seriell zum PC zu übertragen?

    Für was man sich letztendlich entscheidet, ist entweder Geschmacksache oder vom Kunden vorgegeben. Heute kann man ja aus einen riesigen Pool von kostenlosen Programmiersprachen wählen, in den 80'er war es richtig teuer, z.B. mal einen C- Compiler für den Amiga zu bekommen.

    Es kommt eben darauf an, was ich machen will bzw. soll.

    0
  • *

    u_ser-l schrieb:

    Die Smalltalk-VM ist in Smalltalk formulierbar und kann auf einem Smalltalk-System laufen.

    Das Problem ist nur, daß real existierende CPUs keine Smalltalk-VMs sind!

    0
  • ?

    es ging um Selbsthosting-Fähigkeit. Der Performance-Verlust entsteht in der Praxis nicht, weil Smalltalk einen Translator enthält, der den Code der VM nach C übersetzen kann. Dennoch kann Smalltalk auch auf sich selbst laufen.

    0
  • ?

    Burkhi schrieb:

    Bei einen Microcontroller reicht es ja auch meistens aus, diesen in Assembler oder C zu programmieren, weil man solch hohe Anforderung an diesen meist gar nicht stellt.

    was meinst du wohl, welche anforderungen an die gestellt werden? meistens arbeiten sie 24/7 an ihrer leistungsgrenze, der code muss kompakt, performant, sparsam mit RAM umgehen und 'direkt' sein. solche hohen anforderungen werden an PC-programme fast nie gestellt.
    🙂

    0
  • T

    ,fricky schrieb:

    Artchi schrieb:

    Wenn der Arzt unerfahren ist, wird er auch mit einem Chirurgischem Instrument scheitern.

    trotzdem wird alles können und medizinisches wissen dieser welt, aus einem taschenmesser kein chirurgisches besteck machen. will sagen: der arzt muss selbstverständlich gutes werkzeug haben und nicht seine ganze energie darauf verwenden, schlechtes werkzeug in den griff zu bekommen. sonst heisst es viel zu oft: 'operation gelungen - patient tot'.
    🙂

    Auch wenn es eigentlich sinnlos ist, mit fricky zu argumentieren, aber dennoch: Die Qualität eines Werkzeuges bemisst sich nicht dadurch, wie einfach es zu bedienen ist, sondern was der Profi damit leisten kann.

    C++ ist nicht einfach zu bedienen, aber wenn ich es beherrsche, also eine ausreichende Ausbildung erfahren habe, dann kann ich mit C++ mit einem angemessenen Aufwand die besten Applikationen der Welt machen.

    Um den Vergleich zur Chirurgie zu versuchen: eine Operation mit Hilfe der chirurgischen Werkzeuge (was auch immer gebraucht wird) ist sicher nicht einfach aber das macht eine Operation oder die Werkzeuge nicht grundsätzlich schlecht.

    J*** ist wie ein schweizer Offiziersmesser. Sehr vielseitig und einfach zu bedienen, aber ich möchte nicht, dass ein Artzt mich damit operieren muss 😉 (man verzeihe mein J***-bashing).

    0
  • ?

    tntnet schrieb:

    C++ ist nicht einfach zu bedienen, aber wenn ich es beherrsche, also eine ausreichende Ausbildung erfahren habe, dann kann ich mit C++ mit einem angemessenen Aufwand die besten Applikationen der Welt machen.

    da gebe ich dir recht, was immer auch die 'besten applikationen der welt' (oder von der welt, wie artchi sagen würde) sein mögen. aber leider trifft dein argument auf 99.9% aller sprachen zu, der unterschied liegt nur in der einfachheit der bedienung und dem damit verbundenen aufwand.

    tntnet schrieb:

    Um den Vergleich zur Chirurgie zu versuchen: eine Operation mit Hilfe der chirurgischen Werkzeuge (was auch immer gebraucht wird) ist sicher nicht einfach aber das macht eine Operation oder die Werkzeuge nicht grundsätzlich schlecht.

    so'n operateur braucht erfahrung *und* fachwissen *und* gutes werkzeug. sobald eins davon nicht ausreicht, ist der erfolg der operation gefährdet. sein fachwissen sollte aber zu 99% aus medizinischen kenntnissen bestehen und nicht zu 50% wie mängel der werkzeuge auszugleichen sind.

    tntnet schrieb:

    J*** ist wie ein schweizer Offiziersmesser.

    aber nur ein ganz kleines, mit messerklinge, korkenzieher und vielleicht noch 'ner feile. das war's dann aber schon,
    🙂

    0
  • V

    ;fricky schrieb:

    so'n operateur braucht erfahrung *und* fachwissen *und* gutes werkzeug. sobald eins davon nicht ausreicht, ist der erfolg der operation gefährdet. sein fachwissen sollte aber zu 99% aus medizinischen kenntnissen bestehen und nicht zu 50% wie mängel der werkzeuge auszugleichen sind.

    Es ist nicht automatisch ein Mangel des Werkzeugs, wenn jemand nicht damit umgehen kann. Es ist sogar überall üblich, daß der Laie das Profiwerkzeug nicht ordentlich bedienen kann.
    Sein Fachwissen, sollte natürlich nicht zu 99% aus medizinischen Kenntnissen bestehen, damit fordertst Du ja, daß er nichts anderes können darf.

    0
  • ?

    volkard schrieb:

    Es ist nicht automatisch ein Mangel des Werkzeugs, wenn jemand nicht damit umgehen kann. Es ist sogar überall üblich, daß der Laie das Profiwerkzeug nicht ordentlich bedienen kann.

    nein, eigentlich nicht. korrekter umgang mit irgendwelchem werkzeug ist schnell gelernt. was profi und amateur unterscheiden, ist nicht so sehr das 'wie' er's benutzt, sondern 'was' er damit in der lage ist zu schaffen. dieses 'was' hat mit dem werkzeug selbst nur soviel zu tun, als dass es gutes (und richtiges) werkzeug sein muss, um einen nicht zu behindern.

    volkard schrieb:

    Sein Fachwissen, sollte natürlich nicht zu 99% aus medizinischen Kenntnissen bestehen, damit fordertst Du ja, daß er nichts anderes können darf.

    nee, ich meinte nicht nur, dass er gut in der anatomievorlesung aufgepasst hat, sondern die gesamtheit des wissens, die für eine erfolgreiche OP notwendig ist. die bedienung von schere, skalpell, usw. ist doch das trivialste dabei.
    🙂

    0
  • D

    Burkhi schrieb:

    Ich finde eher, dass alle OO-Programmiersprechen mehr zum vereinfachten Denken verleiten, da spielt es keine Rolle ob C++ C#, Delphi oder Java.
    Ich habe jahrelang in Assembler (6502, 68000, 8086), CBM Basic V2, Pascal und C programmiert, alles Sprachen, die noch kein OO beherrschten (ok, TP6 konnte das, aber das hab ich seinerzeit nie benutzt). Der Umstieg auf C++ war für mich schwierig, weil ich meine bis dahin erworbene Vorgehensweise nach ca. 12 Jahren teilweise umstellen musste, aber es hat sich gelohnt, denn vieles hat sich dadurch erheblich vereinfacht. Die ganze Verwaltung ist wesentlich einfacher zu implementieren.
    Wer das nicht glaubt, braucht ja nur mal mit der WINAPI in C zu arbeiten. All die ganzen Datenstrukturen, Handles, usw. die man mühevoll immer mitschleppen muss, kann man wunderbar in Klassen kapseln, was u.a. ja auch die ganzen Klassengerüste wie VCL, MFC, usw. eindrucksvoll beweisen.

    Assembler macht es einem zwar schwer, aber C?

    // user space
#include "biblio.h"

void* daten = biblioCreateDaten();
HANDLER one = biblioGetOne(daten);

// in biblio.h/biblio.c
struct Daten {
    HANDLER one, two three;
    int foo, bar zar;
    Daten klaus, moriz, jochen;
}

void* biblioCreateDaten();
HANDLER biblioGetOne(void* daten);
// usw.
    0
  • K

    Ich empfinde C++ schon als gutes, chirurgisches Werkzeug. Aber wenn ich ne Magen operiere, dann nehme ich was anderes als fuer das Gehirn, obwohl C++ eine general purpose Programmiersprache ist.

    0
  • ?

    otze schrieb:

    Es soll ein neues Objekt hinzugefügt werden, das auf Basis einer beliebig schwingenden komplexen e-Funktion auf Basis von Polarkoordinaten dargestellt wird. Hierbei ist zu beachten, dass die Funktion periodisch in 2pi ist.
    [...]Unter anderem auch Formen wie Kleeblätter. Ein Algorithmus zur numerischen Berechnung der Schnittpunkte existiert.)
    Ich hoffe, damit habe ich alle möglichen Ausflüchte mit abgedeckt.

    was ist daran problematisch? Man definiert eine Klasse Polar mit Instanzvariablen r und abs, deren Instanzen so initialisiert werden:

    p := Polar new r: f abs: g.

    wobei f und g jeweils Blocks sind (Blocks sind in Smalltalk auch Objekte, können also als Parameter übergeben werde), etwa

    f := [ :phi | 2 * phi ]     "r(phi)"
g := [ :phi | phi sin ]   "abs(phi)"

    Dann bekommt Polar eine Methode zum Berechnen der Schnittpunkte mit einem anderen 'Polar' - so ein Algo soll ja nach Vorauss. existieren:

    p := Polar new r: f abs: g.
q := Polar new r: h abs: i.
p cutWith: q.

    Schließlich braucht man noch eine Plot-Funktion - das ist kein Problem, man variiert t über
    den Definitionsbereich und plottet die Funktionen

    x := p r value: t
y := p abs value: t)
    0
  • ?

    etwas unglückliche Bezeichner gewählt: r ist der Winkel, und phi ist die Laufvariable.

    Mit den üblichen Bezeichnungen phi = Winkel, t = Laufvariable und abs = Betrag
    sähe das so aus:

    p := Polar new phi: f abs: g.
f := [ :t | 2 * t ]     "phi(t)"
g := [ :t | t sin ]   "abs(t)"
p := Polar new phi: f abs: g.
q := Polar new phi: h abs: i.
p cutWith: q. 
x := p phi value: t
y := p abs value: t

    aber das Prinzip ist klar.

    Die Plotroutine wäre dann ungefähr von der Form:

    Polar>>plot
1 to: 2 * (Float pi) by: 0.001 do: [ :t || x y | 
    x :=  (phi value: t) sin * (abs value: t).  "r * cos (phi) "
    y :=  (phi value: t) cos * (abs value: t).  "r * sin(phi)"
    aCanvas plot x: x y: y.
 ].
    0
  • ?

    und hier als Smalltalk-Code, vollständig bis auf den tatsächlichen Algo zum Berechnen
    der Schnittpunkte, der hier nur als leerer proxy repräsentiert ist:

    "neue Klasse Polar ableiten"
Object subclass: #Polar
	instanceVariableNames: 'phi abs'
	classVariableNames: ''
	poolDictionaries: ''
	category: ''

"Methode zum Setzen der instance vars zufügen"

Polar compile: 'phi: aphi abs: aabs phi := aphi. abs := aabs '.

f := [ :t | 2 * t ]   "f(t) = 2*t"
g := [ :t | t sin ]  "g(t) = sin(t)"

"zwei Instanzen erzeugen"

p := Polar new phi: f abs: g.  
q := Polar new phi: g abs: f.

"Methode zum Berechnen der Schnittpunkt mit anderem Polar (nur proxy),
    Rückgabe als Array:"

Polar compile: 'cutWithPolar: aPolar "... calc common points of self and aPolar ..." ^ Array new. '.

"Schnittpunkte von p und q berechnen und als Array ausgeben:"

arrayOfCommonPoints := p cutWithPolar: q.
T show: arrayOfCommonPoints asString.

    Ausgabe:

    #()

    muß man nur noch einen geeigneten Algo für die gemeinsamen Punkte in die
    Methode Polar>>cutWithPolar: einsetzen, ansonsten fertig.

    0
  • V

    🤡 🤡 🤡
    Ich vermisse irgendwie die Geraden, Kreise, Ellipsen und Quadrate.

    0
  • ?

    weiß zwar nicht, wozu so eine Polar/kartesische Gemengelage sinnvoll sein soll, aber dazu bildet man eine Oberklasse "DrawElement" zu Strecke + Ellipsenbogen + Polar; deren Instanzen werden in einem Array gespeichert, das die Eingabe für den Schnittalgorithmus darstellt.

    Geeignete Schnittalgorithmen zwischen den 3 Typen werden ja vorausgesetzt, also geht es nur noch darum, die Vereinigungsmenge aus den einzelnen Schnittpunktmengen zwischen je zwei "DrawElement" zusammenzusetzen, das paßt schon.

    0
  • V

    u_ser-l schrieb:

    weiß zwar nicht, wozu so eine Polar/kartesische Gemengelage sinnvoll sein soll, aber dazu bildet man eine Oberklasse "DrawElement" zu Strecke + Ellipsenbogen + Polar; deren Instanzen werden in einem Array gespeichert, das die Eingabe für den Schnittalgorithmus darstellt.
    Geeignete Schnittalgorithmen zwischen den 3 Typen werden ja vorausgesetzt, also geht es nur noch darum, die Vereinigungsmenge aus den einzelnen Schnittpunktmengen zwischen je zwei "DrawElement" zusammenzusetzen, das paßt schon.

    4 Typen, oder? Ellipsenbogen, Quadrat, Gerade, Polarzeug.
    Wie findest Du aus einem der 16 möglichen eingehende Typtupel den richtigen der 6 Schnittalgorithmen?

    0
  • V

    u_ser-l schrieb:

    weiß zwar nicht, wozu so eine Polar/kartesische Gemengelage sinnvoll sein soll

    Das weiß ich auch nicht. Der Polarkram war nicht wirklich nötig.

    0
Anmelden zum Antworten