Ich benutze neuerdings C# und habe mir dort eigene Datentypen definiert,
quasi wie in meinen embedded Projekten (16bit µC).
1
using SINT8 = System.SByte; // char
2
using UINT8 = System.Byte; // unsigned char
3
using SINT16 = System.Int16; // int
4
using UINT16 = System.UInt16; // unsigned int
5
using SINT32 = System.Int32; // long
6
using UINT32 = System.UInt32; // unsigned long
7
using FLOAT32 = System.Single; // float
In ANSI C binde ich überall den Header mit den typedefs ein und fertig.
Jetzt suche in C# auch eine Möglichkeit, dies so zu handhaben. Bis jetzt
muss in jede Datei die oben aufgeführte Typendefinition reinkopiert
werden.
Versuche eine DLL zu erstellen und diese per using einzubinden, schlugen
fehl.
Gibt es eine Methode, ähnlich ANSI C, die Typendefinitionen als eine Art
Header einzubinden?
Sowas ist in C# nicht möglich. Header gibts auch keine( zum Glück).
Nutze doch einfach die normalen Bezeichnungen, so wie es auch gedacht
ist. Solche Großschreibungen sind in C# sowieso nicht erwünscht.
Warum der Typedef? Macht doch vllt im Zusammenhang mit Structs Sinn,
sonst ist das für mich eigentlich nur Kosmetik. C# ist Objektorientiert,
also kann man es ja ganz weglassen oder nicht?
Welches Ziel verfolgst du denn?
Auszug zum Typedef in der Wiki "C# also contains a feature which is
similar to the typedef of C; however, it must be redeclared for each
separate file"
Hans schrieb:> Ich benutze neuerdings C# und habe mir dort eigene Datentypen definiert,> quasi wie in meinen embedded Projekten (16bit µC).>>
1
> using SINT8 = System.SByte; // char
2
> using UINT8 = System.Byte; // unsigned char
3
> using SINT16 = System.Int16; // int
4
> using UINT16 = System.UInt16; // unsigned int
5
> using SINT32 = System.Int32; // long
6
> using UINT32 = System.UInt32; // unsigned long
7
> using FLOAT32 = System.Single; // float
8
>
[...]
> Gibt es eine Methode, ähnlich ANSI C, die Typendefinitionen als eine Art> Header einzubinden?
Nein.
Das würde auch keinen Sinn ergeben.
C# ist nicht C. In C kann z.B. "int" 16, 32, 64, was-auch-immer Bits
groß sein.
In C# nicht, die Datentypen sind strikt festgelegt - schau mal auf die
Namen, was glaubst Du meint das "16" oder "32" im Namen eigentlich? Es
gibt also keinen Bedarf sowas zu tun, und entsprechend sollte man es
auch nicht tun.
Nebenbei bemerkt, die "geboxten" statt der nativen Typen zu benutzen ist
nicht direkt clever wenn nicht aus irgendeinem konkreten Grund
notwendig. Overhead, unerwünschte Effekte und so Scheiss...
Jasch schrieb:> Nebenbei bemerkt, die "geboxten" statt der nativen Typen zu benutzen ist> nicht direkt clever wenn nicht aus irgendeinem konkreten Grund> notwendig. Overhead, unerwünschte Effekte und so Scheiss...
Zur Laufzeit dann doch egal, es wird doch immer die Objektvariante in c#
angewandt, oder nicht?
D. I. schrieb:> Jasch schrieb:>> Nebenbei bemerkt, die "geboxten" statt der nativen Typen zu benutzen ist>> nicht direkt clever wenn nicht aus irgendeinem konkreten Grund>> notwendig. Overhead, unerwünschte Effekte und so Scheiss...>> Zur Laufzeit dann doch egal, es wird doch immer die Objektvariante in c#> angewandt, oder nicht?
Nein, soweit ich weiss nicht.
void Foo(int bar) {
if (bar == null {
...
}
}
ergibt einen Compilerfehler,
void Foo(Int32 bar) {
if (bar == null {
...
}
}
dagegen tut wie gedacht. Nativ (ein nackter 32-Bit-Integer) vs. "Boxed"
(ein von Object abgeleitetes Dingens) eben. Das kann (wegen der
"Nullbarkeit") zur Laufzeit nicht dasselbe sein.
Was sinnvoll unter c# ist, ist die union. Alles andere ergibt für mich
ersteinmal keinen sinn, es aus der µC Welt mitzunhemen.
using System;
using System.Runtime.InteropServices;
[StructLayout(LayoutKind.Explicit)]
public struct SampleUnion
{
[FieldOffset(0)] public bool Flag1;
[FieldOffset(1)] public bool Flag2;
[FieldOffset(2)] public bool Flag3;
[FieldOffset(3)] public bool Flag4;
[FieldOffset(0)] public long Composite;
}
class Sample
{
public static void Main()
{
SampleUnion su = new SampleUnion();
su.Flag1 = false;
Console.WriteLine(su.Composite.ToString());
su.Flag2 = true;
Console.WriteLine(su.Composite.ToString());
su.Flag3 = false;
Console.WriteLine(su.Composite.ToString());
su.Flag4 = true;
Console.WriteLine(su.Composite.ToString());
}
D. I. schrieb:> Jasch schrieb:>> Nein, soweit ich weiss nicht.>>>> void Foo(int bar) {>> if (bar == null {>> ...>> }>> }>>>> ergibt einen Compilerfehler,>>>> void Foo(Int32 bar) {>> if (bar == null {>> ...>> }>> }>> Das ist zur Compilezeit. Ich meinte aber Laufzeit. Laut>> http://openbook.galileocomputing.de/visual_csharp_2010/visual_csharp_2010_02_003.htm#mj2f5f2bae63590a7d163f13a30afb3b43>> werden auch die "nackten" Datentypen später als Objekte behandelt.
Keine Ahnung was Galileocomputing ist, aber was da geschrieben steht ist
Bullshit. Naja, vielleicht auch nicht ganz, merke: "behandelt" !=
"sind", aber das wäre jedenfalls Compilezeit.
Die behaupten "Int32" und "int" wären Aliase, was sowieso schon keinen
Sinn ergibt weil niemand, der noch bei Verstand und nicht total
zugekifft ist, ohne guten Grund zwei Namen für ein und dasselbe Ding
vergibt. Der Compiler macht ein paar Tricks um die ähnlich aussehen zu
lassen, das ist es aber auch schon.
Und aus der Tatsache dass man einem Int32 "null" zuweisen kann, aber
einem "int" nicht, folgt mehr oder weniger zwingend (bekloppte
Sprachdesigner kann man recht sicher ausschliessen...) dass die *zur
Laufzeit* auch verschieden repräsentiert sein müssen, immerhin sind ja
die Wertebereiche sonst gleich und lassen kein "Null-Bit" oder sowas
frei.
Für die fiesen Details siehe die Doku/die Standards zu C# und CLR.
Sorry, irgendwelche, gar in Deutsch verfassten, Dokumente sind selten
hilfreich. Hehehe, ich kann mich noch an Horror-Begriffe wie "mehrfädige
Programmierung" - das kann sogar MS selbst verbrochen haben - erinnern.
Da kommt Brechreiz hoch, hoffentlich sind die gottverdammten
Verantwortlichen inzwischen sehr, sehr qualvoll verreckt... :-(
@Jasch (der Gast)
Aha, das klingt ja spannend. Wie initialisierst du den einen
int-Wertetyp ohne Operator mit einer Null Referenz? Würde mich mal
interessieren, da deine Snippes (trotzt Korrektur), ob int oder Int32
ein Warning ausgeben und beim Aufruf der Methode eine Execption
geschmissen wird(!)
Jasch schrieb:> Und aus der Tatsache dass man einem Int32 "null" zuweisen kann, aber> einem "int" nicht, folgt mehr oder weniger zwingend
Zeig mir doch mal wie Du einem Int32 null zuweist...
Jasch schrieb:> Die behaupten "Int32" und "int" wären Aliase, was sowieso schon keinen> Sinn ergibt weil niemand, der noch bei Verstand und nicht total> zugekifft ist, ohne guten Grund zwei Namen für ein und dasselbe Ding> vergibt. Der Compiler macht ein paar Tricks um die ähnlich aussehen zu> lassen, das ist es aber auch schon.
int ist die Kurzform für Int32, weil dieses der mit Abstand am meisten
genutzte Integer-Datentyp ist. Hinter beiden verbirgt sich EXAKT
dasselbe.
Sharping schrieb:> Jasch schrieb:>> Die behaupten "Int32" und "int" wären Aliase, was sowieso schon keinen>> Sinn ergibt weil niemand, der noch bei Verstand und nicht total>> zugekifft ist, ohne guten Grund zwei Namen für ein und dasselbe Ding>> vergibt. Der Compiler macht ein paar Tricks um die ähnlich aussehen zu>> lassen, das ist es aber auch schon.>> int ist die Kurzform für Int32, weil dieses der mit Abstand am meisten> genutzte Integer-Datentyp ist. Hinter beiden verbirgt sich EXAKT> dasselbe.
So ist es und nicht anders.
1
Int32Test1=null;
1
NULL kann nicht in "int" konvertiert werden, da dieser Werttyp nicht auf NULL festgelegt werden kann.
Aber folgendes funktioniert. Hat aber nix mit dem Thema hier zu tun.
__tom schrieb:> Jasch schrieb:>> Und aus der Tatsache dass man einem Int32 "null" zuweisen kann, aber>> einem "int" nicht, folgt mehr oder weniger zwingend>> Zeig mir doch mal wie Du einem Int32 null zuweist...
OK, OK, da habe ich etwas zwischen .NET und Java durcheinandergebracht.
Scheiss Programmiersprachen allesamt, jeder sollte nur noch Brainf*ck
(das '*' steht für ein 'u', die Forumsoftware ist da irgendwie komisch,
keine Ahnung wie irgendwer irgendwas finden soll wenn man es nicht
korrekt schreiben darf? Oder wieso englische 4-Letter-Words in einem
deutschen Forum relevant sein sollten? Sollte nicht eher "Scheiss"
gefiltert werden?) benutzen. Oder Postscript. ;-)
Vermutlich sollte ich auch nicht so früh am Morgen in der Gegend
herumposten.
Hmm, Java ist also an der Stelle konsistenter als C#... Scheisse, wer
hätt's gedacht...
