VisualBasic naar Delphi converteren

[Verwijderd]

ik heb een programma gemaakt in Visual basic een hele tijd geleden en heb geen zin om dit opnieuw te schrijven naar delphi.

is er een mogelijkhijd om dit te converteren?

alvast bedankt

[Mithrandir]

Kun je 't prog niet aanroepen vanuit delphi??

[Verwijderd]

Ben bang van niet jongen..

[Verwijderd]

dat wel ja maar de source wil ik omzetten naar delphi om het vervolgens aan te passen

[Verwijderd]

Converters voor programmeertalen T zou mooi zijn...

[jelmervos]

Op donderdag 27 december 2001 21:44 schreef dev het volgende:
Converters voor programmeertalen T zou mooi zijn...

Idd, van PHP naar ASP en van VB naar Delphi

Van Delphi naar C++, kan dat dan ook?

[Verwijderd]

http://babel.altavista.com/

Invoer engels:
The quick brown fox jumped over the lazy dog.

Vertaald naar frans:
Le renard brun rapide a sauté par-dessus paresseux le chien

van frans naar duits:
Der schnelle braune Fuchs ist über Faultier den Hund gesprungen

van duits weer naar engels:
The fast brown fox branched over putrid animal the dog

Moraal van dit verhaal, het automatish vertalen van taal naar taal werkt van geen meter, en met programeer talen werkt het psies het zelfde

[Verwijderd]

hmm vaag, iemand op school had daar ooit een proggie voor.

mjah laat maar dan zet ik hem zelf wel over

[marcusk]

Op donderdag 27 december 2001 22:00 schreef Yarvieh het volgende:
Invoer engels:
The quick brown fox jumped over the lazy dog.
...
van duits weer naar engels:
The fast brown fox branched over putrid animal the dog

LOL

Moraal van dit verhaal, het automatish vertalen van taal naar taal werkt van geen meter, en met programeer talen werkt het psies het zelfde

maar progtalen zijn voor computers 'iets' makkelijker te begrijpen dan natuurlijke talen . Van Object Pascal -> C++ moet op zich wel goed mogelijk zijn, alleen de API is een probleem lijkt mij.

[packman]

Op donderdag 27 december 2001 21:44 schreef dev het volgende:
Converters voor programmeertalen T zou mooi zijn...

Ik ben op't werk toch bezig aan een progje om van java code C (geen C++) code te laten genereren - en 'twerkt al bijna helemaal

[mbravenboer]

Ah transformaties .

Programmeertalen transformeren naar andere talen is geen enkel probleem. Ze zijn immers een stuk minder ambigu dan 'natuurlijke' taal. Compileren is in principe zelfs transformeren. Zeker low-level talen als C zijn een aantrekkelijk doel: je kunt bijna elke taal ernaar vertalen.

Wat inderdaad wel een probleem is: de libs...

[packman]

Op donderdag 27 december 2001 22:47 schreef mbravenboer het volgende:
Ah transformaties .

Programmeertalen transformeren naar andere talen is geen enkel probleem. Ze zijn immers een stuk minder ambigu dan 'natuurlijke' taal. Compileren is in principe zelfs transformeren. Zeker low-level talen als C zijn een aantrekkelijk doel: je kunt bijna elke taal ernaar vertalen.

Wat inderdaad wel een probleem is: de libs...

java decompilen is niet moeilijk hoor

Je zit wel met van die rotproblemen zoals 64bit int (java long type) op een motorola 68*** proc (performant) werkende te krijgen, en een garbage collector is ook nie echt simpel...

[mbravenboer]

packman: Ik ben op't werk toch bezig aan een progje om van java code C (geen C++) code te laten genereren - en 'twerkt al bijna helemaal

Klinkt interessant

1. Waarin is de transformatie geschreven?
2. Hoe ga je met interface, virtuele methoden en dergelijke om?
3. Doe je nog wat met dynamic-class loading en reflectie?
4. Hoe pak je de primitieven en lib gebruik aan?
5. AWT? IO?
6. Hoe is de performance?

[mbravenboer]

packman: java decompilen is niet moeilijk hoor

Ach, de source is ook beschikbaar .

Je zit wel met van die rotproblemen zoals 64bit int (java long type) op een motorola 68*** proc (performant) werkende te krijgen, en een garbage collector is ook nie echt simpel...

Idd, zie m'n vorige post... Hoe vang je native code op? Dat heb je toch erg snel nodig...

[packman]

Op donderdag 27 december 2001 22:55 schreef mbravenboer het volgende:

[..]

Klinkt interessant

1. Waarin is de transformatie geschreven?
2. Hoe ga je met interface, virtuele methoden en dergelijke om?
3. Doe je nog wat met dynamic-class loading en reflectie?
4. Hoe pak je de primitieven en lib gebruik aan?
5. AWT? IO?
6. Hoe is de performance?

1. We hebben gedeeltelijk yakk gebruikt om de parsercode te genereren (100% pure java)

2. De bedoeling is om de java code te onderhouden en de C code bij elke rebuild te hergenereren. Het is de bedoeling om dit op embedded platforms te gebruiken (draait nu eigenlijk al ). Je verliest wel je flexibiliteit zoals dynamic class loading enzo, maar dat is in de embedded markt waar ik me mee bezig hou toch maar een security risk Reflectie wordt mooi inline de juiste code voor gegenereerd.

3. Zie 2.

4. Alle datatypes worden door C datatypes vervangen (geen bounds controles meer dus in runtime). Voor native kan je gewoon de method recht in C schrijven. We hebben zelf een API ontwikkeld voor de embedded dingen die wij nodig hebben - meer libs heb je niet echt nodig

5. Vermits het embedded is, is er geen awt of swing. IO werkt allemaal, zelfs java.net.* werkt

6. Performance is zaaalig snel - juist een garbage collect neemt een beetje tijd... (+-1 sec op het target platform), maar dit wordt automatisch gedaan bij elke user input in background (wat toch pure C code is - en waardoor er geen memory corruptie kan optreden) In praktijk moet er nooit echt een automatische garbage collect gedaan worden, en de memory usage heeft ons zelfs verrast (in positieve zin).

[mbravenboer]

packman: 1. We hebben gedeeltelijk yakk gebruikt om de parsercode te genereren (100% pure java)

Ik twijfel nog ff of ik daar blij van moet worden .

2. De bedoeling is om de java code te onderhouden en de C code bij elke rebuild te hergenereren. Het is de bedoeling om dit op embedded platforms te gebruiken (draait nu eigenlijk al ).

Leuk idee, een JVM schrijven voor een onbekend embedded platform zal ook niet direct erg opschieten .

Je verliest wel je flexibiliteit zoals dynamic class loading enzo, maar dat is in de embedded markt waar ik me mee bezig hou toch maar een security risk

Das waar.

Reflectie wordt mooi inline de juiste code voor gegenereerd

Cool! Maar wat voor reflectie laat je allemaal toe? Je kan toch niet dynamisch een methode laten aanroepen als die in native code wordt gecompileerd? Kan je instanties aanmaken met reflectie?

4. Alle datatypes worden door C datatypes vervangen (geen bounds controles meer dus in runtime). Voor native kan je gewoon de method recht in C schrijven. We hebben zelf een API ontwikkeld voor de embedded dingen die wij nodig hebben - meer libs heb je niet echt nodig

Nog een keer cool . Is er ergens info over dit project?

5. Vermits het embedded is, is er geen awt of swing. IO werkt allemaal, zelfs java.net.* werkt

Wauw, je bent extreem goed bezig geweest . Ik ben erg geinteresseerd in meer info/code voorbeelden, dat wordt zeker lastig gezien de commerciele aard?

In praktijk moet er nooit echt een automatische garbage collect gedaan worden, en de memory usage heeft ons zelfs verrast (in positieve zin).

Idd, sommige embedded JVMs hebben geeneens een gc, is ook niet verplicht btw om je JVM te mogen noemen.

[packman]

De convertor is supersnel als je hem gewoon eens door zichzelf hebt gedraaid

De reflectiecode heb ik niet geschreven - maar dat is door een kerel die absoluur reflectie nodig had in het project en dat helemaal werkende wou hebben. Ikzelf gebruik dat eigenlijk nooit. Voor zover ik die ken heeft die wel degelijk alles werkende gekregen op een of andere manier.

Info over het project kan ik je niet bezorgen (inderdaar commerciele zever met licenties enzo).
Ik kan wel een paar links geven met beta en alpha opensource convertors (spijtig genoeg niet nu - die liggen op het werk - en ik kom daar pas woensdag terug...) De meeste projecten zijn echter gestopt en maar gedeeltelijk bruikbaar of met vele irriterende en lastige bugs (zoals string constanten verkeerd converteren enzo - in elk ding dat we bekeken hebben zat dezelfde fout). We zijn begonnen met als basis een van die projectjes (met toestemming) - maar ondertussen schiet daar niet veel origineels meer van over...

De garbage collector is ook een mooi stukje werk - maar hier gebruiken we ook een opensource project dat we hebben moeten modifieren voor het targetplatform - en waarvoor na de cleanup van de code de diffs gaan (moeten )insturen.

Eigenlijk zijn we nu wel serieus offtopic bezig he

[The-Source]

Ik ben wel eens een progje op internet tegen gekomen die van C(++) naar Delphi source converteerde maar daar heb jij weinig. Ik meen mij te herinneren dat het progje van een nederlandse site kwam (van een Delphi/ C boeken schrijver dacht ik).

[mbravenboer]

packman: De convertor is supersnel als je hem gewoon eens door zichzelf hebt gedraaid

Hehe . Das altijd grappig .

De reflectiecode heb ik niet geschreven

Hum, ben wel benieuwd hoe die gast dat dan gedaan heeft, want veel zaken lijken mij vrij onmogelijk... maar goed, jullie hebben veel voor elkaar gekregen, dus wellicht dit ook wel .

Info over het project kan ik je niet bezorgen (inderdaar commerciele zever met licenties enzo).
Ik kan wel een paar links geven met beta en alpha opensource convertors

Ok, dat is wel leuk (als het een beetje leesbaar is ).

We zijn begonnen met als basis een van die projectjes (met toestemming) - maar ondertussen schiet daar niet veel origineels meer van over...

Ah, wat zijn jullie er uiteindelijk mee van plan? Blijft het volledig intern?

De garbage collector is ook een mooi stukje werk - maar hier gebruiken we ook een opensource project dat we hebben moeten modifieren voor het targetplatform - en waarvoor na de cleanup van de code de diffs gaan (moeten )insturen.

Hum klinkt ook cool, ik heb nog nooit een gc geschreven, maar wel wat over gelezen...

Eigenlijk zijn we nu wel serieus offtopic bezig he

Ach, boeiuh

[elnino]

Op donderdag 27 december 2001 19:43 schreef Shadow[KRoZ] het volgende:
ik heb een programma gemaakt in Visual basic een hele tijd geleden en heb geen zin om dit opnieuw te schrijven naar delphi.

is er een mogelijkhijd om dit te converteren?

alvast bedankt

Er bestaan geloof ik wel van die tools, aangezien VB en Delphi qua gebruik niet erg van elkaar verschillen, tenminste qua properties enzo. Voor simpele apps zal het wel werken.

code:

Label1.Caption = "test"

wordt omgezet in: (Ik heb niet echt veel verstand van Pascal, so correct me if I'm wrong)

code:

Label1.Caption := 'test'

Ik dacht dat Borland zelf ook een converter had gemaakt.

[mulder]

Volgens mij is er zat op google te vinden: http://www.google.com/search?q=vb2delphi&hl=fr&lr=

[Verwijderd]

Nou vraag ik me heel stiekum af waarom je de franstalige versie van google gebruikt

[packman]

Op vrijdag 28 december 2001 00:36 schreef mbravenboer het volgende:

[..]

Hehe . Das altijd grappig .

laten we zeggen dat het nu toch een factor - eeeh dunno sneller gaat... Nu ziet ge het bijna niet meer converten als ge de C versie gebruikt - duurt 2 a 3 sec's voor een (redelijk serieus) project - met de java versie is hij toch nog een 20 sec's over om datzelfde project te converten (java start time inclusief)

[..]

Hum, ben wel benieuwd hoe die gast dat dan gedaan heeft, want veel zaken lijken mij vrij onmogelijk... maar goed, jullie hebben veel voor elkaar gekregen, dus wellicht dit ook wel .
[..]

Ik denk dat er een heleboel table lookup is met adresjes enzo van functies. Alles wat geaccesst kan worden is tenslotte ter beschikking tijdens de conversion.

Ok, dat is wel leuk (als het een beetje leesbaar is ).
[..]

Ah, wat zijn jullie er uiteindelijk mee van plan? Blijft het volledig intern?
[..]

yep - da's de voorlopige planning. Er waren wel al contacten met de firma die dat platform produceerd - die waren daar sterk in geinteresseerd.

Hum klinkt ook cool, ik heb nog nooit een gc geschreven, maar wel wat over gelezen...

Ik heb het eens bekeken - en dat is niet iets dat je op een maandje ineen knutseld... zeker als het nog een beetje performant moet zijn ook. We hebben veel geluk gehad dat we die gc zijn tegengekomen - anders hadden we een (serieus) memory probleem. 1 voordeel is van heel deze zaak dat je echt wel java inside-out kent als je daar wat mee bezig bent geweest. Je moest eens weten hoeveel objectjes van 10 of minder bytes er worden gecreeerd in een stomsimpel programmatje - dat zijn er veeeeeeeel.

Het idee is eigenlijk compleet onstaan omdat er 1 platform was waarvoor we een java ter beschikking hadden en zelfs verplicht werden te gebruiken (waardoor ik nu mijn job heb ) - maar dat draaide niet echt vlot.
Dan hadden we nog een ander platform - waar geen java op draaide (en waar we al lang op ontwikkelden) - en waar we nog een andere applicatie voor moesten schrijven - die ook op het java-platform moest draaien. De baas zag 2 keer 12 manjaar niet zitten voor een C en een java versie - dus zijn we hier mee begonnen. Ik heb veel geleerd over de internals van een java toen, en parrallel heb ik het eerste projectje van onacceptabel traag tot op een zeer performant niveau gebracht. Java optimizing is niet echt simpel soms... Dingen zoals renewing in een loop - kick buiten... Zoveel mogelijk objectjes zo maken dat je ze kan herbruiken...
een heel mooie constructie hiervoor is

code:

class Test
{
   protected Test()
   {
     // EMPTY
   }
   public static Test init(Test obj, [params])
   {
     if (obj == null) obj = new Test();
     obj.setobject([params]);
     return obj;
   }
   private void setobject([params])
   {
     // initialize object
     ....
   }
}

en dan een dit gebruiken om een nieuw object te maken dat je al eens gecreeerd zou kunnen hebben:

code:

testobj = Test.init(testobj, [params])

Hmmm nu begin ik toch echt wel ver uit te wijden

[Verwijderd]

ik zal is kijken of ik een converter kan vinden in delphi..
nooit naar gekeken eigenlijk

[mulder]

Op vrijdag 28 december 2001 01:29 schreef Yarvieh het volgende:
Nou vraag ik me heel stiekum af waarom je de franstalige versie van google gebruikt

Omdat ik toen ik in Frankrijk zat, lekker op een azerty te typen... Ahhh qwerty qwerty, wat typt dat dan weer lekker.