Aufzählung geht nicht
Rene Kadner
in Delphi 2009 habe ich folgendes Problem:
var i: integer;
...
if (i in [1..5]) then -> wird compiliert
if (i in [1000..5000]) then -> wird *nicht* compiliert: Fehler E1012
Konstantenausdruck verletzt untere Grenzen.
D�rfen in einer Aufz�hlung nur 'kleine' Zahlen stehen. Wenn ja, wo ist die
Grenze? In der Hilfe habe ich dazu nichts gefunden.
Was kann ich tun (au�er einer doppelten </> Abfrage) ?
Gru�
Ren�
Heinz Zastrau
> if (i in [1..5]) then -> wird compiliert
> if (i in [1000..5000]) then -> wird *nicht* compiliert: Fehler E1012
> Konstantenausdruck verletzt untere Grenzen.
>
>
> Dï¿œrfen in einer Aufzï¿œhlung nur 'kleine' Zahlen stehen. Wenn ja, wo ist
> die Grenze? In der Hilfe habe ich dazu nichts gefunden.
> Was kann ich tun (auï¿œer einer doppelten </> Abfrage) ?
das Problem ist nicht die Aufzï¿œhlung .. sondern die Menge.
Mit 1000..5000 definierst Du ein Aufzï¿œhlung von 1000..5000. Durch die
eckigen Klammer drumherum baust du eine Menge die alle Werte der
Ausfzï¿œhlung enthï¿œlt. Leider kann eine Menge nur bis zu 512 Werte
enthalten. Deswegen erhï¿œlts Du die Fehlermeldung.
Alternativen:
if (1000 <= i) and (i <= 5000) then ...;
oder
case i of
1000..5000: ...;
end;
Ciao Heinz Z.
Martin Behrens
> in Delphi 2009 habe ich folgendes Problem:
>
> var i: integer;
> ...
> if (i in [1..5]) then -> wird compiliert
> if (i in [1000..5000]) then -> wird *nicht* compiliert: Fehler E1012
> Konstantenausdruck verletzt untere Grenzen.
Mengen d�rfen nur maximal 256 Werte haben.
Martin
Heinz Zastrau
> Mengen dï¿œrfen nur maximal 256 Werte haben.
das ist Richtig. :-)
Ciao Heinz Z.
Holger Lembke
>Hallo Martin,
>
>> Mengen d�rfen nur maximal 256 Werte haben.
>
>das ist Richtig. :-)
<aufzeig und h�pf aufgeregt>
Und das mit dem IF war auch falsch!!!!elf
</aufzeig und h�pf aufgeregt>
--
mit freundlichen Gr��en! Password Must Be at Least 18770 Characters
Holgi, +49-531-3497854 ! Can't Repeat Any of Your Previous 30689 Passwords
Rene Kadner
> if (1000 <= i) and (i <= 5000) then ...;
die hier nicht ganz :-), aber vom Prinzip her klar.
> case i of
> 1000..5000: ...;
> end;
Das wï¿œre nicht schlecht, wï¿œrden nicht noch weitere Bedingungen in der IF
Anweisung stehen.
Das mit dem Menge oben wï¿œre einleuchtend. Ein "in [1000, 5000]" fï¿œhrt aber
zur gleichen Fehlermeldung. Das kï¿œnnte der Compiler ja "lï¿œssig" in ein OR
wandeln.
-> Durch Versuche habe ich nun herausbekommen, dass innerhalb der []
Klammern nur Zahlen bis 255 akzeptiert werden. Deine 512 oben sind also
leider auch schon zu viel.
Gruￜ
Renￜ
Heinz Zastrau
> <aufzeig und hï¿œpf aufgeregt>
>
> Und das mit dem IF war auch falsch!!!!elf
>
> </aufzeig und hï¿œpf aufgeregt>
und weil du so aufmerksam bist, darfst Du auch noch erklï¿œren was falsch
ist.
Ciao Heinz Z.
Heinz Zastrau
>> if (1000 <= i) and (i <= 5000) then ...;
> die hier nicht ganz :-),
was fehlt DIr denn da noch?
>> case i of
>> 1000..5000: ...;
>> end;
> Das wï¿œre nicht schlecht, wï¿œrden nicht noch weitere Bedingungen in der IF
> Anweisung stehen.
Wieso lassen denn weitere Bedingungen diese Lï¿œsung schlect aussehen?
Ciao Heinz Z.
Holger Lembke
>>> if (1000 <= i) and (i <= 5000) then ...;
>> die hier nicht ganz :-),
>
>was fehlt DIr denn da noch?
Ein >
Carsten Thumulla
> Deine 512 oben sind also leider auch schon zu viel.
Zu Mengen gibt es eine Compileroption, diese hochzusetzen.
Carsten
Heinz Zastrau
>>>> if (1000 <= i) and (i <= 5000) then ...;
>>> die hier nicht ganz :-),
>>
>> was fehlt DIr denn da noch?
>
> Ein >
das Statement
if (1000 <= i) and (i <= 5000) then ...;
liefert die gleiche Treffer wie
case i of
1000..5000: ...;
end;
und auch die gleich Treffer wie
if i in [1000..5000] then ...;
wenn es sich compilieren lieï¿œe. Nehme als Grenzen 10 und 50 und Du kannst
alle 3 Varianten prï¿œfen. Mir erscheint da ein ">" eher ï¿œberflï¿œssig.
Ciao Heinz Z.
Andrej Kluge
Heinz Zastrau wrote:
> das Statement
>
> if (1000 <= i) and (i <= 5000) then ...;
>
> liefert die gleiche Treffer wie
Es liest sich aber sehr ungewohnt, wie du zugeben muï¿œt. Oder?
Ciao
AK
Heinz Zastrau
>> if (1000 <= i) and (i <= 5000) then ...;
>>
>> liefert die gleiche Treffer wie
>
> Es liest sich aber sehr ungewohnt, wie du zugeben muï¿œt. Oder?
naja, da ich das schon mehrere Jahre mache ist das fï¿œr mich das
natï¿œrlichste der Welt. Ich habe mir das aber nicht ausgedacht sondern aus
dem anerkannt guten Buch "Code Complete" von Steve McConnell ï¿œbernommen.
Ich fand seine Argumentation schlï¿œsssig und seit dem formatiere ich solche
Ausdrï¿œcke so. In Delphi Prism kann man sogar gleich einen Schritt weiter
gehen und
if 1000 <= i <= 5000 then ...;
formulieren.
Ciao Heinz Z.
Holger Lembke
> Mir erscheint da ein ">" eher �berfl�ssig.
Ja. Danke. Jetzt sehe ich es auch.
Hubert Seidel
"Carsten Thumulla" <m...@privacy.net> schrieb im
Newsbeitrag news:e0a9f$4af04698$d9ba1fcb$75...@news1.surfino.com...
> Rene Kadner wrote:
>
> > Deine 512 oben sind also leider auch schon zu viel.
>
> Zu Mengen gibt es eine Compileroption, diese hochzusetzen.
Echt? Ab welcher Version ist das wie m�glich?
In der D5 OH steht:
<Zitat>
Eine Menge ist ein Array von Bits. Jedes Bit zeigt an, ob ein Element in
der Menge enthalten ist oder nicht. Da die maximale Anzahl der Elemente
einer Menge 256 betr�gt, belegt eine Menge nie mehr als 32 Bytes. Die
Anzahl der Bytes, die eine bestimmte Menge belegt, ergibt sich wie
folgt:
(Max div 8) - (Min div 8) + 1
Max und Min sind die obere und die untere Grenze des Basistyps der
Menge. Die Position des Byte eines speziellen Elements E ergibt sich wie
folgt:
(E div 8) - (Min div 8)
Die Position des Bit in diesem Byte ergibt sich aus
E mod 8
Dabei ist E der ordinale Wert des Elements.
</Zitat>
Offensichtlich wird ein Element der Menge mit ein Bit dargestellt.
Gr��ere Mengentyen k�nnen demnach sehr speicherindensiv oder langsam
werden.
Das schliest nat�rlich nicht aus, das es die in sp�teren Versionen geben
k�nnte.
mfg.
Herby
--
http://www.hubert-seidel.eu
Carsten Thumulla
> "Carsten Thumulla" <m...@privacy.net> schrieb im
>>> Deine 512 oben sind also leider auch schon zu viel.
>> Zu Mengen gibt es eine Compileroption, diese hochzusetzen.
>
> Echt? Ab welcher Version ist das wie m�glich?
Bei D7 finde ich Mindestgr��e von Enum-Typen.
{$Z1} oder {$Z2} oder {$Z2}
Ich habs noch nicht benutzt, dachte, da� es hilft.
Eigentlich dachte ich mir, da� man damit ja auch die m�glichen Mengen
erh�ht. M��te ich mal probieren.
> Offensichtlich wird ein Element der Menge mit ein Bit dargestellt.
> Gr��ere Mengentyen k�nnen demnach sehr speicherindensiv oder langsam
> werden.
sicher
Carsten
--
"N�, in die Schule will ich nicht. Ich warte lieber noch drei Jahre bis
ich alles wei�."
Carsten Thumulla
>
> Bei D7 finde ich Mindestgr��e von Enum-Typen.
> {$Z1} oder {$Z2} oder {$Z2}
Wirkt nur auf Enum, nicht auf Mengen.
Sieghard Schicktanz
Du schriebst am Tue, 3 Nov 2009 16:46:26 +0100:
> > if (1000 <= i) and (i <= 5000) then ...;
...
> Es liest sich aber sehr ungewohnt, wie du zugeben muï¿œt. Oder?
Na, jetzt hï¿œrt sich das aber langsam schon bisserl nach PISA-Schaden an...
_Was_ ist an der Angabe "1000 <= i <= 5000" ungewï¿œhnlich?
Fï¿œr eine Programmiersprache, die keine mehrfachen Vergleiche verarbeiten
kann (fast alle) muￜ das eben ein wenig auseinandergezogen werden - eben
zu "(1000 <= i) and (i <= 5000)".
Versteh' ich nicht, was man dadran nicht verstehen kï¿œnnte...
--
(Weitergabe von Adressdaten, Telefonnummern u.ￜ. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ï¿œhnlichem)
-----------------------------------------------------------
Mit freundlichen Grￜￜen, S. Schicktanz
-----------------------------------------------------------
Hans-Peter Diettrich
>>>> Deine 512 oben sind also leider auch schon zu viel.
>>> Zu Mengen gibt es eine Compileroption, diese hochzusetzen.
>>
>> Echt? Ab welcher Version ist das wie m�glich?
>
> Bei D7 finde ich Mindestgr��e von Enum-Typen.
> {$Z1} oder {$Z2} oder {$Z2}
>
> Ich habs noch nicht benutzt, dachte, da� es hilft.
Es hilft nicht, da es sich auf Variablen vom Typ "enum" bezieht, nicht
auf daraus konstruierte *sets*.
>> Offensichtlich wird ein Element der Menge mit ein Bit dargestellt.
>> Gr��ere Mengentyen k�nnen demnach sehr speicherindensiv oder langsam
>> werden.
Solange man die Set-Operatoren f�r boolesche Ausdr�cke verwendet, sind
sie verdammt schnell. Bei Mengen-Operationen wird jede
Programmiersprache langsam.
DoDi
Andrej Kluge
Sieghard Schicktanz wrote:
> Na, jetzt hï¿œrt sich das aber langsam schon bisserl nach PISA-Schaden
> an...
Na, na.
> Fï¿œr eine Programmiersprache, die keine mehrfachen Vergleiche
> verarbeiten kann (fast alle) muￜ das eben ein wenig
> auseinandergezogen werden - eben zu "(1000 <= i) and (i <= 5000)".
Nur aus Interesse: steht eine if-Afrage so formuliert in irgend einem der
Delphi-Quelltexte?
Ciao
AK
Christian Gudrian
> Nur aus Interesse: steht eine if-Afrage so formuliert in irgend einem
> der Delphi-Quelltexte?
FindResource (System.pas):
if ('A' <= ch) and (ch <= 'Z') then Inc(ch, Ord('a') - Ord('A'));
Christian
--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
Andrej Kluge
Christian Gudrian wrote:
>> Nur aus Interesse: steht eine if-Afrage so formuliert in irgend einem
>> der Delphi-Quelltexte?
>
> FindResource (System.pas):
>
> if ('A' <= ch) and (ch <= 'Z') then Inc(ch, Ord('a') - Ord('A'));
Ok, danke.
Ciao
AK
Andreas Mosmann
<7lecmrF...@mid.individual.net>:
> Solange man die Set-Operatoren f�r boolesche Ausdr�cke verwendet, sind
> sie verdammt schnell. Bei Mengen-Operationen wird jede
> Programmiersprache langsam.
> DoDi
Ich will mich ja nicht streiten, aber das mit dem "langsam" ist relativ.
Ich programmiere v.a. Datenbanksoftware. Wei�t Du, wieviele Millionen
Mengenoperationen Du so machen k�nntest, anstatt eine Datenbankabfrage
zu stellen?
Aus meiner pers�nlichen Sicht ist es wesentlich wichtiger, den Quelltext
so durchschaubar wie m�glich zu halten, als auf Geschwindigkeit (bei der
Verwendung bordeigener Mittel) zu achten. Ich werfe achtlos mit
TStringLists um mich, nur um 2-3 Zeilen formatiert in ein TRichEdit zu
werfen, und bem�he regul�re Ausdr�cke, um ein "A 44 X" in seine
Bestandteile zu zerlegen und habe damit gar kein schlechtes Gewissen.
Wenn ich die gesparte Zeit einsetze, um damit meine DB- Zugriffe zu
optimieren, verringert sich der Zeitbedarf der Anwendung deutlich mehr.
Andreas
der Dir hiermit nicht widersprechen, sondern lediglich andere Akzente
setzen wollte. Wenn Delphi ein Set [0..10000000] m�glich machen w�rde,
dann w�rde ich das begr��en. Nicht, dass ich daf�r im Moment eine
Verwendung h�tte, aber allein, dass es ginge, f�nde ich gut. Zeit spielt
in meinem Kontext keine Rolle, da das Ausbremsende idR immer ein Zugriff
auf eine Datenbank hinter einer notorisch zu d�nnen Leitung ist.
Ich habe viel Aufwand in ein (hauseigenes und sehr spezielles) Framework
gesteckt, dass massgeschneidert dynamische SQL- Abfragen generiert - nur
um einerseits das Quelltext- Handling und andererseits die
Datenbankabfragen zu verbessern. Dazu baue ich im Speicher
verschwenderischst irgendwelche Strukturen auf. Und ich habe nicht ein
einziges mal gemerkt, dass das irgendeinen negativen Einflu� auf das
Laufzeitverhalten oder den Speicherverbrauch hatte. Im Moment reden wir
von Hauptspeicher im Gb- Bereich und von Prozessoren, die im GHz-
Bereich getaktet sind. Wenn mein Rechner das k�nnte, dann f�nde er noch
m�helos Zeit, zwischen den Abfragen f�r mich einkaufen zu gehen.
--
wenn email, dann AndreasMosmann <bei> web <punkt> de
Hans-Peter Diettrich
>> Solange man die Set-Operatoren f�r boolesche Ausdr�cke verwendet, sind
>> sie verdammt schnell. Bei Mengen-Operationen wird jede
>> Programmiersprache langsam.
>
>> DoDi
>
> Ich will mich ja nicht streiten, aber das mit dem "langsam" ist relativ.
> Ich programmiere v.a. Datenbanksoftware. Wei�t Du, wieviele Millionen
> Mengenoperationen Du so machen k�nntest, anstatt eine Datenbankabfrage
> zu stellen?
Ein Result-Set in einer Datenbankabfrage ist eine Menge (Liste) von
Objekten, wohingegen die Delphi-Sets eher fest dimensionierten Arrays of
Boolean entsprechen.
Wenn schon, dann entspr�che ein Set in einer Datenbankabfrage einem
(dynamischen) Array of T, nicht einem (festen) Set of T. Entsprechend
unterscheidet sich auch die Navigation in solchen "Sets" (relativ oder
absolut). W�hrend bei Datenbanken die Navigation zum n�chsten Element
eine fundamentale O(1) Operation ist, geht das in Sets nur mit einer
O(n) Schleife.
> Aus meiner pers�nlichen Sicht ist es wesentlich wichtiger, den Quelltext
> so durchschaubar wie m�glich zu halten, als auf Geschwindigkeit (bei der
> Verwendung bordeigener Mittel) zu achten. Ich werfe achtlos mit
> TStringLists um mich, nur um 2-3 Zeilen formatiert in ein TRichEdit zu
> werfen, und bem�he regul�re Ausdr�cke, um ein "A 44 X" in seine
> Bestandteile zu zerlegen und habe damit gar kein schlechtes Gewissen.
Da sind wir uns v�llig einig :-)
> Andreas
> der Dir hiermit nicht widersprechen, sondern lediglich andere Akzente
> setzen wollte. Wenn Delphi ein Set [0..10000000] m�glich machen w�rde,
> dann w�rde ich das begr��en.
Schau mal nach TBits :-)
Und �berlege Dir auch, wie gro� so ein Set im Speicher wird. Bei
Datenbanken ist die Gr��e eines Sets undefiniert, sie wird erst zur
Laufzeit bestimmt. In Delphi w�rde ein Set of Char eine betr�chtliche
feste Gr��e haben, wenn Char (neuerdings) ein WideChar ist!
DoDi