Gå til innhold

Anbefalte innlegg

Hei,

 

Jeg vil stjele en idè fra PHP forumet om gjenbrukbar kode, og begynner med en klasse jeg lagde for å holde orden på config uten og bruke registeret(bruker XML dokumenter)

 

slik blir koden brukt:

Dim config as new clsConf("config.xml") 'hvis filen ikke finnes blir den lagd'
Dim Brukernavn as string = config.item("brukernavn", "default") 'legg til standard brukernavn ell.'
config.save() 'lagre den eventuelt nye filen'
config.item("brukernavn") = "Richard87" 'endre ett ellement'
config.save() 'lagre endringene'

 

 

 

Public Class clsConf
   Private mCur As Xml.XmlNode
   Private xmldoc As New Xml.XmlDocument
   Private Filename As String

   Public Sub New(ByRef strFilename As String)
       If System.IO.File.Exists(strFilename) Then
           xmldoc.Load(strFilename)
       Else
           Dim strXML As String = "<?xml version=""1.0"" encoding=""utf-8"" ?><head></head>"

           xmldoc.LoadXml(strXML)
       End If
       mCur = xmldoc.SelectSingleNode("/head")
       Filename = strFilename

   End Sub

   Public Function Save() As Boolean
       Try
           xmldoc.Save(Filename)
       Catch ex As Exception
           Return False
       End Try

       Return True
   End Function


   Private Function GetItem(ByRef strName As String) As String
       For Each mNode As Xml.XmlNode In mCur.ChildNodes
           If mNode.Name = strName Then
               Return mNode.InnerText
               Exit For
           End If
       Next
       Return ""
   End Function


   Private Sub SetItem(ByRef strName As String, ByRef strValue As String)
       Dim bSet As Boolean = False
       For Each mNode As Xml.XmlNode In mCur.ChildNodes
           If mNode.Name = strName Then
               mNode.InnerText = strValue
               bSet = True
               Exit For
           End If
       Next

       If Not bSet Then
           Try
               Dim mnode As Xml.XmlNode
               mnode = xmldoc.CreateElement(strName)
               mnode.InnerText = strValue
               mCur.AppendChild(mnode)
           Catch ex As Exception
               MsgBox("Feil i programmet" & vbNewLine & "Kunne ikke legge til node!", MsgBoxStyle.Critical, "Feil")
           End Try

       End If
   End Sub

   Public Property Item(ByVal setting As String, Optional ByVal def As String = "") As String
       Get
           Try
               Dim str As String = GetItem(setting)
               If str = "" Then
                   str = def
                   SetItem(setting, def)
               End If
               Return str
           Catch ex As Exception
               SetItem(setting, def)
               Return def
           End Try
       End Get
       Set(ByVal value As String)
           SetItem(setting, value)
       End Set
   End Property
End Class

 

 

Endret av Richard87
Lenke til kommentar
Videoannonse
Annonse

public string Name { get { return name; } set { name = value; } }

Public Property Name As String
 Get
   Return Me._name
 End Get
 Set(ByVal value As String)
   Me._name = value
 End Set
End Property

 

VB krever at du skriver mye mer for å gjøre akkurat det samme. Det støtter også færee features, for eksempel kan lambdauttrykk i VB kun være på én linje.

Lenke til kommentar

Med .Net 4.0 er vel mye av de tekniske forskjellene mellom VB og C# visket ut.

 

VB 10.0 har fått multiline lambda, collection initializers og auto-implemented properties fra C#. C# 4.0 har fått støtte for dynamiske typer og optional argumenter fra VB.

 

VB mangler yield return og multiline kommentarer, det er det eneste jeg kommer på i farten. dvs f.eks denne har ikke noe ekvivalent i VB, der må vi fremdeles arve IEnumerable og instansiere selv:

public IEnumerable<int> Count(int max) {
   for( i = 0; i < max; i++ )
       yield return i;
}

 

Edit:

Og properties i VB støtter heller ikke ulik synlighet på get og set, f.eks er det vanlig å bruker private/protected for set for å gjøre den readonly i C#, det er ikke mulig i VB, da må man gjøre det på gamle måten (skikkelig pain med NHibernate når man ikke kan ha protected set på id-felter):

//denne:
public string Name { get; set; }

// er ekvivalent med denne i VB 10.0 (man implementerer ingen get/set lenger)
Public Property Name As String

//men denne har ingen ekvivalent i VB:
public string Name { get; protected set; }

Endret av MailMan13
Lenke til kommentar

VB har ikke hatt støtte for dynamiske datatyper. VB har hatt støtte for å konvertere alt til object, som også C# har hatt. Dynamiske datatyper er ikke bare nytt i språkene, det er nytt i .NET 4.0 og kalles Dynamic Language Runtime. Det er bygget for å støtte språk som Iron Python bedre. C# og VB får støtte for dynamiske datatyper for å kunne kommunisere med språk som bruker DLR.

 

Pekeraritmetikk er heller ikke støttet i VB. Denne kan brukes til for eksempel å generere et Bitmamp med data på en rask og effektiv måte, for eksempel for å generere et mandelbrot bilde. VB har også et forferdelig system der den som standard automatisk konverterer datatyper som fører til at mye kode blir tvetydig eller at en rett og slett ikke kan vite resultatet uten å kjøre koden.

Eksempelvis: verdi = "1" + 2

Blir s = 3 eller "12"? I C# er dette ulovlig uten å presisere hva man mener. En kan heller ikke blande tekst og tall som i VB. Skal du bruke tekst som et tall, må du parse det først. Automatisk konvertering fører til langt flere runtime feil eller uventet oppførsel.

 

Mest hater jeg datatypekonvertering i Visual Basic, det er skikkelig dumt lagt opp.

 

I C# kan du ikke utføre en implisitt konvertering som fører til tap av data (double til single, float til int, eller tekst til tall) uten å gjøre en eksplisitt cast. Du har også operator as for å konvertere objekter, som returnerer null dersom objektet ikke kan castes.

 

Det som er verst med VB er selve språket. Koden er uoversiktelig, ved siden av å også være utrolig stygt. Jeg jobbet med Visual Basic i mange mange år, og en ting jeg merket, var at ved store programmer, blir koden lett uoversiktelig, fordi det tar lenger tid å lese VB kode enn C#. Et utmerket eksempel her er Properties som er utrolig verbost i Visual Basic. Funksjoner er heller ikke noe bedre. ByVal blir dyttet inn foran alle argumenter, fordi VB6 brukte ByRef som standard. I C# er det byval som standard, med mindre du legger inn out eller ref foran.

 

Variabeldeklerasjon:

int myinteger = 20

Dim myinteger As Integer = 20

Lambdauttrykk:

OpFunc func = (a, b) => a + b;

Dim func As OpFunc = Function(a, b) a + b

For løkker

for(int i = 0; i < 20; i+=5)
 sum += i;

For i As Integer = 0 to 19 Step 5
 sum += i
End For

Funksjoner:

public int Add(int a, int b)
{
 return a, b;
}

Public Function Add(ByVal a As Integer, ByVal b As Integer) As Integer
 Return a + b
End Function

Lenke til kommentar

Med option explicit, option strict og kompilere med implicit conversion til "Error" blir det akkurat like typesikkert som C#. Selvfølgelig, kommer man inn i en eksisterende kodebase der det ikke er gjort riktig fra starten av har man et problem, og VB miljøet er ikke akkurat dem som har vært mest nazi på sånt.

 

Properties i VB er ikke verbost lenger, det er èn linje, omtrent like lang som den ville vært i C#.

 

VB har hatt dynamisk binding gjennom Object klassen som til en viss grad har fungert som den gamle Variant-typen (for lettere COM-interop vil jeg anta). F.eks denne vil ikke gi noe error compile-time, men resolve typen og medlemmet "DoStuff" runtime med en feil om det ikke går. Tilsvarende i C# uten den nye "dynamic"-typen går ikke, da må man bruke reflection (InvokeMember("DoStuff", ...).

dim o as Object = new 'et eller annet'
o.DoStuff()

Endret av MailMan13
Lenke til kommentar

Tja, det har du jo rett i. Men fortsatt er dette noe en IKKE skal gjøre, det er en stor del av poenget med interfaces. Det er noe som henger igjen fra VB6 hvor en ikke kunne definere egne interfaces.

 

Det er latskap å kalle funksjoner på den måten. I dynamiske objekter kan du legge inn nye felter, funksjoner osv. run-time, det kan du derimot ikke gjøre i Visual Basic 9.0.

I C# for eksempel:

dynamic obj = new ExpandoObject();
obj.Navn = "123";
obj.Funksjon = (a, b) => a + b;
obj.Resultat = obj.Funksjon(1, 2);

Så dynamisk støtte er ikke noe C# har hentet fra Visual Basic, ettersom Visual Basic ikke har hatt støtte for dette før i 10.0 som er samtidig med at C# 4.0 får støtte for det samme igjennom DLR.

Lenke til kommentar
  • 2 uker senere...

Synes C# er et mye bedere valg for .NET enn VB.

Eller for med som er en python fyr ironpython

VB.NET er nok helt annent språk enn vb-6,henger noe igjen at jeg har likt vb-6 veldig dårlig.

 

GeirGrusom ha tatt noen svakheter som fortsatt er i VB,men ser VB har skjerpet seg en del.

Mener nå at C# kunne tatt over for VB,men valg kan jo alltid være bra ;)

 

Bare for gøy tar jeg med python i sammenligningen til GeirGrusom.

Variabeldeklerasjon:
--------------------
C#
int myinteger = 20

#VB
Dim myinteger As Integer = 20

#python
Trenger ingen Variabeldeklerasjon



Lambdauttrykk:
--------------
C#
OpFunc func = (a, b) => a + b;

#VB
Dim func As OpFunc = Function(a, b) a + b

#python
lambda a, b: a + b



For løkker:
---------
C#
for(int i = 0; i < 20; i+=5)
 sum += i;

#VB
For i As Integer = 0 to 19 Step 5
 sum += i
End For

#python
sum([x for x in range(0,20,5)])

#Alternativ.
my_list = []
for i in range(0,20,5):
   my_list.append(i)
sum(my_list)



Funksjoner:
----------
C#
public int Add(int a, int b)
{
 return a, b;
}

#VB
Public Function Add(ByVal a As Integer, ByVal b As Integer) As Integer
 Return a + b
End Function

#python
def add(a, b):
   return a, b

 

 

>>> #Python trenger heller ikke pakke koden inn i klasse for og kjøre
>>> (lambda a, b: a + b)(4,8)
12
>>> sum([x for x in range(0,20,5)])
30
>>> my_list = []
>>> for i in range(0,20,5):
my_list.append(i)
>>> sum(my_list)
30
>>> def add(a, b):
return a, b

>>> add(5, 9)
(5, 9)

Endret av SNIPPSAT
Lenke til kommentar

Her er det mange tekniske forklaringer på "A er bedre enn B fordi C". Og de er like uinteressante som alltid... ;)

 

 

 

Det viktigste er egentlig: Bruk det som får jobben gjort! :)

 

Jeg er ikke utdannet programmerer, men må lage mine egne verktøy fra tid til annen for det mangler en del. Da fungerer VB helt utmerket, bl.a. fordi det er enkelt å lese (iallfall for meg som ikke er programmerer, dere programmerere er muligens av en annen oppfatning men det får dere lov til). Vil du bli programmerer, skal du uansett gjennom en del språk, og da kan det være like greit å ha en basiskunnskaper i VB også. Til syvende og sist er det logikken din som er det viktige, ikke hvilket språk den er skrevet i. :)

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å
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...