Gå til innhold

Anbefalte innlegg

Heisan folkens

Har et spørsmål om generiske klasser

 

Jeg har en datamodell med filer som alle sammen har en STRING(36) som heter GUID. Dette er felles for samtlige filer

 

I tillegg har jeg i DataSource lagt inn metoder som heter GetDataByGUID og FillByGUID der begge mottar en STRING

 

Greia er at et TableAdapter returnerer et datasett og ikke en DataRow. Jeg vil forenkle litt slik at jeg vil lage en funksjon som returnerer kunn aktuell datarow. Dette kan jeg selvfølgelig gjøre alle klassene mine, men så tenker jeg - hvorfor ikke putte dette rett i en FileManager klasse og ser for meg en generisk klasse av ett eller annet slag. F.eks. noe slik:

 

class FileManager<TableAdapter, DataSet, DataRow>
{
 TableAdapter TA;
 DataSet DS;

 public FileManager(TableAdapter pTA, DataSet DS)
 {
TA = pTA;
DS = DS;
 }
 public DataRow GetDatarow(String pGUID)
 {
// Hva skal ligge her tro?
 }
}

Jeg får ikke helt puttet inn noe på den plassen fordi Intellisencen ikke klarer analysere datatypen som kommer oger, og det er jo forståelig.

 

Noen som vet noe om hvordan dette kan gjøres?

Lenke til kommentar
Videoannonse
Annonse
1. bruk string og ikke String ;)

1. Hvorfor?

2. Hadde dette med saken å gjøre da?

 

;-)

1. Av samme grunn som du bruker int og ikke System.Int32.

2. Sikkert ingenting...

 

Men for å svare på spørsmålet ditt:

 

Du kan legge til constraints på de generiske typene dine, feks at de må arve fra TableAdapter og DataRow osv. Se http://msdn.microsoft.com/en-us/library/d5x73970(VS.80).aspx

Takker for svar. Dette var det jeg var på jakt etter.

 

Men bare for å ha det helt klart:

Er det annbefalt å bruke int og ikke System.Int32? Og i så fall - hvorfor? Og gjelder det i såfall alle disse datatypene?

 

Hvis det er annbefalt å ikke bruke "klassene", hvorfor finnes de da?

Lenke til kommentar
Det der visste jeg ikke om :O det øker nytten til generics betydelig!

Ganske kjekt ja, særlig at du kan lage skranke for value-type/reference-type. Men syntaksen er akkurat så lite intuitiv at jeg må slå det opp hver gang, noe som er litt dumt.

Lenke til kommentar
Er det annbefalt å bruke int og ikke System.Int32? Og i så fall - hvorfor? Og gjelder det i såfall alle disse datatypene?

Det er ikke anbefalt, du SKAL sier vi ;) C#-spec'en er dog litt mer slepphendt og sier bare at det er foretrukket:

Each of the predefined types is shorthand for a system-provided type. For example, the keyword int refers

to the struct System.Int32. As a matter of style, use of the keyword is favored over use of the complete

system type name.

Hvis det er annbefalt å ikke bruke "klassene", hvorfor finnes de da?

System.String og System.Int32 osv er .NET-rammeverkets implementasjoner. .NET er mer enn bare C#. Derfor finnes de.

Lenke til kommentar

public struct Vertex3<T> where T : struct
{
 T m_x;
 T m_y;
 T m_z;
 (...)
 public Vertex3<T> Normalize()
 {
double cross = Math.Sqrt((double)(m_x * m_x + m_y * m_y + m_z * m_z));
return new Vertex3<T>((T)m_x / cross, (T)m_y / cross, (T)m_z / cross);
 }
}

 

:D hurra! jeg trodde slikt bare var mulig i C++ med templates jeg :p

Lenke til kommentar
Jeg føler dette ligger litt over meg for øyeblikket :p

 

Kan også ha noe med at jeg har liten bruk for avanserte datatyper i jobben min for tiden.

 

HDSoftware: goto eksisterer også, men det betyr ikke at du skal bruke den :p

HÆ?!?!?! Ikke bruke Goto?? Nå fåru gi deg hehe

 

Minner meg forresten om ett av mine første programmer jeg lagde, dengang på en Oric-1. Skulle konvertere fra tall til binære tall og gjorde noe slik...:

data "00000001", "00000010", "00000011", "00000100", "00000101", "00000110", "00000111", etc...
dim Bin$(255)
for a = 1 to 255
 Bin$(a) = read
next

lbl:
 input("Tallet er:",Tall)
 print("Det binære til ";tall;" er ";Bin$(Tall)
 goto lbl

hehe, jada, ikke så veldig bra ;-) Men etter hvert lagde jeg selvsagt en logisk versjon som regnet ut. Det som var litt kult var jo at det første programmet gjorde jobben 10 ganger så kjappt i en effektiv loop som konverterte data. Ikke uforventet så klart, men det forteller noe om at det logiske ikke bestandig er det beste.

 

Noen ganger måtte vi faktisk gjøre dette. Er jo en av CBM64 generasjonen og det hendte ofte vi skulle imponere med kule animasjoner. Det blei nesten helt umulig å få til med de innebyggede rutinene for sinus og cosinus. Derfor loopet vi gjennom 360 grader og lagde en tabell med verdiene. Plutselig animerte vi grisekjappt.

 

uhm, litt på villspor nå kansje?? hehe

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...