Entwickler-Ecke
Off Topic - C#
Delete - Mo 12.05.03 11:10
Titel: C#
Ich mags nicht. Ich hab mal Microsofts C# Builder probiert, saulangsamer Compiler. Außerdem mag ich die Programmiersprache an sich nicht.
Was haltet ihr denn so davon ?
ShadowCaster - Mo 12.05.03 11:14
C# ist irgendein von microsoft eingeführter Standard der im Wesentlichen vom Aufbau her (von den Ideen (Einfachvererbung, etc.) Java entspricht. Hab mal ein paar Sachen darüber gelesen. Meiner Meinung nach versucht Microsoft nur Java nachzumachen und so die Herrschaft etwas mehr auszubauen. Es gibt mittlerweile schon Browsersplugins, etc. die in C# geschrieben sind.
Also ich werde C# bestimmt niemals anrühren wenn ich es nicht muss, weil sogut wie alles was von microsoft kommt, macht abhängig (also von Windows) ... ;) Ein Glück, dass es für Delphi CLX gibt und wir delphianer schon seid längerem nicht mehr von Microsoft Windows abhängig sind.
C# ist abhängig von Windows und insofern nicht zu gebrauchen. Dies ist meine (zugegeben emotional angehauchte) Meinung zu dem Thema.
An dieser Stelle möchte ich meine ach so beanspruchten Fingerlein nicht länger auf der Tastatur abnutzen und über den (Mü... naja.. das Zeugs da) schreiben *g*
neojones - Mo 12.05.03 12:56
C# = Proprietär und systemgebunden, will heißen: Der Rotz wird so schnell aussterben wie andere unnötige Programmiersprachen, z.B. Profan oder Zimmermann Basic.
Nightfly - Mo 12.05.03 13:01
Imho redet ihr da Troll Quark ...C hat genauso seine berechtigung, es gibt halt einfach Zeugs was in C am schnellsten/effektivsten umgesetzt werden kann.
Moritz M. - Mo 12.05.03 13:12
Klar hat C# seine Berechtigung, auch zu existieren. Aber die Sprache an sich halte ich von Schwachsinn. Ich schätze, Microsoft hat da mal wieder versucht alles auf diese Sprache zu konzentriere, genauso wie bei Windows. Nur hats halt nicht geklappt....
Udontknow - Mo 12.05.03 13:18
Also die Sprache an sich empfinde ich als recht gelungen. Es hat sehr viele Dinge von Delphi übernommen, wie z.B. die Properties. Das sind meiner Meinung nach Schritte in die richtige Richtung. Ganz unabhänig jetzt davon, daß das alles mit .Net zusammenhängt...
Wo wir gerade dabei sind: Weiss jemand, ob es irgendwann Multi-Inheritance für Delphi geben wird?
Cu,
Udontknow
Nightfly - Mo 12.05.03 13:22
Naja, aber ich wage zu behaupten das es eine Sehr mächtige Sprache ist. Es heißt nich umsonst, es ist nicht leicht sich mit C was auf den Fuß fallen zu lassen, doch wenn's passiert ist gleich das Bein ab.
Mag dahingestellt sein wie nützlich/vertretbar es ist, (bes. für theoretiker)zum Beispiel zuzulassen das man in einer Schleife den durchlaufzähler manipuliert...war'n doch die C Leute die damit angefangen haben....
Udontknow - Mo 12.05.03 13:28
Na, den Zähler kannst du auch in Delphi manipulieren. Man muss nur ein wenig herumdoktern... :wink:
Klabautermann - Mo 12.05.03 13:37
Hallo,
| neojones hat folgendes geschrieben: |
| C# = Proprietär und systemgebunden, will heißen: Der Rotz wird so schnell aussterben wie andere unnötige Programmiersprachen, z.B. Profan oder Zimmermann Basic. |
das halte ich für wunschdenken. Ich schätze C# kann sogar C++ ablösen. Denn in vergleich zu diesem besitzt es einige verbesserungen und die Akzeptanz ist sehr hoch. So sprinkt auch nciht nur Borland mit dem kürzlich vorgestelten C#-Builder (ehemals Sidewinder) auf diesen Zug auf, mit Glade gibt es auch schon eine C#-RAD umgebung für UNIX. Wer sich dafür interessiert kann sich ja den Toolbox Artikel
Platformunabhängig mit C# [
http://www.toolbox-mag.de/data/tx32003artikel1.pdf] durchlesen.
Gruß
Klabautermann
CenBells - Mo 12.05.03 13:50
| Udontknow hat folgendes geschrieben: |
| Also die Sprache an sich empfinde ich als recht gelungen. Es hat sehr viele Dinge von Delphi übernommen, wie z.B. die Properties. |
Ich glaube nicht, das das direkt von delphi abgeschaut ist. Gut es heißt in Delphi direkt property aber propertys gibt es auch in java und auch vorher schon in pascal und C...
Das es nicht plattformabhängig ist, ist klar, aber man braucht doch erstmal eine Virtualmachine, oder (ähnlich java)?
Gruß
Ken
Klabautermann - Mo 12.05.03 13:53
Hallo,
| CenBells hat folgendes geschrieben: |
| Ich glaube nicht, das das direkt von delphi abgeschaut ist. Gut es heißt in Delphi direkt property aber propertys gibt es auch in java und auch vorher schon in pascal und C... |
die Chance ist aber groß, schließlich hat M$ für dieses Projekt Delphi Entwickler abgeworben. Das was ich auf der CeBit 2002 zur Datenbankanbindung gesehen habe, hat auch sehr an Delphi erinnert ;).
Gruß
Klabautermann
PS: Warum heißt dieses Topic eigentlich C++ wenn es doch um C# geht?
ErnestoChe - Mo 12.05.03 14:04
Hi,
von was redet Ihr eigentlich?
C, C++, C#
Da sollte auf jeden Fall differenziert werden. Über C# kann ich nicht viel sagen.
Was aber C++ angeht sollte es keine Diskussion geben. Es hat mehr als nur eine Daseinsberechtigung. Jeder Programmierer sollte zumindest in Grundzügen C/C++ beherrschen.
MFG
- Ernesto -
Udontknow - Mo 12.05.03 14:06
Also, meine Meinung ist, das Delphi, um wirklich C++ den Rang abzulaufen, nur noch Operator-Übersteuerung und Multi-Inheritance fehlt, dann ist´s "perfekt". :)
Delete - Mo 12.05.03 14:23
Ähm ich meinte eigentlich C# sorry
MaxiTB - Mi 14.05.03 14:55
Titel: Endlich mal was wo ich mitreden kann ... *ggg*
ANSI-C / C++
Weils auch oft angesprochen wurde, es gibt eine Menge Dinge, die in diesen Sprachen superb realisiert sind - allerdings fordert C wesentlich mehr Diszipin von einem Programmierer als z.B. Pascal.
C#
Schlecht mit Delphi/C-classics vergleichbar - auch der Vergleich mit Java hinkt stark. Der einzige Pluspunkt von Java war damals das Framework - C# ist im Prinzip eine Mischung von C/Delphi/VB und setzt auf MSIL auf ... dafür wird ja auch gerade ein Delphi Compiler gebastelt.
Fazit: Wäre das ganze nicht auf MS gewachsen, ich würde es hochjubbeln - mal alleine aus der Programmierersicht !
AndyB - Mi 14.05.03 15:24
Titel: Re: Endlich mal was wo ich mitreden kann ... *ggg*
| MaxiTB hat folgendes geschrieben: |
| Wäre das ganze nicht auf MS gewachsen, ich würde es hochjubbeln - mal alleine aus der Programmierersicht ! |
Also wenn ich mir überlege, dass für jedes Feld in einer Klasse das Wort
public,
private oder
protected vor dem Typ und den Feldnamen schreiben muss, dann denke ich, dass diese Sprache die Programmierer eher peinigt als ihnen hilft. Das Sichtbarkeitsprinzip hätten sie besser von C++ übernehmen sollen.
Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
| using System;
public class ErstesProgramm
{
private int a;
private String b;
public double c;
public String d;
public static void Main()
{
// mein Code
}
} |
MaxiTB - Mi 14.05.03 16:53
Titel: Das halte ich für eine Gerücht ...
... weil nämlich wie in C++ alle nicht explizit angegebenen Member private sind.
Jedenfalls wars noch bei Beta2 so ...
Und genz ehrlich, Tippaufwand ist bei Pascal-Ablegern mit begin/end ja auch nicht ohne ... man spart ja auch procedure/function.
Nop ... das ist kein Argument.
Was eher nervig ist, ist nun die explizite Angabe von override oder abstract - das gabs unter C++ noch nicht.
Sehr praktisch: sealed - auch die AdHoc-Vererbung hat seine Vorteile, besonders, wenn man furchtbar schlampig programmiert. *gg*
ShadowCaster - Do 15.05.03 11:39
naja, damit Delphi C++ den Rang ablaufen kann sollte es auch Mehrfachvererbung (die ich immer noch stilistisch für die sauberste Variante, nicht jedoch einfachste und fehlertoleranteste Variante halte) und vorallem Treiberprogrammierung unterstützen ;) Wenn das der Fall wäre, wärs echt genial.
Delete - Do 15.05.03 11:56
Für die Treiberprogrammierung war es nie gedacht und ausgelegt. Es war dazu gedacht schnell und effizient Windows, hauptsächlich GUI-Anwendungen, zu entwicklen.
ShadowCaster - Do 15.05.03 11:59
Das ist mir klar aber das ist ein wesentlicher Grund, warum Delphi im Beliebtheitsfaktor einige Prozentpunkte unter C steht, würd ich sagen. Treiber sind wichtig. In Delphi kann ich z.B. keinen gescheiten Virenscanner programmieren, wie ich es wollte (schade eigentlich). Schade, dass Delphi "nur" ein RAD-Tool ist. So wird es C nie den Rang ablaufen können. Ich bin der Meinung dass C seine Darseinsberechtigung hat aber ich glaube nicht, dass sich C# durchsetzen wird. Vielleicht wird es mal so eine Verbreitung wie Visual C++ erreichen in ein paar Jahren aber mehr sicher nicht...
Delete - Do 15.05.03 12:06
Sehe ich nicht so. Delphji hat einfach eine ganz andere Zielgruppe. Und wenn du einen Treiber brauchst, dann Programmkier ihn mit VC und den Rest mit Delphi.
MaxiTB - Do 15.05.03 12:07
Titel: @ShadowCaster
Du hast es noch nicht ganz verstanden, oder ?
C# ist nur eine Ausdrucksweise der .NET Platform - es ist dabei völlig egal ob du VB.NET, Delphi.NET, C# oder was auch immer programmierst - sie alle produzieren MSIL.
Und wenn du ein Programm in VB.NET und C# schreibst, was den selben Algorithmus zu Grunde liegt, du wirst dich wundern - beide Assemblies sind identisch (klar - sind ja auch beide von MS, aber ich denke, auch Delphi-Code wird nicht sehr davon abweichen - wieso auch).
Also ist die Frage der Programmiersprache der Zukunft keine Frage - wenn sich die .NET-Platform etabliert wie damals Win95 oder IE, dann gibts bald keine Unterschiede mehr, was du programmierst. Der Output ist egal welche Programmiersprache identisch.
ShadowCaster - Do 15.05.03 12:21
ja, schon, das ist richtig. Bin nur gespannt, wann Delphi über den Status des RAD-Tools hinausdigitiert (bitte um Verzeihung für meine gerade ziemlikch kindische Ausdrucksweise @digimon) und zu einer Plattform für alle Arten von Programmen und Systemkomponenten wird. Darauf warte ich gespannt :)
Klabautermann - Do 15.05.03 17:18
Hallo,
| ShadowCaster hat folgendes geschrieben: |
Treiber sind wichtig.
[...]
Ich bin der Meinung dass C seine Darseinsberechtigung hat aber ich glaube nicht, dass sich C# durchsetzen wird. Vielleicht wird es mal so eine Verbreitung wie Visual C++ erreichen in ein paar Jahren aber mehr sicher nicht... |
damit wiedersprichst du dir ein wenig. Denn einerseits behauptest du, das Delphi zur verbreitung von C++ aufschließen könnte, wenn man Treiber damit erstellen könnte. Andererseits sagst du aber, das Visual C++, der
einzige Compiler der Windows Treiber erstellen kann, nur eine geringe verbreitung hat.
Also irgendwie passt das nicht.
Gruß
Klabautermann
Delete - Do 15.05.03 17:28
| ShadowCaster hat folgendes geschrieben: |
| Bin nur gespannt, wann Delphi über den Status des RAD-Tools hinausdigitiert |
Warum sollte es das? Porsche baut auch keine Panzer.
ShadowCaster - Fr 16.05.03 08:42
naja, warum? die Frage hättest du gar nicht stellen brauchen. Weil Entwickler die Funktionen brauchen und deswegen früher oder später auf VC++ umsteigen müssen, nur weil Delphi das und einiges anderes nicht kann. Da kann ich ja dann gleich bei C++ bleiben, wenn ich systemnah entwickeln will und delphi in der Sparte ganz vergessen.
Du kannst das etwa folgendermaßen vergleichen: Warum baut Porsche auch ABS und ESP in seine Autos ein? Zum einen (der wichtigste Punkt) um den Fahrkomfort der Autobesitzer zu steigern und das Unfallrisiko zu mindern und um mehr Kunden zu gewinnen und weil das andere Hersteller auch tun.
Porsche könnte ja auch sagen, vergleichbar mit Borlands oder deiner Meinung: Wir bauen in unserem Autosegment nur Sportwagen, wofür brauchen die ESP oder ABS? Die Autos unserer Konkurrenz haben das ja schon. (Sollen die Kunden zu unserer Konkurrenz gehen. Wir nennen unsere Autos Sportwagen und nicht Unfallfreiwagen oder Luxuswagen, das tut die Konkurrenz).
Naja, ein Auto ist immer noch ein Auto. Letztendlich ist es das Problem der Hersteller. Den Vergleich mit dem Panzer halte ich schlicht für übertrieben. Warum werden in Autos Kilometerzähler eingebaut? Damit man das Auto nicht trocken fährt. Wenn man nach dem Prinzip entwickelt: die Konkurrenz besitzt das ja schon! dann wird man nie was in allen Segmenten der Technik erreichen. So ist das auch bei Compilern. Was nützt mir ein Compiler oder RAD-Tool wenn ich damit nur Anwendungen auf vorhandenen Systemfunktionen entwickeln kann? Was ist wenn mir die Systemfunktionen von Windows zu langsam oder zu schlecht sind oder ich systemnah entwickeln will? Dann brauch ich auch nicht den Inlineassembler von Delphi, weil der mir da sowieso nix bringt.
Was hätten denn die ersten Entwickler von DirectX sagen sollen? Es gab die Schiene OLE und COM, DCOM. Damals haben Spieleentwickler in DOS entwickelt, weil Windows und die lahme COM- OLE-Schiene nicht ging. Es war einfach zu langsam oder nicht möglich was dafür gescheit zu entwickeln, bis private Programmierer die Schiene neu definiert haben mit DirectX. Dann kam plötzlich M.... und hat dieses Tool aufgekauft, weil immer und immer mehr Spielehersteller damit entwickelt haben und M.... entdeckt hat, das DirectX im Bereihc der Spiele die Zukunft ist.
Wenn ich für Windows oder andere Systeme nicht mal Treiber entwickeln kann, dann ist das so, als würde ich mit einer Blackbox arbeiten. Ich kann sie bedienen und was mit ihr machen, aber ich kann nicht in sie reinschauen oder Dinge in ihr ersetzen. Ich hab doch gar nichts gegen Delphi und ich weiß, dass Delphi als RAD-Tool deklariert ist, aber die Systemschiene ist unerlässlich. Soviele Anwendungen wie Virenscanner, Grafikkartentreiber, Soundkartentreiber, COM-OLE-Treiber, Directx-Treiber, Mainboard-treiber, etc. Wie soll ich in Delphi jemals solche Treiber als Systemhersteller entwickeln können? Da fang ich ja bei 0 an. Also nehme ich VC++ oder C# oder was auch immer. Das find ich total schade. Es ist einfach fast gemein von Borland, Delphi nicht so zu erweitern, weil Delphi für mich einfach die Zukunft darstellt. Wenn diese Features in Delphi drinnen wären, würde Borland mit einem Schlag ein komplettes Marktsegment konkurrenzfähig besetzen können. Das ist nicht gerade wenig.
Naja, lange Rede, kurzer Sinn. Das was oben steht, wars was ich sagen wollte ... *lol*. :lol: Ich will jetzt nicht von C# abschweifen. Die Idee halte ich ja schon für gut, dass Sachen von Delphi und Java und C vereint wurden, allerdings ist C# systemabhängig. Man macht sich von Microsoft abhängig und das ist fahrlässig. Sofern bald Palladium und TCPA oder wie das jetzt mittlerweile heißt auf den Markt kommen, dann gute Nacht Windows. Wer auf der C#-Schiene fährt, der sitzt in einem Zug, der auf einer Strecke fährt, deren Gleise bald enden ... und dann irgendwann macht es Bumm... und Windows ist nicht mehr da und plötzlich stehen alle Firmen deren Programme auf C# entwickelt wurden ohne Absatzmarkt da, da niemand mehr Windows benutzt.
Das sind jetzt sehr düstere Aussichten... aber so denke ich wird ich der Markt höchstwahrscheinlich entwickeln. Ich sehe nicht ein warum ich C# benutzen soll. Das ist ein Gleis, was nach 3 Kilometern endet, es sei denn jemand entwickelt Interpreter für Browser und unterschiedliche Betriebssysteme, aber es gibt ja schon Java. Ich nehm doch lieber Java, auch wenns langsamer ist. Java ist C# schon mindestens 5 Jahre in der Entwicklung vorraus. Das gibt es schon seid 1990, wenn die Daten in meinem Gedächtnis stimmen.
MaxiTB - Fr 16.05.03 09:00
Titel: Die Aussage ...
... C# ist systemabhängig stimmt eben nicht.
Nochmals: C# ist nur eine Programmiersprache des .NET Frameworks.
Weiters kann man mit jeder .NET Sprache gleichwertige .NET Anwendungen schreiben (oder auch nur Assemblys).
Und das .NET Framework wird derzeit auch auf andere Platformen (wie z.B. Linux) portiert ... du kannst also auch eine .NET Anwendung früher oder später unter anderen OS laufen lassen (auch wenns noch ein paar Problemchen gibt ...).
Die Aussage c# ist abhängig von Windows ist damit schlicht und ergreifend falsch - die Aussage, MS gibt vor, was das Framework macht, kann, darf und somit auch jede darauf laufende Anwendung ist eine andere Geschichte.
Zur Treiberprogrammierung: Schlicht und ergreifend unwichtig - wenn eine OS-API oder auch ein darüberliegendes Framework Klassen/Funktionen bietet, welche die Aufgabe auch lösen können (z.B. für Virenscanner), dann ist Treiberprogrammierung schlicht unnötig - und sollte meiner Meinung nach auch bei den Hardwareherstellern und OS-Entwicklern bleiben.
Sonst reißt man nur Sicherheitslücken in sein System, weil man vorher immer checken müßte, was der Treiber eigentlich tut und kann.
ShadowCaster - Fr 16.05.03 09:08
Ich hatte doch oben gesagt, dass C# systemabhängig und damit Abhängig von microsoft macht, oder nich? Naja egal... hab mich vielleicht falsch ausgedrückt. Werde mich an dieser Stelle wegen zu wenig Fachwissen über C# aus der Diskussion zurückziehen, bevor ich noch Falsches von mir geb. Ich hoffe, ihr versteht das...
nachtrag: wenn ich immer erst warten muss, bis microsoft mir die Api-funktionen anbietet,damit ich nicht selbst schnittstellen schreiben muss, dann bin ich aber ganz schön aufgeschmissen. Ich werd mal sehen, ob ich mich nicht in VC++ einarbeite und wenn mir die Sprache gefällt muss ich schauen, ob ich nicht hauptsächlich darin entwickel, was die Systemprogrammierung angeht, weil ich bei Delphi ja nicht genug geboten bekomm.
MaxiTB - Fr 16.05.03 09:22
Titel: @ShadowCaster
Lest du eigentlich meine Postings ?
C# und alle damit verbundenen Sprachen sind N I C H T systemabhängig - das ist nämlich der Sinn von Frameworks (siehe Java auch wenns dort ziemlich schlampig implementiert wurde, aber auch .NET ist ja nicht perfekt).
ShadowCaster - Fr 16.05.03 09:30
ich hab ein Tool für die Treiberentwicklung auch mit delphi gefunden... nach ziemlich langem Suchen. Es sind keine Kenntnisse des DDK nötig. Allerdings turnt mich dieses Tool noch nicht so an. Scheinbar haben da schon ein paar Leute eine Schnittstelle zwischen DDK und Delphi geschaffen, nur warum kommt das nicht von Borland?
http://www.jungo.com/windriver_windows.html
Klabautermann - Fr 16.05.03 10:40
Hallo,
| ShadowCaster hat folgendes geschrieben: |
| nur warum kommt das nicht von Borland? |
ich kenne dieses Tool nicht, und kann nicht sagen, wie gut es arbeitet. Aber Borland hat höchst warscheinlich eine Kosten nutzen Rechnung aufgemacht, und festgestellt, dass die entwicklung eines Compilers für Treiber seine Kosten nicht wieder einspielt. Denn wenn ich recht informiert bin, ist das Compilat für treiber von denen für "normale" Anwendungen komplett unterschiedlich, so das es tatsächlich auf einen Zweiten Compiler hinauslaufen würde (dessen funktionen natürlich in die selbe EXE wie der erste integriert werden könnte).
Sicher ist es schade, dass Delphi keine Treiber erzeugen kann, allerdings ist mir lieber, das es dies nicht kann, als wenn ich auf irgendwelche RAD funktionen verzichten müsste.
Gruß
Klabautermann
ShadowCaster - Fr 16.05.03 10:48
naja, wieso sollte man auf RAD-Funktionen verzichten müssen? Das wäre ja als wenn du behaupten würdest, dank CLX müsste man auf VCL-Funktionen verzichten. Das ist doch nicht der Fall. Lediglich eine SChnittstelle zur DDK wäre super, die das Entwickeln von Treibern ermöglicht.
AndyB - Fr 16.05.03 10:59
| ShadowCaster hat folgendes geschrieben: |
| Lediglich eine SChnittstelle zur DDK wäre super, die das Entwickeln on Treibern ermöglicht. |
Diese Schnittstelle zu schreiben ist kein Problem. Nur wer übersetzt die zig MB DDK Header-Dateien nach Pascal um sie dann in einem einzigen Treiber zu verwenden? Auch wenn diese dann Online gestellt werden sollten, was ich mir bei dem Übersetzungsaufwand eher als entgeltlich vorstellen kann, werden nicht all zu viele Delphi-Programmierer Treiber schreiben.
| Zitat: |
| Denn wenn ich recht informiert bin, ist das Compilat für treiber von denen für "normale" Anwendungen komplett unterschiedlich |
Nein, es ist das selbe compilat. Der Linker von Delphi ist die "Schwachstelle", denn dieser kann keine Treiber zusammenlinken, wie es der Linker von VC++ kann. Beim ilink.exe von BCB ist ein Linken von Treibern zwar vorgesehen, aber dann tatsächlich einen Treiber zu Linken ist ein anderes Problem, da wiederum mit den unterschiedlichen .lib-Formaten zu tun hat.
Klabautermann - Fr 16.05.03 11:27
Hi,
| ShadowCaster hat folgendes geschrieben: |
| naja, wieso sollte man auf RAD-Funktionen verzichten müssen? |
weil dafür menpower benötigt wird, die irgendwo anders abgezogen wird.
| ShadowCaster hat folgendes geschrieben: |
| Das wäre ja als wenn du behaupten würdest, dank CLX müsste man auf VCL-Funktionen verzichten. Das ist doch nicht der Fall. |
Von Kylix verspricht Borland sich eine führende Position auf einem neuen Markt. Daher wurden daher wohl zum teil neue Leute eingestellt. Dennoch habe ich das gefühl, das die neuerungen in Delphi weniger sauber umgesetzt werden als früher (tActionToolbar & Co sind unverschämt Buggy [auch noch nach dem Patch]) und Kylix ist erst mit der Aktuellen Version 3 halbwechs einsetzbar. Trotzdem kämpft Borland schon fast anisch um der erhoffte Marktposition (bei €20 für K3 Pro können die keinen Gewinn machen). Es würde mich nicht mal überraschen, wenn diese Schiene zu gunsten von .NET (welches auch wieder Manpower kostet) eingestellt würde. Auf jeden Fall kämpft das Delphi-Language Team von Borland momentan an drei Fronten, die werden da keine vierte eröffnen. Selbst wenn Delphi Treiber erstellen könnte, würde das seine Marktposition nur unwesentlich verbessern, da die wenigsten Benutzer Treiber Programmieren wollen/müssen. Wie, gesagt, ich fände es auch nicht schlecht, wenn Delphi könnte, aber es gibt Dinge die wichtiger sind.
Viele Programmierer würden warscheinlich auch auf grund ihrer Überzeugung nicht auf Pascal als Sprache zur Treiber Programmierung zurückgreifen. Da für Systemnahe Programmierung C(++) als ideal angesehen wird. Denn in C(++) ist alles möglich was technisch realisierbar ist, in Pascal nicht. Dies wird bei Leuten die nah an der Maschiene sind als riesen Vorteil gesehen.
Gruß
Klabautermann
AndyB - Fr 16.05.03 11:34
| Klabautermann hat folgendes geschrieben: |
| bei €20 für K3 Pro können die keinen Gewinn machen |
Wenn genug Leute bestellen, dann vielleicht doch. Bei 14 Käufern hat man schon 280 €, wie die Kylix 3 Pro Version kostet (Steckenborn.de) eingefahren.
ShadowCaster - Fr 16.05.03 15:32
Klabauterman, du hast wohl recht :?
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2026 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!