Verleitet C++ zum komplizierteren denken?



  • u_ser-l schrieb:

    der Unterstrich bedeutet übrigens

    :=
    

    Und was bedeutet

    :=
    

    ?



  • pairElement _ pairClassName new.
    

    =

    pairElement := pairClassName new.
    


  • u_ser-l schrieb:

    pairClassName := 'Pair' , class1st , class2nd.   "String-Konkatenation"
    pairElement := pairClassName new.
    

    Jo, das ist ganz hübsch und fühlt sich für Smalltalk irgendwie "gut" an.



  • Tim schrieb:

    pointercrash() schrieb:

    Tim schrieb:

    pointercrash() schrieb:

    Das Zeug muß 24/7 funktionieren und das tut es, auch wenn das Grundkonzept pure Prozessorbeschäftigungstherapie ist.

    Welches Grundkonzept denn nun?

    Hast keine Lust mehr, zu googeln?

    Vielmehr kann ich via google nicht herausfinden was genau du mit "Grundkonzept" meinst, "visuelles Softwaredesigntool" oder "SPS" oder was auch immer. Aber lassen wir das.... 🙄

    Und was ist mit Lesen? 🙄 Bei einer zyklusbasierten SPS hast Du nur Polling mit einer Art if(..)- Verzweigung zur Verfügung, das ist das Grundkonzept. Bei neueren SPS kommt das ereignisbasierte Zeug dazu, das aber i.a.R an irgendein tolles Modul gebunden ist, in dem dann z.B. drei Timer drin sind. Die grafischen Konfigurationstools lassen ein System zusammenklicken und parametrieren.

    ;fricky schrieb:

    @pointercrash():
    SPSn finde ich garnicht so doof. wo früher der elektriker seine schützschaltungen mit dicken drähten 'programmierte', hackt er heute seine stromlaufpläne in die SPS rein. die dinger haben schon ihre berechtigung. programmierung (die übrigens weit davon entfernt ist, zu kompliziertem denken zu verleiten) und installation sind halt auf's 'grobe' fachpersonal zurechtgeschnitten. sie sind ausbaufähig, echtzeitfähig, extrem haltbar usw. das passt schon alles.
    🙂

    Ne, stimmt ja alles so nicht mehr. Dem Werkselektriker platzt der Kopf, wenn Du ihn mit nacktem Step-7- Code konfrontierst. Auch ich finde das nicht mehr lustig, wie man Ereignistrigger einstellt, weder direkt gecodet noch mit den Konfig- Tools. Oft genug stellst Du nach zwei, drei Stunden fest, daß Du genau das Ereignis, das Du brauchst, mit dem Modul nicht herstellen kannst. Tadaa, bettel' den Hersteller an, das reinzumachen.

    Robust, ja das sind sie, ideal für Volltrottel, die einen Drehstromanschluß von einem Signalkabel nicht unterscheiden können. Ausbaufähig ja auch, problemlos mit voller Kasse. Echtzeitfähig aber nur in absolut beschämendem Rahmen im Vergleich zur "natürlichen" Power der darin verbauten Prozessoren.

    Wer den Overhead von C++ bemäkelt, sollte sich wirklich überlegen, sich argumentativ vor das SPS- Konzept zu stellen.

    Btw. Siemens hat ja so 96/97 seine erste Soft- SPS auf Basis von Win CE 1.0 als Revolution vorgestellt. Revolutionär daran war, daß es endlich auch SPSsen gab, die gnadenlos abstürzten. Ob letztlich WinCE dran Schuld war oder Siemens mit dem SPS- Teil danebengelangt hat, weiß ich nicht, ich weiß nur, daß ein Kunde die Dinger zwar getestet und dann "wegen massiver technischer Unsicherheit" den produktiven Einsatz untersagt hat.



  • Seite 35 schon! 😮 Ihr denkt schon wieder viel zu kompliziert. Das kommt sich vom vielen C++. :p



  • volkard schrieb:

    Jo, das ist ganz hübsch und fühlt sich für Smalltalk irgendwie "gut" an.

    hier ein konkreter Beispielcode, der, so wie er da steht, direkt in einem Workspace ausführbar ist.
    Mit der Vereinfachung, daß die vorhandenen Klassen 'ByteString' und 'SmallInteger' statt 'Polar' und 'Line' verwendet werden:

    | a b l |
    
    Object subclass: #PairSmallIntegerByteString
    	instanceVariableNames: ''
    	classVariableNames: ''
    	poolDictionaries: ''
    	category: ''.
    
    Object subclass: #PairSmallIntegerSmallInteger
    	instanceVariableNames: ''
    	classVariableNames: ''
    	poolDictionaries: ''
    	category: ''.
    
    Object subclass: #PairByteStringByteString
    	instanceVariableNames: ''
    	classVariableNames: ''
    	poolDictionaries: ''
    	category: ''.
    
    a := #( 1 'abc' 3 ).
    b := #( 'xyz' 'def' 4 ).
    
    l := Array new: 9.  
    
    1 to: (a size) do: [ :i | 
    	1 to: (b size) do: [ :j | 
    		ca := a at: i.
    		cb := b at: j.
    		caS := (a at: i) class asString.
    		cbS := (b at: j) class asString.
    		cS := 'Pair' , caS , cbS.
    
    		Transcript show: 'i = ' , i asString, ' j = ' , j asString , ' : ' , cS; cr.
    
    		index := (i - 1) * (b size) + j.
    
    		l at: index put: cS.
    
    		"newObject := (Smalltalk at: cS asSymbol) new.
    		l at: index put: newObject."
    
    		" die auskommentierte Zeile setzt voraus, dass Klassen 
    			PairByteStringSmallInteger usw.
    			existieren ..."
    		]	
    	].
    
    Transcript show: l asString; cr.
    

    Ausgabe:

    i = 1 j = 1 : PairSmallIntegerByteString
    i = 1 j = 2 : PairSmallIntegerByteString
    i = 1 j = 3 : PairSmallIntegerSmallInteger
    i = 2 j = 1 : PairByteStringByteString
    i = 2 j = 2 : PairByteStringByteString
    i = 2 j = 3 : PairByteStringSmallInteger
    i = 3 j = 1 : PairSmallIntegerByteString
    i = 3 j = 2 : PairSmallIntegerByteString
    i = 3 j = 3 : PairSmallIntegerSmallInteger
    
    #('PairSmallIntegerByteString' 'PairSmallIntegerByteString' 'PairSmallIntegerSmallInteger' 'PairByteStringByteString' 'PairByteStringByteString' 'PairByteStringSmallInteger' 'PairSmallIntegerByteString' 'PairSmallIntegerByteString' 'PairSmallIntegerSmallInteger')
    

    Der Clou befindet sich in den Zeilen

    newObject := (Smalltalk at: cS asSymbol) new.
    		l at: index put: newObject.
    

    Hiermit wird zur Laufzeit zu einem variablen String cS ein Objekt erzeugt, das
    derjenigen Klasse angehört, deren Name cS ist.



  • auch das gefecht von u_ser_1 und volkard, wie nun eine optimale oop-lösung usw. aussehen soll, ist doch interessant, oder nicht?

    Um ehrlich zu sein ... nein.



  • Wieso? Dieser kryptische smalltalk code macht mich ganz wuschig.


Anmelden zum Antworten