Hallo NG,

ich habe gleich noch eine Frage. Sie betrifft die zahlreichen
Konvertierungsmöglichkeiten. Welche sollte man wann anwenden? Werden die
VB-spezifischen Funktionen (CInt,...) auch in Zukunft unterstützt?
Ich möchte konkrete Beispiele nennen; die Konvertierung soll sicher und
möglichst performant sein:

1.) String --> Integer , wobei String eine Benutzereingabe ist
2.) String --> Integer , String enthält garantiert eine gültige Int-Zahl
3.) double, decimal, single --> Integer, Ergebnis soll richtig gerundet
werden, der Wertebereich für Int ist garantiert eingehalten
4.) double, decimal, single --> Integer, wie 3. aber der Wertebereich kann
überschritten sein
5.) ein Objekt (z.B. die Datenzelle einer DataRow) --> Integer; die
Datenzelle enthält garantiert einen gültigen Int-Wert
6.) wie 5.), jedoch kann die Datenzelle auch DBNull sein

In diesem Zusammenhang noch eine Frage:
Was ist besser: Dim i as Integer oder Dim i as System.Int32 ?
Wo ist der Unterschied?

Viele Grüße
Hans-Rüdiger

Hans-Rüdiger Hanke wrote:
....
> ich habe gleich noch eine Frage. Sie betrifft die zahlreichen
> Konvertierungsmöglichkeiten. Welche sollte man wann anwenden? Werden
> die VB-spezifischen Funktionen (CInt,...) auch in Zukunft unterstützt?

Hans-Rüdiger,
die Wahrscheinlcihkeit ist hoch, dass das noch ein paar Versionen so bleiben
wird. Durch die Möglichkeit der parallelen Nutzung der unterschiedlichen
Framework-Versionen dürfte das aber überhaupt kein Problem für die Zukunft
sein.

> Ich möchte konkrete Beispiele nennen; die Konvertierung soll sicher
> und möglichst performant sein:
>
> 1.) String --> Integer , wobei String eine Benutzereingabe ist

Viel wichtiger sind die Prüfungen auf Falscheingaben. Da bietet sich
TryParse an.

> 2.) String --> Integer , String enthält garantiert eine gültige
> Int-Zahl

Val - wenn es amerikanisch ist, sonst CInt, wenn die Zahlendarstellung lokal
ist.

> 3.) double, decimal, single --> Integer, Ergebnis soll richtig
> gerundet werden, der Wertebereich für Int ist garantiert eingehalten

Was ist "richtig gerundet"? Kaufmännisch oder mathematisch?

> 4.) double, decimal, single --> Integer, wie 3. aber der
> Wertebereich kann überschritten sein

Vorher prüfen!

> 5.) ein Objekt (z.B. die Datenzelle einer DataRow) --> Integer; die
> Datenzelle enthält garantiert einen gültigen Int-Wert

Auf Typ casten!

> 6.) wie 5.), jedoch kann die Datenzelle auch DBNull sein

vorher auf DBNull testen.

> In diesem Zusammenhang noch eine Frage:
> Was ist besser: Dim i as Integer oder Dim i as System.Int32 ?
> Wo ist der Unterschied?

Schau dir mal die Auflösung im Reflector an.

Peter

"Hans-Rüdiger Hanke" wrote:

[..]
> 5.) ein Objekt (z.B. die Datenzelle einer DataRow) --> Integer; die
> Datenzelle enthält garantiert einen gültigen Int-Wert
> 6.) wie 5.), jedoch kann die Datenzelle auch DBNull sein
>
> In diesem Zusammenhang noch eine Frage:
> Was ist besser: Dim i as Integer oder Dim i as System.Int32 ?
> Wo ist der Unterschied?
>
> Viele Grüße
> Hans-Rüdiger

moin,

zum konvertieren von datentypen kannst du zum einen die vb-variante nehmen,
z.b. cdec, cint, cdbl, cstr usw benutzen, mit denen aber nicht jede
konvertierung möglich ist, z.b. funktionert eine umwandlung eines objektes,
z.b. datarow so nicht
da müßte man die tostring-methode benutzen und dann cint, aber das kann man
auch mit ctype direkt erledigen, damit lassen sich auch objekte konvertieren :

wenn man z.b. drei buttons hat und das click-ereignis der buttons in einer
sub haben möchte, dann muß man den ereignissender mit cytpe(sender, button)
konvertieren, da sender vom typ objekt ist.

ich weiß es nicht ganz genau, aber ich meine wenn man cytpe benutzt, wird es
intern als convert.to-methode benutzt, das ist die .net-variante, kann mich
aber auch irren.

es gibt auch noch die möglichkeit directcast zu benutzen, da weiß ich jetzt
so ad hoc nicht wo da die unterschiede zu den verschiedenen möglichkeiten

dasselbe betrifft integer oder system.int32, ersteres ist die vb-variant und
2. der eigentlich .net datentyp, bietet sich an zu benutzen, wenn man c# und
vb gemischt benutzt.

"rundungsfehler" treten z.b. auf, wenn man einen double oder decimal-wert in
einen integer umwandelt, weil dieser logischweise nur ganzzahlen aufnimmt,
umgekehrt natürlich nicht.


wenn du mit datasets arbeitest, empfiehlt sich die ctype-methode, da du
ansonsten erst den objekt-typ in einen string(.tostring) konvertieren
mü0test, wenn du cint benutzt

die tostring-methode haben viele objekte, nur werden die standardmäßig nicht
von intellisense angezeigt, sind aber vorhanden !

alle datentypen sind auch objekte weshalb diese diverse methoden bereit
stellen, wie z.b. die tostring-methode, die bei datentypen dann einen string
liefert, den mat mit der format-methode z.b. in eine währung umwandeln kann
..format("c")

eine sache gibts noch, das boxing, d.h. die umwandlung von wertetypen in
referenztypen oder wars umgekehrt ? egal, das kann rechenzeit kosten, wenns
sehr viele werden, sollte man im hinterkopf behalten.

gegenteil ist das unboxing, witzigerweise gibt es da unterschied im il-code
von vb.net und c-sharp, weil c# ein unboxing "kennt" und vb erledigt das in 2
oder drei einzelschritten.


ich hoffe das hat ein wenig geholfen

Hallo Peter,
erstmal vielen Dank für deine Mühe(n).
Folgende Fragen habe ich aber noch:

"Peter Fleischer" wrote:

> Hans-Rüdiger Hanke wrote:
> ....

> > 3.) double, decimal, single --> Integer, Ergebnis soll richtig
> > gerundet werden, der Wertebereich für Int ist garantiert eingehalten
>
> Was ist "richtig gerundet"? Kaufmännisch oder mathematisch?

Na, was nimmt man dann am besten für kaufmännische Rundung und was bei
mathematischer Rundung?
>
> > 4.) double, decimal, single --> Integer, wie 3. aber der
> > Wertebereich kann überschritten sein
>
> Vorher prüfen!

Wie?

> > 5.) ein Objekt (z.B. die Datenzelle einer DataRow) --> Integer; die
> > Datenzelle enthält garantiert einen gültigen Int-Wert
>
> Auf Typ casten!

Wie?

>
> > 6.) wie 5.), jedoch kann die Datenzelle auch DBNull sein
>
> vorher auf DBNull testen.

Wie am besten?

>
> > In diesem Zusammenhang noch eine Frage:
> > Was ist besser: Dim i as Integer oder Dim i as System.Int32 ?
> > Wo ist der Unterschied?
>
> Schau dir mal die Auflösung im Reflector an.

Sorry, ich betrachte die Programmierung aus Sicht der
Anwendungsprogrammierung - was zeigt mir denn der Reflector und wie hilft mir
das weiter?

Hans-Rüdiger

Hallo Peter!

"Peter Fleischer" <peter.fleischer_nospam_> schrieb:
>> ich habe gleich noch eine Frage. Sie betrifft die zahlreichen
>> Konvertierungsmöglichkeiten. Welche sollte man wann anwenden? Werden
>> die VB-spezifischen Funktionen (CInt,...) auch in Zukunft unterstützt?
>
> die Wahrscheinlcihkeit ist hoch, dass das noch ein paar Versionen so
> bleiben wird. Durch die Möglichkeit der parallelen Nutzung der
> unterschiedlichen Framework-Versionen dürfte das aber überhaupt kein
> Problem für die Zukunft sein.

'CInt' und Co. wird es wohl noch so lange geben, wie es VB gibt. Für 'CInt'
gibt's schliesslich keine 1:1-Entsprechung im .NET Framework. Siehe dazu
auch:

Conversion operators in VB
<URL:http://www.panopticoncentral.net/archive/2004/06/07/1200.aspx>

DirectCast revealed
<URL:http://www.panopticoncentral.net/archive/2003/07/10/149.aspx>

Hallo Hans-Rüdiger

> Konvertierungsmöglichkeiten. Welche sollte man wann anwenden? Werden die
> VB-spezifischen Funktionen (CInt,...) auch in Zukunft unterstützt?

Wenn du schon so ausdrücklich danach fragst:
Im bereits genannten Link
http://www.panopticoncentral.net/arc...6/07/1200.aspx
sind da die Varianten 1...3 'akzeptabel', Variante 4 dagegen nicht...

Hans-Rüdiger Hanke wrote:
....
> Na, was nimmt man dann am besten für kaufmännische Rundung und was bei
> mathematischer Rundung?

Hans-Rüdiger,
kaufmännisch muss man selbst programmieren, mathematisch machen die
eingebauten Funktionen.

>>> 4.) double, decimal, single --> Integer, wie 3. aber der
>>> Wertebereich kann überschritten sein
>>
>> Vorher prüfen!
>
> Wie?

MinValue, MaxValue!

>>> 5.) ein Objekt (z.B. die Datenzelle einer DataRow) --> Integer; die
>>> Datenzelle enthält garantiert einen gültigen Int-Wert
>>
>> Auf Typ casten!
>
> Wie?

CType(....)

>>> 6.) wie 5.), jedoch kann die Datenzelle auch DBNull sein
>>
>> vorher auf DBNull testen.
>
> Wie am besten?

obj Is DBNull.Value

>>> In diesem Zusammenhang noch eine Frage:
>>> Was ist besser: Dim i as Integer oder Dim i as System.Int32 ?
>>> Wo ist der Unterschied?
>>
>> Schau dir mal die Auflösung im Reflector an.
>
> Sorry, ich betrachte die Programmierung aus Sicht der
> Anwendungsprogrammierung - was zeigt mir denn der Reflector und wie
> hilft mir das weiter?

Wenn du selbst programmierst, kannst du ja mal die Definition anschauen.

Peter

>
> Wenn du schon so ausdrücklich danach fragst:
> Im bereits genannten Link
> [..]
> sind da die Varianten 1...3 'akzeptabel', Variante 4 dagegen nicht...

The best example here is the conversion from Integer to Long or Long to
Integer. This compiles directly down to a conv.i8 or conv.i4.ovf
instruction, respectively. You really, really, really don't want to be
calling functions to do this kind of conversion ...

Ich habe eine positive Long Zahl, die in Integer zwar garantiert rein passt,
aber eine negative Integer ergeben kann. An der Konvertierung bin ich fast
gescheitert. Wie geht das "richtig"?
Es handelt sich um einen Farbcode, nicht um Mathematik...

Lutz

> Ich habe eine positive Long Zahl, die in Integer zwar garantiert rein
> passt,
> aber eine negative Integer ergeben kann. An der Konvertierung bin ich fast
> gescheitert. Wie geht das "richtig"?
> Es handelt sich um einen Farbcode, nicht um Mathematik...

Hallo Lutz,
wo siehst Du ein Problem? Beachte die Literale hinter den Hex-Werten:
&H80000000L <> &H80000000. Letzterer Wert wird nämlich als Int32
interpretiert und das ergibt dann ca. !-2.147.483.648!

\\\
Dim i As Integer
Dim l As Long = &HFFFFFFFFL ' < Hier
Console.WriteLine(l)

If (l And &H80000000L) = &H80000000L Then ' < Hier
i = CInt(l And &H7FFFFFFF) Or &H80000000
Else
i = CInt(l)
End If
Console.WriteLine(i)

If i < 0 Then
l = i And &H7FFFFFFF Or &H80000000L ' < Hier
Else
l = i
End If
Console.WriteLine(l)
///