C# et bedre språk enn Java?

[GeirGrusom]

Denne muligheten har du Java også. Se på Java Native Interface (JNI).

9563521[/snapback]

Pussig hvordan de tingene som blir trukket frem som "mangler" i java faktisk er støttet i språket likevel

9566384[/snapback]

 

Hehe

 

JOGL er et wrapper bibliotek, og er skrevet i C++

Hvorfor er det skrevet i C++ hvis:

1. Java er kjappere en C++ (som jeg har sett så utrolig mange artikler om)

2. Java kan kommunisere med Native code på en effektiv måte?

 

Å la implementasjonen være skrevet i Java ville jo vært det beste...

 

Angående enums, er det bare jeg som synes dette er en teit løsning?

 

Det gjør jo egentlig enums helt overflødig, siden du kan gjøre akkurat det der med en klasse i C# eller C++, og da også Java, uten å bruk enums, fordi enums har en annen funksjon i alle andre språk.

 

public class MyEnum
{
 private uint m_value;
 public const uint West = 0x01;
 public const uint North = 0x02;
 public const uint East = 0x04;
 public const uint South = 0x08;

 public static implicit operator uint(MyEnum src)
 {
   return src.m_value;
 }

 public bool IsNorth { get { return (m_value & North) == North; } }
 public bool IsWest { get { return (m_value & North) == North; } }
 public bool IsEast { get { return (m_value & North) == North; } }
 public bool IsSouth { get { return (m_value & North) == North; } }
}

 

Selvsagt lager dette en latterlig stor klasse, framfor det en enum ville gjort, enum er mer effektiv i funksjon.

 

Sånn det ble gjort i Java ville jeg kalt en hack.

Endret 25. september 2007 av GeirGrusom

[Dj_Offset]

JOGL er et wrapper bibliotek, og er skrevet i C++

Hvorfor er det skrevet i C++ hvis:

1. Java er kjappere en C++ (som jeg har sett så utrolig mange artikler om)

 

Java er ikke kjappere enn C++, selv om i teorien kunne det ha vært tilfelle en del ganger.

Microsoft sier også at CLI infrastrukturen dems er raskere enn native (akkurat samme tøv igjen).

 

2. Java kan kommunisere med Native code på en effektiv måte?

 

Jepp, gjennom JNI.

 

Å la implementasjonen være skrevet i Java ville jo vært det beste...

 

Tja, du foretrekker kanskje MesaGL fremfor hardware assisted OpenGL også da?

Java kan ikke gjøre interaksjon med hardware uten å bruke et native-kode. Det samme gjelder Microsofts CLI.

 

Angående enums, er det bare jeg som synes dette er en teit løsning?

 

Det gjør jo egentlig enums helt overflødig, siden du kan gjøre akkurat det der med en klasse i C# eller C++, og da også Java, uten å bruk enums, fordi enums har en annen funksjon i alle andre språk.

 

En enum er til for å være en håndterlig enhet som er lett å spesifisere og bruke.

Strengt talt er de ikke nødvendige, siden man like gjerne kan ha en rekke med konstanter.

 

final static int north = 1;
final static int south = 2;
final static int east   = 4;
final static int west   = 8;

void foo(int direction) { ... }

 

Men så har man kjernen av problemet. Hva hvis du sender inn "99" til foo() ?

Det er jo ikke en gyldig retning.

 

Derfor ønsker du å spesifisere at foo() tar en begrenset type fremfor 'int', og får dermed kompilatoren til å spy ut en feilmelding om du forsøker noe slikt.

 

enum Direction {
north = 1,
south = 2,
east   = 4,
west   = 8;
}

void foo(Direction dir) { ... }

 

Så kommer neste problem, som kanskje er et større problem på Java platformer hvor distribuert programmering er ganske vanlig.

 

Hva skjer når to uavhengige JavaVM kommuniserer med hverandre og de har av spesielle årsaker ulik definisjon av "enum Direction" ?

Da sitter du med samme problem igjen. Ved å gjøre enum til en klasse vil det være typesikkert å serialisere den over nettverk for kommunikasjon mot andre JVMs.

 

Både C og C++ har store svakheter med enums. Jeg vil påstå at enums er NO-GO i public APIer i C/C++. Mulig det vil være lurt i C# også, vet ikke...

Endret 25. september 2007 av Dj_Offset

[GeirGrusom]

Tja, du foretrekker kanskje MesaGL fremfor hardware assisted OpenGL også da?

Java kan ikke gjøre interaksjon med hardware uten å bruke et native-kode. Det samme gjelder Microsofts CLI.

les signaturen min. Glorg er et grafikk OpenGL API jeg har skrevet 100% i C#.

Man kan kommunisere med OpenGL direkte gjennom OpenGL.NativeOpenGL klassen, og OpenAL gjennom OpenAL.NativeOpenAL.

 

I C# er det forskjell på Program1.EnEnum og Program2.EnEnum, det er to forskjellige typer, og må isåfall eksplicit castes for å kunne veksle verdier.

 

Oftest lager man en dll som skal fungere som et mellomledd med datatyper og slikt for å hindre dette problemet.

 

Men i C# er ikke 99 en feil verdi i en enum, fordi enum kun er en primitiv integer verdi, og vil ikke føre til at programmet kræsjer, men utfallet vil jo bli udefinert, men her skal det være opp til programmereren også å vite hva som skjer, dette er ikke Visual Basic

 

I C++ har jeg egentlig aldri sett enum blitt tatt i bruk...

[abcd423417984]

Jeg må ærlig innrømme at jeg foretrekker C# rett og slett fordi de har fikset alle irritasjonsmomentene fra Java. Jeg er selv Java-programmerer som har drevet med Java litt for lenge til at jeg bare kan bytte, selv om jeg skulle ønske jeg kunne...

[Mr.Garibaldi]

Tja, du foretrekker kanskje MesaGL fremfor hardware assisted OpenGL også da?

Java kan ikke gjøre interaksjon med hardware uten å bruke et native-kode. Det samme gjelder Microsofts CLI.

les signaturen min. Glorg er et grafikk OpenGL API jeg har skrevet 100% i C#.

Man kan kommunisere med OpenGL direkte gjennom OpenGL.NativeOpenGL klassen, og OpenAL gjennom OpenAL.NativeOpenAL.

 

9570657[/snapback]

 

Men så vidt jeg kan se fra public partial class NativeOpenGL, så lager du en wrapper som sender kallene videre inn i opengl.dll, som tar seg av native kallene...

 

Og da blir det jo ikke noe annet enn hva man kan gjøre i Java opp mot OpenGL.dll. Evt. forskjell blir da i hvor mye overhead der er i JNI og C# interop...

[GeirGrusom]

Men så vidt jeg kan se fra public partial class NativeOpenGL, så lager du en wrapper som sender kallene videre inn i opengl.dll, som tar seg av native kallene...

 

Og da blir det jo ikke noe annet enn hva man kan gjøre i Java opp mot OpenGL.dll. Evt. forskjell blir da i hvor mye overhead der er i JNI og C# interop...

9571556[/snapback]

 

hehe lest i kildekoden nå?

partial class heter den kun fordi jeg flyttet alle conster til en annen fil, sånn at Visual Studio ikke skulle hikke så fælt over en stor kodefil (intellisense ble litt treg når det var såpass mange linjer i samme fil)

 

Et problem jeg har opplevd her, er faktisk at Dll-er ikke blir lastet før ett kall blir gjort, dette førte til at jeg må kalle en OpenGL funksjon før jeg kunne bruke wglCreateContext, for ellers kræsjet programmet her :S

 

Sånn det fungerer, er at når man kaller en funksjon første gangen, laster .NET dll-en i minnet, lager en tabell over funksjonene, og deretter kopler de til programmet som kjører. Dermed vil man ikke få noen ytelsesproblemer med å kalle native funksjoner.

 

Men hvis man kan gjøre dette i Java også, hvorfor skrives da JOGL i C++?

[Dj_Offset]

Men hvis man kan gjøre dette i Java også, hvorfor skrives da JOGL i C++?

 

JOGL er ikke skrevet i C++.

 

JOGL er autogenerert JNI-plugin basert OpenGL's heade-filer ved hjelp av Gluegen, resultatet, når bygget, er en DLL-fil (for de som ikke bruker *NIX) som lastes av JVM...

 

Eneste merkbare forskjell her, er at JOGL er en ekstrakomponent, hvorav NativeOpenGL følger med CLIet fra Microsoft.

[prebenl]

Jeg tror derimot det har mye med at Java og C++ læres på de fleste skolene.

Du tror de tunge industriaktørene med 20-30 år bak seg velger Java, fordi det er det "ungdommen" lærer på skolen nå. Det er vel heller motsatt, nemlig at skolene lærer bort Java/C#/C++ fordi det er det som blir brukt i arbeidslivet.

 

I C++ har jeg egentlig aldri sett enum blitt tatt i bruk...

C++ er det språket der jeg definitivt har sett dem mest brukt..

Endret 26. september 2007 av Geofrank

[GeirGrusom]

- CGG eller Visual C++ kreves for å compile JOGL

 

- NativeOpenGL er skrevet av meg i C#

 

Jeg har derimot kun sett #define

og const int brukt i C++, og aldri enum.

Endret 28. september 2007 av GeirGrusom

[Jarmo]

En post fjernet grunnet unødvendig personhets.

Hvis dette gjentar seg så vil vedkommende få seg en ferie.

 

Moderering kommenteres ikke i denne tråden men på pm.

Endret 1. oktober 2007 av Jarmo

[siDDis]

Dette må være ein av dei versus trådane eg har lest som har vore minst lærerikt. Argumentene dykkas handler stort sett om ting som løyses på forskjellige måter i språkene og at favorittspråket som løysning blir favorisert.

 

Java og .Net er så og si 99% likt, forskjellane er mikroskopiske. Eg har utvikla i Java, Mono/.Net og brukt Visual Studio, MonoDevelop NetBeans og Eclipse som verktøy.

 

Visual Studio har klart vore det beste IDE å utvikle i igjennom årene, men per dags dato liker eg best NetBeans 6 Milestone 10 som har ypperleg støtte for JRuby/Ruby/Rails og J2ME. Eclipse er det verste møkket av IDE eg har vore borti og krever vanvittig mykje tilleggskonfigurasjon, så eg synes det ikkje er rart at folk som har brukt Eclipse hater Java.

 

Java har ein stor fordel over .Net og det er at Java fungerer på fleire plattformer. Men begge språk er typiske språk som vil kunne gjøre alt og er typisk kva eg kaller bloated. Men Java er ekstra spesiell her som har sikkert 100 bibloteker med lik funksjonalitet og då er det ikkje rart at Java applikasjoner sluker heilt vanvittig mykje minne.

 

Eg velger språk/utviklingsmiljø etter oppdraget eg får og bruker ikkje eit språk/utviklings for å løyse alle oppgåver.

[GeirGrusom]

C# synes jeg har mange unødvendig funksjoner, og det ble litt ekstra tullball når C# 2.0 kom med generics, og alle Windows Forms klassene bruker egen skrevne collections, istedet for System.Collections.ComponentModel.Collection<>

 

Da blir det noenganger rot hvis man skal f.eks. gjøre en collection om til en array. List<> har en ToArray funksjon.

 

using er eksempel på bloated funksjoner i .NET, det eneste den gjør, er å kalle Dispose når objektet faller ut av using scopet.

 

yield return har jeg heller ikke sett den helt store nytten med (dette er for å returnere en verdi i en iteration)

Endret 4. oktober 2007 av GeirGrusom

[niggerguy]

Skal holde meg unna Java jeg.

[DeadManWalking]

Java tror jeg er valgt pga brukervennligheten mot nye brukere. Foreleseren min i videregående programmering liker ikke java i det hele tatt. Hun ser ut som om hun har peiling, så jeg stoler på det.

[pgdx]

Skal holde meg unna Java jeg.

Gjør det. Ikke post i forumet her, heller, da. Du har nettopp vekket flammehelvetet som har sovet siden oktober 2007.

 

Java tror jeg er valgt pga brukervennligheten mot nye brukere.

Det tror du vel.

 

Foreleseren min i videregående programmering liker ikke java i det hele tatt. Hun ser ut som om hun har peiling, så jeg stoler på det.

Det er viktig å ikke legge sin lit til folk bare fordi de er fra universitetet.

[Patton]

Foreleseren min i videregående programmering liker ikke java i det hele tatt. Hun ser ut som om hun har peiling, så jeg stoler på det.

Det er viktig å ikke legge sin lit til folk bare fordi de er fra universitetet.

Spesielt på universitetet er det veldig viktig å lære seg å være kritisk til alt en hører og leser. Utforsk hvorfor Anya ikke liker java, og sammenlign dette med andre kilder (både pro og kontra). Bygg først din egen mening når du har greidd å validere en del av påstandene. Verden er ikke så svart/hvitt som en gjerne ønsker, java har sine fordeler og ulemper som alle språk.

Endret 9. august 2009 av Patton

[GeirGrusom]

Har ikke så lyst til å restarte en flametråd her igjen, men til niggerguy:

Java er et essensielt språk i bransjen. Det er et av de mest utbredte, og også dermed et av de mest nyttige språkene. fordelen det har, er at det er plattformuavhengig, og i mange tilfeller vil det utbalanserer glatt ulempene med selve språket.

Java kan gi deg langt flere jobbtilbud også.

Det at jeg synes java er litt tåkete laget på mange punkter betyr ikke at språket er ubrukelig.