Alle Jahre (Monate) wieder... Zukunft von Delphi

[Bernhard Geyer]

Zitat:

Zitat von olafst (Beitrag 1242176)

einzig die gigantische sammlung an freien komponenten vermisse ich in c#. Allerdings habe ich auch nicht sehr intensiv gesucht, aber wenn eine googlesuche auf den ersten 10 seiten nur kommerz-kompos ausspuckt, kann da nicht viel sein.

Bei der gigantischen" Sammung von Delphi-Komponenten musst du aber die abziehen die entweder nicht mehr gepflegt sind oder mittlerweile aus hundert verschiedenen Quellen *irgendwie* gepflegt sind. Früher mal Super Einsetzbare Komponenten wie den THtmlViewer oder der TEmbeddedWB sind mittlerweile eher eine Schwachstelle der eigenen SW da sie einen Versionswechsel der IDE verhindern. Die Jedi VCL hat sich auch mittlerweile zum Renten-heim für nicht mehr gepflegte Komponenten gewandelt und die Entwickler die diesen Code pflegen werden auch immer weniger.

[messie]

Zitat:

Zitat von OlafSt (Beitrag 1242176)

bin auch ich am überlegen, so langsam den Schwung von Jahrzehnten mit Delphi in Richtung C# zu machen.

Wenn Du nichts Zeitkritisches machst und ein die Euronen für die zusätzlichen Komponenten übrig hast, ist da nichts gegen einzuwenden. C# ist nun mal ein Delphi-Abkömmling.

Ich habe mich ja kürzlich beruflich neu orientiert und stelle fest, dass die Leute, die mit Software zu tun haben, von Delphi vielleicht "gehört" haben, aber sich alle gut mit LabView auskennen. Warum? Weil National vor 15-20 Jahren begonnen hat, systematisch die Berufs- und Hochschulen zu versorgen. Da gab es kostenlose Kurse, die Hochschulen wurden ausgestatten und geschult. National erntet das jetzt ab, zumindest im technischen Bereich. Und sie bieten guten Support und haben LabView auch detulich weiter entwickelt (jetzt sogar mit OOP).

Ursprünglich war das eigentlich die Borland-Strategie. So etwas braucht einen langen Atem und den hatte während der mehrfachen Besitzerwechsel keine.

Bei den reinen Informatiker würde ich die großen und umfangreichen Projekte ohnehin im Bereich UML sehen. Und da ist es dann egal, welcher Compiler drunter sitzt.

Grüße, Messie

[Bernhard Geyer]

Zitat:

Zitat von messie (Beitrag 1242224)

C# ist nun mal ein Delphi-Abkömmling.

Primär ist es eigentlich ein Java-Abkömmling.

Zitat:

Zitat von messie (Beitrag 1242224)

Bei den reinen Informatiker würde ich die großen und umfangreichen Projekte ohnehin im Bereich UML sehen. Und da ist es dann egal, welcher Compiler drunter sitzt.

Ja ja. UML und nix mehr Schreiben. Das sind dann die Projekte die auf Heise auftauchen weil Sie gescheitert sind.

[Furtbichler]

Zitat:

Zitat von messie (Beitrag 1242224)

C# ist nun mal ein Delphi-Abkömmling.

Stimmt, weil Anders Hejlsberg an beiden Sprachen maßgeblich beteiligt ist. Genauso wie die Glühbirne ein Abkömmling des Phonographen ist. Beides wurde von Thomas Edison erfunden. ;-)

Zitat:

Zitat von messie (Beitrag 1242224)

Bei den reinen Informatiker würde ich die großen und umfangreichen Projekte ohnehin im Bereich UML sehen. Und da ist es dann egal, welcher Compiler drunter sitzt.

Boah, noch so ein Expertenstatement. Mir war jetzt neu, das ich Funktionalität in UML abbilde. Und so ein bisserl Funktionalität, so Schleifen und so, sollte eine Software schon haben. Außer, Du programmierst die Bundesregierung. Dann reicht UML definitiv.

[Memnarch]

Zitat:

Zitat von messie (Beitrag 1242224)

Bei den reinen Informatiker würde ich die großen und umfangreichen Projekte ohnehin im Bereich UML sehen. Und da ist es dann egal, welcher Compiler drunter sitzt.

Ding Ding, 1990 are calling, they want their utopia back!

Ne mal erlich, der satz war nicht ernstgemeint oder? Oder sind blaupausen jetzt plötzlich fertige gebäude?

[Mavarik]

Zitat:

Zitat von Furtbichler (Beitrag 1242196)

Wieso? Willst Du in deiner rosaroten 'Delphi ist das Beste' Blase leben, wo alle nur 'Delphi is so toll' singend und mit Blümchen im Haar ums Lagerfeuer tänzeln? :lol: Im Ernst: Ich kann dich voll und ganz verstehen und ich finde es gut, wenn 'alte Hasen' wie Du einfach das machen, was sie am besten können. Alles ok. Erlaube anderen alten Hasen aber auch, mal über den Tellerrand zu hoppeln und zu berichten, das die Möhrchen da draußen viel besser schmecken.

Es geht nicht um eine rosarote Brille!

Läuft Delphi optimal? Nein!
Kann ich damit arbeiten? Auf jeden Fall!
Fehlen mir Sprachfeatures? Nein!

Ich konnte 31 Jahre auf Generics verzichten und mir hat nix gefehlt. Natürlich habe ich es mir angeschaut und ich nutze Generics jetzt auch. Es geht aber auch ganz problemlos ohne.
Braucht man Class Proceduren? Nein es geht auch ohne, aber ich nutze diese seit einiger Zeit.
Es mag sein, dass es das ein oder andere Sprachfeature noch gibt, welches ich dann auch ggf. nutzen würde (die obige Liste ist natrülich nicht komplett) aber in komme auch ohne aus.

"dependency injection" hat sicherlich "ne nette Idee dahinter", genauso wie einige andere "Code Pattern", aber brauche ich das?

Damit ich sagen kann : "Boh, schaut mal was ich alles cooles im Sourcecode machen kann".

Der Kunde sieht nicht wie ich das programmiert habe. Und schneller wird es dadurch auch nicht. Vielleicht wird das ein oder andere dadurch Bugfreier, mag sein. Aber ein Typecast auf einen Pointer hat's auch jahrelang getan.

Vielleicht habe ich früher zu lange ASM programmiert oder für zu viele Proceduren die Prozessortaktzyklen nachgerechnet, aber ich sehe hinter jeder Struktur nur die Speicherstellen und die Anzahl der Maschinenbefehle um das ein oder andere um zu setzen. (Nicht mehr so schlimm wie früher)

Wenn es zum täglich Brot gehört hat, mit:

Delphi-Quellcode:

LD HL,$8028    // 21 28 80
LD DE,$8000    // 11 00 80
LD BC,$780      // 01 80 07
LDIR                  // ED B0

den Bildschirm um eine Zeile nach oben zu scrollen, sieht man diesen "neumodischen Kram" vielleicht mit anderen Augen {wie geil, ich hab die Hexcodes immer noch im Kopf}. Das bedeutet jedoch nicht, dass ich mich Neuem verschließen würde.

Ich denke wenn die Profis, die Semiprofis und alle anderen die mehr als ne Demo-App zusammen bekommen, an der Qualität von Delphi - in welcher Form auch immer - mitarbeiten, können wir mit einem sich stetig verbessernden Delphi noch viele Jahre arbeiten.

Ein guter Schritt in diese Richtung wäre sicherlich ein deutschsprachiger technischer Ansprechpartner mit direktem Kontakt zum Delphientwicklerteam. Was ist eigentlich mit "TEAM-B" gibt es die noch?

Mavarik

[Perlsau]

Zitat:

Zitat von Furtbichler (Beitrag 1242149)

Das verwirrt mich: Ist das Leben als Delphiprogrammierer nun mit THC oder mit C2H5OH besser auszuhalten? :gruebel:

Dazu fällt mir nur ein: Drogenkonsum beim Programmieren ist kontraproduktiv.

[Namenloser]

Zitat:

Zitat von Perlsau (Beitrag 1242246)

Zitat:

Zitat von Furtbichler (Beitrag 1242149)

Das verwirrt mich: Ist das Leben als Delphiprogrammierer nun mit THC oder mit C2H5OH besser auszuhalten? :gruebel:

Dazu fällt mir nur ein: Drogenkonsum beim Programmieren ist kontraproduktiv.

Nicht unbedingt. Koffeinkonsum ist sehr produktiv ;)

[Perlsau]

Zitat:

Zitat von Namenloser (Beitrag 1242247)

Nicht unbedingt. Koffeinkonsum ist sehr produktiv ;)

Da hast du natürlich recht: Der durchschnittliche Programmierer ist Kaffeevernichter. Eigentlich meinte ich ja auch nur die Drogen, welche Denkleistung und -fähigkeit negativ beeinflussen. Ich bin schon nach einem Bier nicht mehr fähig, zu programmieren, da mach ich die seltsamsten Fehler. Und THC schon gar nicht, das geht nämlich stark auf's Kurzzeitgedächtnis. :lol:

[Furtbichler]

Zitat:

Zitat von Mavarik (Beitrag 1242240)

Ich konnte 31 Jahre auf Generics verzichten und mir hat nix gefehlt.

Jo. Wenn man nicht weiß, was es so alles gibt, ist ja auch klar, das einem das nicht fehlt. :lol:

Zitat:

Der Kunde sieht nicht wie ich das programmiert habe. Und schneller wird es dadurch auch nicht.

Der Hausbesitzer sieht auch nicht sofort, ob Du billigen Mumpitz verbaut hast oder Qualitätsmaterial und ob Du als Architekt ordentlich konzipiert hat oder das Haus einfach einsfixdrei hochgezogen hast. Das Haus hat doch nen Dach, Fenster, Zimmer, und die Spüle geht auch. Was will man mehr. ;-)
Ich kann mir auch nicht vorstellen, das Du ein Flugzeug fliegen würdest, was so wie deine SW erstellt wurde, oder ("Hebt ab, bleibt in der Luft. Topp.") Na ja. Mach deinen Kram als Maverick. Der Nick passt ja. ;-)

Zitat:

Das bedeutet jedoch nicht, dass ich mich Neuem verschließen würde.

Doch. Du verschließt dich moderner und stabilerer Architektur (300 Zeilen THEN-Abschnitte :lol:). Aber das ist ok. Wenn es deinen Ansprüchen genügt.

Auch eine Gartenlaube hält dem Regen stand.

[jaenicke]

Zitat:

Zitat von Perlsau (Beitrag 1242248)

Zitat:

Zitat von Namenloser (Beitrag 1242247)

Nicht unbedingt. Koffeinkonsum ist sehr produktiv ;)

Da hast du natürlich recht: Der durchschnittliche Programmierer ist Kaffeevernichter.

Nein, der durchschnittliche Programmierer ist ein Gerät um Kaffee in Quelltext umzuwandeln...

[Mavarik]

[OT]

Zitat:

Zitat von Furtbichler;1242253 Na ja. Mach deinen Kram als [URL="http://de.wikipedia.org/wiki/Maverick"

Maverick[/URL]. Der Nick passt ja. ;-)

Sorry falscher Link zu Wikipedia das ist der Richtige.

Außerdem schreibe ich es anders, aber das ist eine andere Geschichte.
[/OT]

[hanspeter]

Ohne Kaffee ist Delphi nicht zu ertragen.

In der Firma arbeite ich mit D2007.
Die IDE ist das verbuggteste Teil, was mir je in meiner Praxis untergekommen ist.
Wegen Unicode besteht auch nicht viel Hoffnung, auf eine neuere Version zu updaten.
Obwohl seit dem Mobilehype tut sich ja auch für Bestandskunden nicht mehr viel.
Ich habe den Eindruck, dass die Umstellung auf Unicode nicht gerade eine Glanzleistung ist.
Es kann eigentlich nicht sein, dass der gleiche Datentyp (String) ein untgerschiedliches Format hat.
Jenachdem ob er mit Index oder ohne verwendet wird.


Gruß
Peter

[Furtbichler]

Zitat:

Zitat von Mavarik (Beitrag 1242380)

Sorry falscher Link

Eigentlich dachte ich an den hier. "Top Gun" war mir enfleucht. Aber es war auch nicht ganz ernst gemeint.

[mkinzler]

Zitat:

Ich habe den Eindruck, dass die Umstellung auf Unicode nicht gerade eine Glanzleistung ist.

Das ligt aber ausnahmsweise nicht an Delphi, sondern an der Tatsache, dass man sich auf implementierungsdetails verlassen hat. (z.B. in Zeichen = 8Bit). Zudem war der Stringtyp schon immer ein "virtueller" Typ. Wer explizit einen Ansistring wollte, konnte dies auch vorher durch Verwendung dieses Strings tun und hätte dann nach der Umstellung auf Unicode keine Probleme gehabt.

[Insider2004]

Zitat:

Zitat von hanspeter (Beitrag 1242629)

Ohne Kaffee ist Delphi nicht zu ertragen.

In der Firma arbeite ich mit D2007.
Die IDE ist das verbuggteste Teil, was mir je in meiner Praxis untergekommen ist.
Wegen Unicode besteht auch nicht viel Hoffnung, auf eine neuere Version zu updaten.
Obwohl seit dem Mobilehype tut sich ja auch für Bestandskunden nicht mehr viel.
Ich habe den Eindruck, dass die Umstellung auf Unicode nicht gerade eine Glanzleistung ist.
Es kann eigentlich nicht sein, dass der gleiche Datentyp (String) ein untgerschiedliches Format hat.
Jenachdem ob er mit Index oder ohne verwendet wird.


Gruß
Peter

In D2007 gibt es kein Unicode. In XE arbeitet Unicode einwandfrei.

[Bernhard Geyer]

Zitat:

Zitat von Insider2004 (Beitrag 1242641)

In D2007 gibt es kein Unicode. In XE arbeitet Unicode einwandfrei.

Das meint er ja. Er hat sagen wir mal "supoptimalen" Code und müsste ür Versionen >= 2009 seinen Code korrigieren aber das sieht er nicht ein.

[Memnarch]

Zitat:

Zitat von hanspeter (Beitrag 1242629)

Es kann eigentlich nicht sein, dass der gleiche Datentyp (String) ein untgerschiedliches Format hat.
Jenachdem ob er mit Index oder ohne verwendet wird.

Das verstehe ich absolut nicht, was meinst du den damit?

[DeddyH]

Reine Vermutung meinerseits, was er gemeint haben könnte:

Delphi-Quellcode:

var
  s1: string; //langer String, UTF-16 ab Delphi 2009
  s2: string[100]; //kurzer String, immer Ansi

[mkinzler]

Delphi-Quellcode:

var
  s0: string; //vor Delphi 2009 entweder Shortstring oder langer String (ANSI) je nach Einstellung,   ab Delphi 2009 UniCodeString(UTF-16)
  s1: AnsiString; //langer String immer Ansi
  s2: string[100]; //kurzer String (Shortstring), immer Ansi

String ist ein virtueller Typ; wenn man einen bestimmten will muss man eine konkreten Stringtyp ( AnsiString, Unicodestring verwenden!

[jaenicke]

Zitat:

Zitat von mkinzler (Beitrag 1242662)

String ist ein virtueller Typ; wenn man einen bestimmten will muss man eine konkreten Stringtyp ( AnsiString, Unicodestring verwenden!

Wenn man sich denn hätte auf so etwas verlassen können, würde es Sinn machen seinen Code entsprechend zu schreiben. (Mache ich auch)
Das habe ich bei Integer aber auch gemacht... und dann kam 64-Bit und rumms, alles neu schreiben.

[mkinzler]

Beim Integer haben sie sich nicht daran gehalten, obwohl Integer auch ein "virtueller" Typ war.
Darum schrieb ich ja, dass es in diesem Fall "ausnahmsweise" nicht an Delphi/EMBT liegt.
Das der Integertyp sicht mehr wächst und der geänderte Startindex beim String (nextgen) schon.

[Bernhard Geyer]

Zitat:

Zitat von mkinzler (Beitrag 1242764)

Beim Integer haben sie sich nicht daran gehalten, obwohl Integer auch ein "virtueller" Typ war.

Beim Integer hat man halt das gemacht was der Rest der Sprachen-Welt auch gemacht hat. Unter 64-Bit integer trotzdem bei 32-Bit gelassen.
Der Aufschrei/Ärger wäre größer wenn Delphi hier den eigen/eigentlich konsequenteren Weg gegangen wäre.

[Furtbichler]

Ganz ehrlich? Ich finde es generell ein no-go, wenn Datentypen in der Entwicklung einer Sprache ihren Aufbau ändern. Wieso hat man das bei 'Real' denn nicht auch gemacht? Nee, da wurde aus purem Zufall (FPU) der Datentyp Single,Double und Extended eingeführt (Gott-Sei-Dank). Und Boolean wurde auch so gelassen, stattdessen gibt es dann WordBool, LongBool.

Wieso war man bei Integer und String so dämlich? Na, Delphi eben. :wall: Und jetzt soll mir bloß keiner kommen, das das so sein musste. Musste es nicht. Es gibt für alles eine Lösung.

[jaenicke]

Zitat:

Zitat von Furtbichler (Beitrag 1242789)

Ganz ehrlich? Ich finde es generell ein no-go, wenn Datentypen in der Entwicklung einer Sprache ihren Aufbau ändern.

Dafür sind es per Definition Metadatentypen, die per Definition keinen festen Aufbau haben.
Wenn man das braucht, gibt es ja entsprechend die Datentypen, deren Aufbau fest definiert ist.

Da das in der Liste der Datentypen auch eindeutig so definiert ist, hätte es damit eigentlich keine Probleme geben sollen. Das war selbst mir ziemlich am Anfang klar als ich mit Delphi angefangen habe. Ich habe zwar einiges falsch oder ungünstig gemacht und habe mich bei API Aufrufen etwas dumm angestellt (kann man in meinen ersten Posts von vor 10 Jahren vielleicht auch noch sehen :oops:), aber das stand in der Hilfe und war damit auch klar.

Bei Ansi <--> Unicode hatte ich daher in meinen privaten Projekten so gut wie keinen Umstellungsaufwand. Nur bei Integer, wo die Vorgehensweise eben nicht der Dokumentation entsprach, musste ich Anpassungen machen.

[Namenloser]

Zitat:

Zitat von Furtbichler (Beitrag 1242789)

Wieso hat man das bei 'Real' denn nicht auch gemacht?

Hat man doch! Heute ist Real äquivalent zu Single, aber ursprünglich hatte Real ein anderes Format. Dieses kann man auch heute noch explizit verwenden, in Form von Real48. Aber weil es auf modernen Prozessoren langsam ist (würde mich nicht wundern, wenn es emuliert werden muss), ist es nicht mehr der Standard-Alias für Real.

[Jumpy]

Hallo,

nur mal aus Neugier, da ich noch nicht so lange dabei bin, das ich mal ein altes Projekt hätte umstellen müssen, bzw. das eine was ich von D6 auf D2010 umgestellt habe hat kaum Probleme gemacht:

Wo liegt denn das Problem bei den Strings oder Integern? Bzw. wann hätte man Probleme damit bekommen? Wenn man mit Pointern arbeitet oder so?

Delphi-Quellcode:

var s:String;
begin
  s:='blub';
  showmessage(s);
end;

wird ja wohl kaum Probleme machen.

[Bernhard Geyer]

Zitat:

Zitat von Furtbichler (Beitrag 1242789)

Wieso war man bei Integer und String so dämlich? Na, Delphi eben. :wall:

MS hat es mit C genau so gemacht. Integer ist gewachen und auch unter 64-Windows ist der Integer jetzt 32-Bit lang. Na, Microsoft eben. :wall:
Und wie ist es mit CString in C++? 8 Bit wenn nicht Unicode und 16 Bit (hier geht man nicht darauf ein ob jetzt UCS-2 oder UTF-16 verwendet wird (man nimmt halt das was das OS nimmt, also NT: UTC-2 und danach UTF-16)

[DeddyH]

Zitat:

Zitat von Jumpy (Beitrag 1242797)

Wo liegt denn das Problem bei den Strings oder Integern?

http://docwiki.embarcadero.com/RADSt...icode_anpassen

Zitat:

Suchen Sie nach Quelltext, der:

davon ausgeht, dass SizeOf(Char) 1 ist.
davon ausgeht, dass die Länge (Length) eines Strings gleich der Byte-Anzahl in dem String ist.
Strings oder PChars direkt manipuliert.
Strings in oder aus einem persistenten Speicher liest oder schreibt.

Die beiden ersten Annahmen sind für Unicode nicht zutreffend, weil bei Unicode SizeOf(Char) größer als 1 Byte sein kann, und die Länge (Length) eines Strings doppelt so groß ist wie die Anzahl der Bytes. Darüber hinaus muss Code, der in einen persistenten Speicher schreibt oder daraus liest, gewährleisten, dass die korrekte Anzahl von Bytes geschrieben oder gelesen wird, da ein Zeichen evtl. nicht mehr durch ein einzelnes Byte repräsentiert werden kann.

[Mavarik]

Zitat:

Zitat von Jumpy (Beitrag 1242797)

Delphi-Quellcode:

var s:String;
begin
  s:='blub';
  showmessage(s);
end;

wird ja wohl kaum Probleme machen.

Ne aber ein

Delphi-Quellcode:

var
  S    : Array [0..255] of Char;
  Name : Shortstring;
begin
  Name := 'Meine Mainformtitle'+#0;
  Move(Name[1],S[0],length(Name));
 ...
end;

schon...

[arnof]

Also ohne alles hier durchzulesen:

viele viele haben noch URALT Versionen aus Borlandzeiten!!!!!!!

Da ich nun auch Komponenten vermarkte ist mir das sehr aufgefallen:

Gestern habe ich erst wieder schreiben müssen, das ich Delphi 3 nicht unterstützte :cyclops: Ich schaue ja immer mal mir die Homepage von Kunden an. Hier stand zu lesen hochmoderne RAD Entwicklungsumgebung, da konnte ich mir das grinsen nicht verkneifen!

50% der Käufer benutzt Delphi 5

[Jumpy]

Zitat:

Delphi-Quellcode:

var
  S    : Array [0..255] of Char;
  Name : Shortstring;
begin
  Name := 'Meine Mainformtitle'+#0;
  Move(Name[1],S[0],length(Name));
 ...
end;

Klingt jetzt bestimmt ketzerisch ist aber echt nicht böse gemeint. Warum macht man sowas?
Ich hab ähnliches schon benutzt um Buffer oder variable Records oder sowas, die man von API-Funktionen zurückkriegt auszulesen, aber sonst?
Wie gesgagt echt nicht böse gemeint.

Und ist das bei den Integern genauso? Also das es letztlich damit zu tun hat wie die gespeichert werden?

[mkinzler]

Das Problem beim Integer ist anders gelagert. Er war eigentlich ein "wachsender" Typ; also ein Typ, der sich an die Plattform anpasst ( 16-Bit-Exe: 16Bit; 32-Bit-Exe: 32Bit) Für diesen Zweck haben ihn Viele verwendet. Mit Einführung des 64-Bit Compilers wurde der Typ aber auf 32Bit festgeschrieben und ein neuer virtueller Typ NativeInt eingeführt, der wächst. Alle die sich darauf verlassen haben, das ein Integer immer die Breite der Plattform hat, mussten dann ihren Code ändern.

[Delphi-Laie]

Zitat:

Zitat von mkinzler (Beitrag 1242832)

Das Problem beim Integer ist anders gelagert. Er war eigentlich ein "wachsender" Typ; also ein Typ, der sich an die Plattform anpasst ( 16-Bit-Exe: 16Bit; 32-Bit-Exe: 32Bit) Für diesen Zweck haben ihn Viele verwendet. Mit Einführung des 64-Bit Compilers wurde der Typ aber auf 32Bit festgeschrieben und ein neuer virtueller Typ NativeInt eingeführt, der wächst. Alle die sich darauf verlassen haben, das ein Integer immer die Breite der Plattform hat, mussten dann ihren Code ändern.

Ist es mit Cardinal nicht genauso?

Ich kann mich erinnern, das früher schon moniert zu haben, daß eine festgelegte - scheinbar für alle Ewigkeiten gültige - Marschrichtung schon beim nächsten Wechsel der Bitanzahl wieder fallengelassen wurde.

[mkinzler]

Cardinal ist 32Bit und war auch immer so geplant. Aber Integer was "wachsend", bis sich MS anders entschieden hat und EMBT nachgehechelt hat!

[Delphi-Laie]

Zitat:

Zitat von mkinzler (Beitrag 1242875)

Cardinal ist 32Bit und war auch immer so geplant. Aber Integer was "wachsend", bis sich MS anders entschieden hat und EMBT nachgehechelt hat!

Nein, das stimmt nicht. Cardinal wurde mit seiner Einführung (Delphi 1?!) als "generisch" tituliert und hatte 16 Bit. Konsequenterweise bot dieser Datentyp ab Delphi 2 dann auch 32 Bit.

[Bernhard Geyer]

Zitat:

Zitat von mkinzler (Beitrag 1242875)

... Aber Integer was "wachsend", bis sich MS anders entschieden hat und EMBT nachgehechelt hat!

Ob nur MS sich so entschieden hat?
MS verwendet das LLP64-Modell wo int auch unter 64-Bit 32-Bit groß ist
Wohingehend der größte Teil der "Restwelt" nach LP64 geht wo - oh wie blöd - int unter 64-Bit ebenfalls 32-Bit groß bleibt.

Einzig im ILP64 und SILP64 lassen int mitwachsen. Aber ob es sinnvoll gewesen wäre diesen "Aussenseitersystemen" wie HAL, SPARC64 oder UNICOS zu folgen mag ich beweifeln. Dafür hat UNICOSE die spezielle Idee auch short auf 64-Bit zu heben.

Für den "Rest" der Welt ist int mittlerweile normale das int einfach auf 4-Byte größe verharrt und haben ihre Programme schon angepasst. Blos wir Delphianer trauern der (m. E. richtigen) Entscheidung von Emba nach.

[Daniel]

Wir brauchen einen "Like-Button". Vielleicht ohne Anglizismus, mehr im Sinne von "Scheiße nochmal - der Kerl hat aber sowas von verdammt Recht".
:mrgreen:

[rapante]

Zitat:

Zitat von Daniel (Beitrag 1242891)

Wir brauchen einen "Like-Button". .
:mrgreen:

Scheiße nochmal - der Kerl hat aber sowas von verdammt Recht :lol:

[DeddyH]

Ich stelle mir gerade so ein Symbol vor mit einem gestreckten Daumen und einem Häufchen obendrauf. Scheiße nochmal :lol: