globale variablen

[Wolfgang Roller]

Hallo,<p>

Hagen hat Recht. Da C# nichts anderes als Java unter Microsofts Deckmäntelchen ist und absolut fast nichts neues enthält, was nicht Java auch schon hätte, verhält es sich in dieser Beziehung vermutlich genauso.<p>
Während eines Java-Kurses im Januar diesen Jahres hat sich ein Kollege kurz mal einen der vielen zum Download bereit stehenden Java-Decompiler heruntergeladen und ihn auf unsere und andere in Java Bytecode vorliegende Dateien losgelassen. Das Ergebnis war verblüffend. Es fehlen zwar die Kommentare und die lokalen Variablen werden nach einem Schema durchnummeriert, aber ansonsten wunderbarer Quellcode, der sofort mit dem Compiler erneut fehlerlos übersetzt werden konnte.<p>
Solange man eine Server-Applikation hat und die Clients lediglich kleine Java-Applets zu sehen bekommen, ist das alles kein Problem. Aber ich würde nicht gerne eine komplette Applikation in Java oder C# ausliefern wollen.<p>
Natürlich gibt es auch ein Mittelchen dagegen, das diese Schwäche etwas mildert. Beim Entwickeln werden wir Programmierer immer angehalten sprechende Klassen- und Methodennamen zu verwenden. Das ist in diesem Fall natürlich eher schlecht. Damit man diese löbliche Gewohnheit nicht aufgeben muß, gibt es sogenannte "Scrambler bzw. Obfuscatoren", die vor der Auslieferung aus den schönen sprechenden Namen wirre Bezeichnungen machen, so daß nun im decompilierten Quellcode sich der Sinn nicht mehr so leicht erschließen lassen soll.<p>
So hat eben jede Technologie auch ihre Schattenseiten.<p>
Gruß<p>
Wolfgang Rolle

[Andreas Kosch]

Hallo,

@Hagen: Das Pascal von Wirth hat mit dem Object Pascal nur eine gewissen Ähnlichkeit, ausserdem steckt bei Borland Pascal 7/Delphi das KnowHow ja in der OWL bzw. VCL (diese Teile spielten bei Wirth keine Rolle).<br>
Microsoft hat <b>nicht</b> mehr die absolute Kontrolle. Seit Mitte Oktober hat das OPEN SOURCE-Projekt <i>Mono</i> (http://www.go-mono.com) das erste .NET-Programm fertig, dass unter <b>Linux</b> läuft. Neben dem C#-Compiler haben die dort auch die CLR-Runtime sowie ein Teil der Klassenbibliothek portiert. Die WinForms von Windows werden nach GTK+ umgesetzt und als Ersatz für ADO.NET setzt Mono auf die Treiberschicht GNOME-DB.

@Wolfgang: C# enthält durchaus Neues gegenüber Java, die verschiedenen Väter schimmern durch:<br>
C++ Erbe: Syntax, Overloading, Präprozessor, Zeiger (unsafe code)<br>
Java-Erbe: Einfachvererbung, Interfaces<br>
VB-/Delphi-Erbe: Komponenten, Properties, Events<br>
VB-Erbe: For Each-Schleife<br>
Delphi-Erbe: Klassen der CLR :-)<br>
<b>Und das Ganze ist im Gegensatz zu Java optimal an Windows angepasst.</b>

Das wirklich Neue an .NET liegt darin, dass die Sprachunterschiede verschwinden. Ich gebe zu, dass es für die C/C++ Leute ein Schock darstellt, wenn die VB-Leute auf einmal "gleichwertige" Partner sind, solange alle für .NET entwickeln. Anders Hejlsberg hat in einem Interview gesagt, dass C# und VB.NET von der Leistungsfähigkeit zu 99% identisch sind (nur die Syntax unterscheidet sich). Da Microsoft in <i>Visual Studio .NET</i> die Auswahl von Managed C++, C# und VB.NET anbietet und die Sprachen auch gemischt werden dürfen (ohne Profiler und Debugger zu irritieren), wird sich dieses Konzept durchsetzen.

P.S: Es ist erstaunlich, wie viele Entwickler trotz OPEN SOURCE-Rummel immer noch ihren Sourcecode verstecken wollen :-)<br&gt

[Gesine Kuhlmann]

Hi,

C# ist definitiv alter Wein in neuen Schläuchen. Früher nannte man soetwes schlicht Interpreter. Aber Keller heist heute ja auch Basement. Und es tut sich natürlich auch ein neues Marketingfeld auf. Wo der Sinn liegen soll, wieder zum Interpreter zurückzukehren, ist mir schleierhaft. Auch JAVA, wo MS diesmal abgepinnnt hat, konnte das noch nicht hinreichend belegen. Deshalb ist der seit Jahren postulierte Siegeszug von JAVA bisher auch ausgeblieben. Aber irgendwie passt das doch zu MS wie die berühmte Faust auf's Auge. Da können Sie doch wieder jahrelang behaupten: Mit C######### wird aber alles gut ;-). Oder: Wir waren's nicht, deine Hardware passt leider nicht. Oder: Kauf' alle Produkte von uns, die passen auch am besten in 'unsere' Umgebung usw.

Niklaus Wirth stehen heute noch die Haare zu Berge, wenn er sich TP/Delphi anguckt. Das das was er mit Pascl im Sinn hatte, kaum etwas mit den Borland-Produkten zu tun hat erkennt man sofort, wenn man seine persönlichen Weiterentwicklungen <b>seiner</b> Programmiersprache anschaut.

Das Beispiel von Jens ist dieser Form natürlich absolut sinnlos. Mit einer kleiner Erweiterung, wird es aber zu einem Objekt, welches die wesenlichsten Punkte der Objektorientierung ( Blackbox, defensiver Programmierstil ) aufzeigt:

<pre>
TGlobInteger = class(TObject)
private
FGlobInt : Integer;
procedure WriteGlobInt( NewInt: Integer );
public
property GLobInt : Integer read FGLobInt write WriteGlobInt;
end;
...
var
GlobInteger : TGlobInteger;
implementation
...
initialization
GlobInteger:=TGlobInteger.Create;
finalization
GlobInteger.Free;
end.
...
procedure TGlobInteger.WriteGlobInt( NewInt: Integer );
Begin
if ( NewInt > 0 ) and ( NewInt < 11 ) then
FGlobInt := NewInt
else
ShowMessage( 'Ungültiger Wert' );
end;
</pre>

Gruß
Gesin

[Andreas Kosch]

Hallo Gesine,

&gt;Deshalb ist der seit Jahren postulierte Siegeszug von JAVA bisher auch ausgeblieben

genau das ist der Punkt. Java hat sich auf den Desktops nicht durchgesetzt, weil die am meisten verbreitete Zielplattform (Win32) nur stiefmütterlich unterstützt wurde (Java-Prinzip des kleinsten gemeinsamen Nenners). Im Gegensatz dazu steht bei .NET zuerst die Sprachunabhängigkeit an 1. Stelle und die Plattformunabhängig dafür nur an 2. Stelle (das Betriebssystem entscheidet somit auch bei .NET über die Leistungsfähigkeit der Anwendung mit). Wir dürfen also die Vorteile (Garbage Collector, bequeme Thread-Synchronisation, Attribute-basierende Programmierung usw.) ausnutzen, ohne uns den Nachteil einzuhandeln, dass die Anwender meckern, weil das Ergebnis nicht mehr wie die gewohnten Windows-Programme aussieht.
&#10

[Klaus-Peter Fitzner]

Hallo,

vielleicht noch mal zu dem Thema Globale Variablen. Ich halte es auch so, wie Hagen schon sagte. Die, die ich im ständigen Zugriff von verschiedenen Units aus haben will, werden in einer eigenen Unit global definiert. Bspw. akt_User, akt_PLZ, akt_Ort. Das gibt natürlich den Vorteil, daß ich überall nur den aktuellen Ort über die Variable akt_Ort abgreifen kann. Das setzt natürlich voraus, daß kein Namenskonflikt z.B. mit Windows- oder Delphi-Namen entsteht. Und ich glaube hier liegt auch das generelle Problem der Gefährlichkeit dieser Variante. Wenn ich meine Variable "CurrencyFormat" nenne, kann sich jeder den Spaß ausmalen, wenn ich diese benutze.

mfg Klaus-Pete

[Gesine Kuhlmann]

Hi Andreas,

Sun musste MS 1997 verklagen, damit Java durch <b>von MS</b> künstlich geschaffene Inkompatibilitäten nicht die Win32-Plattform verliert. Deshalb wurde MS dann auch richterlich verdonnert W98 entsprechend anzupassen. Von stiefmütterlicher Unterstützung seitens Sun also keine Spur. Eher frage ich mich, was denn dagegen sprach Windows intern -also ohne die von Sun festgelegten Schnittstellen zu verletzen- auf die Anforderungen von Java hin zu optimieren ???

Das lässt dann den Schluss zu: <i>Du sollst keinen König haben, neben mir</i>. So ist C# ein Kind, welches zwar erst vor kurzem aber genau in diesem Zusammenhang geboren wurde. Mit C# muss man nämlich keine Rücksicht mehr auf irgendwelche Konkurrenten nehmen, sondern kann wieder sein eigenes Süppchen kochen. Wenn man dann noch ein wenig in der hervorragenden Marketingküche von MS rührt, ist der Erzrivale Sun mit seinem Java innerhalb kürzester Zeit erledigt. Ob diese asbach-uralte MS-Taktik ein weiteres Mal funktioniert, sei mal dahingestellt.

Da Java und C# prinzipbedingt mit den gleichen Schwierigkeiten zu kämpfen haben, wird noch viel Wasser bei Blohm&Voss vorbeifliessen, bis man aus einer der beiden Techniken immanente Vorteile ziehen kann.

Gruß
Gesin

[Hagen Reddmann]

Nochwas. Wenn das was MS mit JAVA abgezogen hat funktionierte dann müsste das doch auch mit C#, .NET gehen ?? Zum Schluß muß ich als Coder auspassen oder solange warten bis Borland die neuesten Änderungen am Compiler gemacht hat, damit die absichtlich von MS eingebauten Unterschiede im JIT-Compiler berücksichtigt werden.

Ich glaube sehr wohl das nachdem MS die Basis von .NET unterstützt sofort und sehr massiv die existierenden COM Objecte der Shell/WinWords/INet usw. durch Windows.NET unterstütz werden. Jo, es brauch ja keine diese zu nutzten, könnte man argumentieren, aber die Verführung ist groß. Finally der Coder erzeugt tweilweise unabsichtlich inkompatibilitäten.

@Klaus-Peter: Wichtig ist immer nie zu vergessen das wir intelligent sind, eine eigenständige Berufsgruppe, und wie bei einem Flugzeugpilot vorrausgesetzt werden sollte das wir unser Handwerk verstehen. Der Verzicht auf globale Variablen wäre meiner Meinung nach ein zu starke Selbstbeschneidung, ich meine nicht nur die globalen globalen Variablen, sondern im Besonderen die globalen Variablen die nur lokal zur Unit gültig sind.

Ich weiß nicht so recht. Die Zukunft könnte so aussehen wie die Delphi VCL. Alles Objectorientiert, will ich mal zwei Zahlen mit Delphi addieren dann muß ich erstmal 15 Objecte erzeugen, bzw. der Compiler macht das völlig transparent für mich (noch viel schlimmer).
Der entstehende Overhead durch die "CCL" ist dann gleichmal 1 Mb per EXE. Also sowas wie man's schon im WEB findet, Objecte und Routinen die ein Bit im Integer setzen, löschen und toggeln !!??

Gruß Hage

[Andreas Kosch]

Hallo Gesine,

der von Sun angestrengte Prozess 1997 richtete sich gegen <i>Microsoft Visual J++ 6.0</i> (die erste Entwicklungsumgebung, die Anders Hejlsberg bei seinen neuen Brötchengeber konzipiert hat). Da im Original-Java sogar eine MessageBox gefehlt hat, musste VJ++6 massiv nachrüsten (um überhaupt in der Win32-Welt akzeptiert zu werden). Zwar hat Microsoft den Prozess verloren, aber damals das Recht zugesprochen bekommen, selbst etwas Java-ähnliches zu entwickelen, solange nicht die Zeichenkette "Java" draufsteht.

Die Sprache (C#) ist aber nicht das Wichtige, sondern der wirkliche Nutzen liegt im <B>Framework</b> - also den Klassen, die auf die CLR aufsetzen und die unser Leben erleichtern sollen. Jeder, der sich in der Vergangenheit über den Wildwuchs bei den Win32-API-Funktionen oder der Schwierigkeit von COM beschwert hat, findet nun im Framework eine objektorientierte Programmierschnittstelle vor. Und wenn man sieht, welche Funktionalität zum sofortigen Einsatz bereitliegt, stellt man sich dann doch die Frage, warum man das nicht nutzen und statt dessen wieder alles von Hand schreiben sollte.

Als Beispiel kann ich hier nur wieder mein bereits genanntes SOAP-Beispiel anführen. Während man bei Delphi 6 sowohl beim Server als auch beim Client extra Komponenten konfiguriert und das Interface von Hand schreiben muss, reicht bei .NET sowohl beim Server als auch beim Client <b>eine einzige zusätzliche</b> Programmzeile aus. Somit kann jemand SOAP nutzen, ohne auch nur eine blasse Ahnung über die dahinter liegenden technischen Details haben zu müssen. Ich vergleiche das immer mit der Entwicklung in der Elektronik. Im Jahr 1978 habe ich noch einen NF-Verstärker gebaut, der aus diskreten Bauteilen bestand. Man musste Schaltungen lesen können, eine Leiterplatte malen, ätzen, bohren und bestücken - um dann von Hand die Gegentakt-B-Endstufe auf einen klirrfaktorfreien Arbeitspunkt einzustellen. Nur 2 Jahre später gab es einen schwarzen Plastikwürfel mit Kühlblech und 6 Beinchen (2 Strom, 2 Lautsprecher, der Rest Input), so dass jeder (ohne diese speziellen Kenntnisse) das Gleiche viel schneller und besser zusammenbauen konnte (und Kurzschluss- und Überlastungsfest war das dank der integrierten thermischen Sicherung auch noch). Genau das passiert zur Zeit mit .NET in unserer Branche....

[Hagen Reddmann]

@Andreas, werden denn dann die verschiedenen .NET Versionen für Windows,Sun,Linux identische Funktionalitäten aufweisen MÜSSEN ?? Oder ist eine Anwendung die z.B. mit/für das Windows.NET entwickelt wurde auch abhängig vom Windows.NET ??

Gruß Hage

[Andreas Kosch]

Hallo Hagen,

.NET unterliegt <b>nicht</b> dem Prinzip des kleinsten gemeinsamen Nenners. Die einzige feststehende Voraussetzung ist, dass alle beteiligten Sprachen der CLS (Common Language Specification) entsprechen. Die CTS-Spezifikation (Common Type System) definiert die unter .NET verwendbaren Datentypen, wobei allerdings zwischen Pflicht und Kür unterschieden wird. Jede .NET-Sprache muss mindestens die von der CLS vorgeschriebenen Datentypen unterstützen, darf aber optional zusätzlich die in CTS deklarierten Typen unterstützen. Durch diese Unterteilung wird es möglich, dass ca. 20 Sprachen .NET-fähig gemacht werden können (Eiffel, Cobol, Smalltalk, Python, Perl usw.), wobei dies allerdings auch bedeutet, dass nicht jede Sprache im Detail gleichwertig sein muss.

Das Gleiche gilt für das Framework und die Betriebssysteme. Mit .NET wird ein Minimum definiert, wobei jeder Anbieter seine Implementationen eigenständig erweitern darf (damit der Entwickler sein Produkt, und nicht das der Konkurrenz kauft). Somit wird eine .NET-Anwendung unter Windows mehr können als unter Linux. Im Gegensatz zu Java gilt für .NET der Spruch "Einmal geschrieben - läuft überall" nicht. Statt dessen müsste der Spruch etwa "Wenn ich mich freiwillig auf den kleinsten gemeinsamen Nenner beschränke, könnte es überall laufen" lauten. Dieses Problem haben wird ja bereits heute mit Delphi 6 und Kylix 1 - nur wenn ich mich in Delphi 6 auf die Beschränkungen der CLX einlasse, erhalte ich ein Projekt, dass auch unter Kylix 1 für Linux compiliert werden kann. Wenn ich diese Linux-Kompatiblität jedoch nicht benötige, kann ich mit Delphi 6 und der VCL eine Anwendung schreiben, die viele Win32-Features gezielt ausnutzt

[Gesine Kuhlmann]

Hi Andreas,

Der Prozess richtete sich nicht nur gegen VJ++, sondern alle Produkte mit Java-Technologie. So insbesondere auch W98, wo Teile des JNI weggelassen wurden. Da stellt sich doch sofort die Frage, warum ich etwas weglasse. Ohne viel Phantasie bemühen zu müssen, kommt man schnell darauf, das dieses eine gezielte torpedierung der Plattformunabhängigkeit und damit des Hauptnutzens von Java ist. Deshalb wurde MS verknackt, W98 IE und VJ++ innerhalb von 90 Tagen entsprechend nachzurüsten oder ganz auf JAVA zu verzichten.
Man kann das natürlich auch so wie du formulieren: <i>...MS das Recht zugesprochen bekommen hat, etwas eigenes zu etwickeln</i> ;-)

Sollte C# nun wirklich dass so oft von MS versprochene Ei des Kolumbus sein, dann stehe ich beim Gratulieren in der ersten Reihe. Da es z.Zt. aber eher ein ungelegtes Ei ist, halte ich mir möglichst alle Türen offen und versuche Applikationen so plattformunabhängig wie nur möglich zu halten. Dank Kylix/CLX wird das auch immer einfacher.

Gruß
Gesin

[Andreas Kosch]

Hallo Gesine,

es geht doch nichts gegen ein gepflegtes Streitgespräch :-)

Bei dem damaligen Streit wurde Microsoft gezwungen, sein <i>Viual J++ 6.0</i> so zu ändern, dass immer dann eine Compiler-Meldung angezeigt wurde, wenn der Entwickler auf eine Microsoft-Erweiterung von Java zurückgegriffen hat. Das führte bei der Entwicklung einer Anwendung, die nur für den Einsatz unter Win32 vorgesehen war, selbstverständlich dazu, dass <b>ständig</b> diese Meldungen angezeigt wurde (d.h. ein vernüftiges Arbeiten war nicht mehr möglich). MS musste daher VJ++ 6 als solches beerdigen (weil niemand mehr damit arbeiten wollte) - unabhängig davon, welche anderen Nachrüst-Aktionen bei den Laufzeitbibliotheken notwendig wurden. Der Prozess hat aber auch zu der Klarstellung geführt, dass SUN nicht die absolute Kontrolle (Monopol) über die Sprachmerkmale von Java hat. Jede Software-Firma darf etwas eigenes entwickeln (und sei auch noch so ähnlich mit Java), solange nicht die Zeichenkette "Java" drauf steht.

Für uns spielt das aber keine Rolle, da wir immer 2 Optionen haben: <br>
1. Original-Java, wenn die Plattformunabhängigkeit das primäre Ziel ist ("Einmal schreiben - überall laufen"), oder<br>
2. .NET, wenn die Anwendung speziell für Win32/Intranet/Internet geschrieben wird und man auf die bequemen, vorgefertigen Klassen und Komponenten aus dem .NET-Framework zugreifen will.<br>
Im Fall 1 <b>müssen</b> wir die Sprache Java verwenden/lernen, im Fall 2 <b>dürfen</b> wir uns eine Sprache aussuchen, die uns zusagt. Im Idealfall (wenn Borland unser vertrautes Object Pascal zu einer .NET-Sprache aufbohrt) ist dann nur die Klassenbibliothek neu, die die bisherigen Win32-API-Funktionen objektorientiert einkapselt.
&#10

[Jens Schumann]

Hallo,
Plattformunabhängigkeit ist grundsätzlich eine tolle Sache. Aber ich muß mich z.Z. auf die
Plattform konzentrieren, die mein Marktumfeld verlangt. Und das verlangt ganz klar und
eindeutig Windows. Deshalb befasse ich mich seit ca. 2 Wochen nebenbei .net und C#.
Je länger ich mich damit beschäftigte desto interessanter und gei... finde ich dieses Gespann.
Gerade der Punkt WebServices (ob die Welt jemals sowas braucht ist eine andere Diskussion)
ist dort extrem einfach gelöst. <br>
Ich würde viel lieber weitherhin mit Delphi arbeiten. Aber die sog. Plattformunabhängigkeit
(Windows o. Linux bei zwei Plattformen von Plattformunabhängigkeit zu sprechen ist ziemlich gewagt)
hat D6 soviele Bugs beschert, das es z.Z. nicht zu gebrauchen ist. (Hoffentlich kann mich
jemand vom Gegenteil überzeugen).<br>Jens Schuman

[Andreas Kosch]

Ich kann es nicht (.. vom Gegenteil überzeugen)

[Gesine Kuhlmann]

Hi Andreas,

Stimmt ;-).

Ich glaube es ging lediglich darum, die Defaulteinstellungen so zu ändern, dass man nicht <b>automatisch</b> MS-Erweiterungen nutzt. Wenn MS dann die Umstellung des Standards als zu schwierig für die Zweizeilen-Entwickler betrachtet und deshalb das ganze Projekt einstampft, dann haben die doch selber Schuld.

Drittens haben wir natürlich auch die Möglichkeit mit Delphi/CLX zu entwickeln.

An Jens:
Du hast natürlich Recht, dass 2 Plattformen die minimalste Form der 'Plattformunabhängigkeit' darstellt. Ich finde es aber ganz beruhigend, zumindestens einen Ersatzwagen in der Garage stehen zu haben. Im übrigen wurde bisher über jede neue Delphi Version und der damit einhergehenden Bugs gequakt. Borland hat letztendlich aber immer durchweg brauchbare und stabile Lösungen abgeliefert. Ich kenne im Gegensatz dazu Entwicklungsumgebungen, bei denen dir der Kaffee hochkommt ( z.B. CA Visual-Object ).

Gruß
Gesin