|
Re: Inttostr int C#
Zitat:
Juhu, wir lieben alle prozedurale Methoden, die ungeordnet irgendwo herumliegen, überhaupt keinen Bezug auf ihren Typen haben und die Code-Completion einmüllen. Zitat:
Delphi-Quellcode:
Wozu der Cast :gruebel: ?
Label1.Text := Int32(Convert.ToInt32(TextBox1.Text) * Convert.ToInt32(TextBox1.Text)).ToString;
[edit] Rest siehe phXql :wink: [/edit] Zitat:
Ich glaube, du hast dir das falsche Hobby ausgewählt, du bist jedenfalls in die entgegengesetzte Richtung wie 95% aller Programmierer gepolt. Obwohl, vielleicht bist du auch einfach 20-30 Jahre zu spät dran. |
Re: Inttostr int C#
Hab ich auch schonmal hier gefragt ;) Suche hilfe!
|
Re: Inttostr int C#
Zitat:
|
Re: Inttostr int C#
Nur weil IHR der Meinung seid, prozedurale Programmierung sei schlecht, ist das in der Realität noch lange nicht so!
Das "normale" Win32-Delphi ist im Grunde die perfekte Mischform. Das hat rein gar nichts mit "zumüllen" zu tun, das ist einfache ein effizienter, sehr gut leserlicher Programmierstil. Das ist es schließlich, was Pascal mal ausgemacht hat: Die LESBARKEIT. Die ganze DotNET-Scheisse macht das alles nur kaputt. |
Re: Inttostr int C#
Zitat:
greetz Mike |
Re: Inttostr int C#
Zitat:
Aber: Rein prozeduale Programmierung ist die reinste Folter. Ich muss in der Schule Logo machen (das ist sogar noch deutlich Spur schlimmer, als z.B. C), ich weiß wovon ich rede ;) Da ist man froh, wenn man sich "mal eben" eine Klasse schreiben kann, die Prozeduren dazu rein, und fertig ist's. Das erzeugen der Klasse ist dann nur noch Gewohnheitssache. Wenn ich mir aber vorstellen müsste, alles prozedural zu machen (wie ich es z.T. auch mit Logo tun muss)... :shock: Zitat:
Und das hat Pascal bis heute noch, auch in Delphi.NET. Und nur, weil man mal statt einer Funktion eine Methode aufrufen muss (was deutlich schneller geht, wenn man es einmal kennt), heißt es gleich, dass .NET schlecht ist? :gruebel: :wall: |
Re: Inttostr int C#
Zitat:
Mit DotNET hat Microsoft eine Seuche geschaffen, die fast so schlimm wie Java ist, sich aber wohl leider noch deutlich weiter ausbreiten wird :( |
Re: Inttostr int C#
Zitat:
Java eine Seuche? wenn du meinst *gg* .NET hat seine Vor- und Nachteile. Ok, ich muss ein Framework mitliefern, muss das aber nur einmahlig installieren. Ist bei Applikationen, die bspw. DirectX verwenden genauso. Bloß dass .NET den Vorteil der Plattformunabhängigkeit hat, genau wie Java. (Logisch unter der Voraussetzung, dass es ein Framework installiert ist) Etwas gegen das streng Objektorientierte Konzept zu sagen find ich irgendwie lächerlich. Es dient der Sauberkeit und übersicht. So vermeide ich, dass ich mir meine Units mit wirren Funktionen zumülle, obwohl ich die genausogut in eine Klasse stecken kann. Mit .NET wird man gezwungen, sauberer zu programmieren. Bezüglich langsamer Ausführgeschwindigkeit: Das kann ich stolz bestreiten. Nachdem ich sowohl managed als auch natives DirectX programmiert, als auch diverse Algorithmen von Win32 auf .NET portiert habe kann ich sagen, dass die Ausführgeschwindigkeit sich ca. ausgleicht. Meine mDX-Appls laufen manchmal mit 2-3 Frames langsamer, was aber relativ wenig ausmacht. Andere Dinge liefen in .NET schneller als in Win32. Zudem: Etwas in .NET zu schreiben dauert höchstens gleichlang wie für Win32, geht normalerweise aber schneller. Es ist also eher ein Segen für die Entwickler ;) Aber wie gesagt, du kannst gern bei Win32 bleiben. Wär halt ca. so alsob einer vor Jahren gesagt hätt er würd weiterhin 16Bit-Appl. produzieren :P greetz Mike [edit]Es lebe der rote Kasten, wenner mal kommen würde... kann von mir aus gelöscht werden |
Re: Inttostr int C#
Zitat:
1.) ist .NET verdammt schnell (das zeigen alle Performance-Tests) 2.) ist die Runtime nicht riesig sondern nur 20 MB gross, die Bibliotheken die man für Win32 braucht sind deutlichst grösser und 3.) ist .NET dank seiner Sicherheitsfeatures deutlichst sicherer vor attacken geschützt als jede andere native Applikation. Ich sage hier nur CAS. Und was die lesbarkeit des Compilats angeht: Ich lese lieber Assemblercode als durch einen Obfuscator gejagten IL-Code. |
Re: .NET Diskussion
Ich habe überhaupt nichts gegen .Net.
Ich entwickle jetzt testweise schon eine Weile mit Visual C# Express Edition und muss sagen, das gefällt mir inzwischen besser als meine Delphi2005-PE. Das .Net-Framework vereinfacht einem wirklich sehr vieles! Von Netzwerkkomponenten bis Serialisierung... Ich habe auch keine Performanceprobleme, ich entwickle ja nichts "großes".... Eine "normale" Anwendung mit ein paar Fenstern und ein paar Berechnungen wird wohl bei heutigen Rechnerstärken auch kein Problem machen. Und nachdem die meisten Leute auch DSL haben, ist es auch kein Problem, sich das Framework zu ziehen. |
Re: .NET Diskussion
Dann häng ich den mal wieder hier dran:
Zitat:
Auf den Delphi Tagen wurde mal quer durch den Raum gefragt, wer von den Anwesenden aktiv .NET Applikationen schreibt. Von den 250 Teilnehmern waren das vielleicht mal gerade 10. Es muss nicht immer alles in den Himmel gelobt werden, was neu und besser sein soll. Der Meinung von den Handymarketing Leuten nach brauchen wir ja alle Handys mit Kamera, Filmen, MP3 Playern und Fön. Aber ist das wirkich so. Ich nutze mein Handy zum Telefonieren und SMSen, das wars. Wär mir lieber es würd dafür ein paar mal weniger am Tag abstürzen, als diesen ganzen Kram mitzuschleppen, den ich nie brauche. Ich sehe da ein Analogon zur ganzen .NET Thematik. Ist sicherlich ne feine Sache, und ich bin selbst auch als Entwickler dabei, mich intensiver damit auseinanderzusetzen. Aber ein gesundes Mistrauen ist imho immer bei allem angebracht. Wir werden sehen was die Zeit bringt, und für den Fall, dass nachher wirklich alles auf .NET rausläuft, muss man einfach nur gewadmet sein. Schaun mer mal. Ich wollte einfach mal bischen die Gmüter beruhigen. Es gibt Pros und Contras sowohl zu Win32 als .NET. Lasst uns das erst mal akzeptieren. |
Re: .NET Diskussion
Moin Zusammen,
also ich für meinen Teil sehe .NET auch als eine geschickte Strategie, von der, mittlerweile doch sehr gut dokumentierten API abzulenken. Die "normale" Win32-API (gilt analog natürlich auch für Win64) wird uns wohl noch lange erhalten bleiben, mindestens so lange, bis der Nachfolger von Vista auf den Markt kommt, und selbst der, erwarte ich jedenfalls, wird wohl zumindest noch einen Emulator dafür haben. Ein Grossteil der Win32-API wird ja vom .NET-Framework gekapselt, aber so manche interessante Funktion muss man sich schon selber importieren (oder ich bin nicht in der Lage sie zu finden ;-)) |
Re: .NET Diskussion
Zitat:
|
Re: .NET Diskussion
Zitat:
Die VCL mag ein anderer Grund sein. Sie ermöglicht zu einem gewissen Grad ähnlich produktiv zu entwickeln wie es mit .Net möglich ist. Auf den ersten Blick sehen es viele nicht ein, einen zweiten Blick zu riskieren. Noch ein Grund dürfte Delphi.Net ein, welches soviele versteckte Quirks enthält um unter .Net noch ein D32-Verhalten vorzutäuschen. Da die Sprache nicht wirklich an .Net angepasst wurde stösst man sich oft die ellbogen an den neuen Geflogenheiten in dieser neuen Welt. Wer .Net mit D.Net kennenlernt dürfte also noch ein paar willkommene Gründe vorfinden, warum er keinen 3. Blick riskieren will. ;) Für mich bedeutet .Net hauptsächlich GoodBye Units, Good Bye DCUs und eine riesige in sich konsistente Klassenbibliothek. Letztlich gab es hier einen Thread über den schnellsten MD5 Algo. Nunja, der in System.Security.Cryptography ist sackschnell, genau wie Sha, AES, Rinjdael und Co. Für native Spielereien nehme ich gerne Alzis Hashlisten, in .Net habe ich generische Dictionaries, SortedDictionaries, TreeSets,... Alle implementieren Interfaces wie IDictionary<K, T>, so dass auch eine eigene Implementierung mit den restlichen Klassen kompatibel bleibt. Wo wir bei Interfaces sind: .Net ist von vorne bis hinten interfacebasiert :) IEnumerable ermöglicht foreach/for in, zusammen mit IList und IBindingList sollte sich das Interface aber schon rumgesprochen haben... Es gibt aber mehr: Du nimmst eine bestehende Klasse, verpasst ihr IComponent und kannst sie auf den Designer ziehen. (WinForm, WebForm, Service, WebService und Component) Du implmentierst IListSource und du kannst sie als DatenQuelle im Designer an Controls binden. Du implementierst ITypedList und hast 100% Kontrolle was wie gebunden werden kann[1]. IBindableComponent lässt dich Daten an Properties deiner Klasse binden... IEditableObject lässt dich darauf reagieren wenn der User in einem an deine Property gebundenen Control Esc drückt oder die in SWF integrierte Validierung fehlschlägt. Zu D32 konnte ich mich nie mit dem DB-Aware Dingsens anfreunden, DataBinding in .Net möchte ich nicht mehr missen. ;) Kurz gesagt: Es ist einfach ungeheuer mächtig. :) Bei weiteren Fragen konsultieren sie einfach ihre lokale .Net SDK Doku. :zwinker: Ich bin echt froh, dass ich mich damals so dermaßen über D8 geärgert habe[2]. Wäre es benutzbar gewesen, hätte ich .Net wohl nie _richtig_ kennen und schätzen gelernt... [1]auf die Art übersetzt z.B. ein DataSet den object array an Daten in einer DataRow in Properties, die man irgendworan binden kann. [2]Ich war sooo bescheuert und hatte ein Upgrade von D7Pro auf D8Arch gekauft :wall: Thx for the Road show ;) |
Re: Inttostr int C#
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
|
Re: .NET Diskussion
Hi
.NET ist in meinen Augen der einzig richtige Schritt, denn W32-API wird auf dauer aussterben. Ich bin zwar noch auf dem W32 Zug. Das liegt aber nicht an mir sondern an Cheffe :-D Das wird sich aber auch bald ändern. Mir persönlich ist es relativ egal welche "Sprache" ich nun schreibe ob es D.NET oder D-W32 ist... wenns sein muss würd ich den Prozessor auch direkt mit OP-Codes füttern. :twisted: Nur irgendwie trauer ich jetzt schon meinem W32-API-Wissen nach :( Zusammenfassend und auf lange Zeit gesehn kann man .Net mit den Worten beschreiben: Do or Die (Kommt mir das nur so vor oder is mein Betrag relativ zusammenhangslos??) Greetz Boombuler |
Re: .NET Diskussion
Wenn man sich als ITler gegen .NET sperrt, so ist man entweder in gänzlich anderen Gefielden unterwegs oder man betreibt karrieretechnischen Selbstmord.
Die Win32 wird uns noch ein paar Jahre ernähren und wir werden in dieser Zeit weiterhin unsere Win32-Anwendungen anbringen können. Aber irgendwann ist eben Schluss - und dieser Prozess ist doch schleichend. Mehr und mehr Produkte von Drittanbietern werden die Win32-Unterstützung aufgeben und auch in der Wahrnehmung der Kunden (diese Wahrnehmung wiederum entscheidet mit über unsere Knete) werden Win32-Anwendungen in einer Handvoll Jahren veraltet sein. A propos "veraltet": Es ist mir schleierhaft, warum die Frage der Objektorientierung in regelmäßigen Abständen wieder hochkommt. Das Thema hat nichts mit Delphi, Windows oder .NET zutun, sondern es ist eine Frage der Software-Architektur. Wenn man sich mal umguckt, wird man feststellen, dass die OO einen etablierten Platz in der Software-Entwicklung eingenommen hat und das nicht zu unrecht. Murks kann man immer machen - aber das ist doch gar nicht die Frage. Ich überlege, ob diejenigen, die sich gegen .NET sperren, sehr jung oder schon recht alt sein mögen. Wer jung ist, in der Branche bleiben will und sich gegen neue Technologiene wie .NET sperrt, handelt naiv. Wer bereits das eine oder andere Dutzend an Jahren Berufserfahrung gesammelt hat, der sollte wiederum schon den einen oder anderen Framework-Wechsel miterlebt haben und auch wenn die jeweils eigenen Projekte nicht umgestellt wurden, so sollte doch der Gedanke nichts Neues sein, sich jede Dekade in eine neue Technik einarbeiten zu müssen. |
Re: .NET Diskussion
Moin moin,
naja, die WinAPI wird so schnell nicht aussterben, allerdings ist sie eben "deprecated". Ich sehe eindeutig einen Vorteil in Sprachen wie Java, C#, usw. Das Wort "Plattformunabhaengigkeit" sollte wohl alles sagen. Damit muss ja nicht unbedingt eine Unabhaengigkeit zwischen Linux und WIndows gemeint sein; nein, auch eine Unabhaengigkeit zwischen einzelnen Windows-Versionen waere schon was. So weiss man wenigstens, dass wenn man eine App fuer .NET 1.1 kompiliert, sie auch dort laufen wird. Wenn ich eine Win32-App kompiliere, dann ist dies nicht gegeben. Von der .NET-Programmierung zu unterscheiden ist aber die objektorientierte Programmierung. Wer stur gegen OOP ist, no matter what, der hat den Zug definitiv verpasst und sollte entweder ueber Rente oder Umschulung nachdenken. Es ist ein Programmierkonzept, das sich durchgesetzt hat, weil es gut ist. Nicht weil wir gerne Punkte machen, nicht weil wir Funktionsaufrufe extrem lang machen wollen, nein, ganz einfach weil es (mir zumindest) logisch einleuchtet. Wenn ich einen Integer habe, dann sollte dieser seine Konvertierungsroutinen mitbringen. Wenn ich eine Struktur XYZ habe, waere es dann nicht einleuchtender, die Funktionen, die eine Struktur erfordern, direkt in die Struktur einzubauen? Also anstatt:
Code:
ganz einfach
DoSomeThingWithMyStructure(MyStructure, Param1)
Code:
Joa, ist sogar kuerzer...solange nicht weissgottwieviele Unterklassen da sind wird es das auch bleiben. Aber darueber wurde schon oft diskutiert, und nie kamen wir zu einem gruenen Zweig. Es laesst sich nur eines sagen: das perfekte Programmierkonzept gibt es einfach nicht.
MyStructure.DoSomeThing(Param1)
Greetz alcaeus |
Re: .NET Diskussion
Zitat:
Allerdings muss ich aus Erfahrung sagen, die Unabhängigkeit tatsächlich schon in sehr grossen Teilen auch Unabhängig vom Betriebssystem ist. Bisher konnte ich jede - und damit meine ich wirklich jede - .NET 1.1-Applikation die ich geschrieben habe (mehr mit Delphi.NET als mit C#) so wie sie aus dem jeweiligen Compiler herauskam auf ein Linux-, MacOS und auch Solaris-system kopieren - und sie lief. Die Mono bzw. dotGNU runtime vorausgesetzt. Gut, die zwei WindowsForms Applikationen zählen eigentlich nicht wirklich, weil ich da nur eine Handvoll Standard-Komponenten verwendet habe, aber - und gerade das kommt ja auch immer mehr auf Firmen zu - die ASP.NET Anwendungen und Webservices liefen auch, und zumindest einer von denen war arg hochgezüchtet :) Natürlich hat Win32 noch seine Existenzberechtigung - das will ich auch keinem Absprechen. Aber man sollte sich ernsthaft die Frage stellen, was von einem zukünftigen, neuem Produkt erwartet wird. Dies ist schon jetzt und wird auch weiterhin so sein:
Punkt 1 bietet zur Zeit ausschliesslich .NET. So wie der Win16/Win32 - Wechsel werden Win32-Anwendungen irgendwann nur noch emuliert und dann später gar nicht mehr laufen. .NET ist ja gerade entwickelt worden, um eine Schicht zwischen Anwendungen und OS zu haben, die diese Hürde überbrückt. 2 und 3 sind eine Frage der Architektur. Viele Programme sind leicht Wartbar und leicht Erweiterbar, viele sind es nicht. .NET liefert mit seiner Struktur aber das Handwerkszeug gleich mit, um auch neue Projekte ohne grösseren Aufwand leichter Wartbar und Erweiterbar zu machen. Sicherheit: Auch hier sage ich nur CAS. Wenn eine Applikation nunmal nicht auf das Filesystem darf, dann kann ein bösartiger Angriff, selbst wenn er einen unter .NET so gut wie ausgeschlossenen Buffer-Overflow-Angriff fährt, eben keinen Code ausführen, der auf das Filesystem zugreift. Was das Framework auch so an Sicherheitsmechanismen mitbringt ist nicht zu verachten: Ver- und entschlüsselung, Hashing, Authentication (besonders im ASP-Bereich), Sessionhandling (auch hier ASP). Das sind alles Dinge die man schon von Haus dabei hat, die man in Win32-Applikationen entweder teuer zukaufen oder aber selber schreiben muss, und gerade letzteres ist sehr fehleranfällig und damit Sicherheitskritisch. Alles in allem sehe ich persönlich .NET als einen richtigen Schritt in die Zukunft. Neue Projekte beginne ich nur noch unter .NET. Ob sich die Portierung alter Projekte lohnt sei mal dahingestellt und ist vom Einzelfall abhängig. |
Re: .NET Diskussion
Also mit fast 42 Jahren (Hey ich bin bald die Antwort auf die Frage :zwinker:), gehöre ich wohl schon zu den Älteren. Ich habe schon ein paar Wechsel mitgemacht und mache auch den .NET-Wechsel mit. Ich müsste nicht, da ich damit nicht mehr mein Geld verdiene, aber ich halte .NET für eine konsequente Weiterentwicklung der OO-Konzepte.
Borland hat OOP übrigens maßgeblich voran getrieben (TP5, wenn ich nicht irre). Die damalige Oberfläche (Turbo-Vision) hat dem Programmierer irre viel Steuerungsarbeit erspart. Und es war OO! Mit Einführung von Programmiersprachen für Windows wurde das konsequent fortgeführt. Bestimmt nicht, weil es schlecht war. Wenn man dann mal sieht, wer an der Entwicklung von .NET beteiligt war (Name ist mir entfallen, aber es war ein wichtiger Entwickler von Borland), muss man sich nicht wundern, dass .NET OO ist. OOP hat sich über viele Jahre bewährt. Es ist daher fast zwangsläufig, dass irgendwann sowas wie .NET kommen würde. Anfangs konnte ich mich auch nicht richtig damit anfreunden. Der Grund war Delphi. Nicht weil die IDE schlecht war/ist, sondern weil es imho nicht konsequent genug umgesetzt wurde. Dazu kommt die Trägheit von Borland (-> .NET 2.0) und die wirklich schlechte Hilfe-Funktion. Alles was ich jetzt neu anfange, mache ich mit C#. Als IDE benutze ich SharpDevelop und bin sehr zufrieden. D2006 ist mir einfach zu teuer und unterstützt ja immer noch nicht .NET 2.0. Einige Dinge, die ich mal eben schnell machen muss, mache ich noch unter Win32 mit Delphi, weil ich da mit meiner Erfahrung einfach schneller bin. Aber das wird nicht so bleiben. |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 01:25 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz