1

Franchement c'est n'importe quoi.

j'ai voulu installer VB pour développer un truc rapide dont j'avais besoin: écrire un texte sur une image et en récupérer les pixels pour faire un sprite (y'a 11000 sprites donc je fais pas à la main, non, non)

en vb6 j'ai déja fait ça, faut 10 lignes entre picture.print et picture.point()

maintenant, faut un code horrible genre:
        Dim g As Graphics
        Dim s As String
        Dim f As Font
        Dim p As Pen
        Dim b As Bitmap

        f = New Font("Gulim", size, FontStyle.Regular, GraphicsUnit.Pixel, 0)
        p = New Pen(Color.Red, 1)
        g = Graphics.FromImage(b)
        PictureBox1.Image = b
        PictureBox1.Refresh()
        v = 1 - (b.GetPixel(x, y).R / 255)

etc etc...

franchement j'ai l'impression d'écrire du java sans les points virgules, avec DIM truc AS TYPE au lieu de TYPE truc en C & co. trois mots clés au lieu d'un... wow

je me demande où est passé l'intéret du basic (oui, oui, je sais) qui était de pouvoir développer rapidement.

quand on regarde l'aide de VB aussi, on se rend compte que chaque langage microsoft: VB,C#,C++,J# est EXACTEMENT le même avec un analyseur syntaxique différent. Pour preuve, les pages d'aide présentent les exemples dans chaque langage. En gros, c'est le même langage avec des mots clés différents. Ils se sont pas trop fait chier pour leur super interopérabilité entre les langages neutral

quand en plus on sait que tout ça n'est pas natif mais interprété par leur machine virtuelle .Net à la con, et que c'est la stratégie principale de développement de microsoft, on a pas fini de voir les applications ramer, et faudra pas s'étonner!

pourquoi abandonne ton le natif? pourquoi essaye t on d'émuler un CPU software pourri sur des CPUs x86 de plus en plus puissants? le prétexte c'est protéger les accès mémoire? mais normalement, quand on programme pas comme un porc, y'a pas d'accès mémoire défectueux!

bref, j'en ai soupé du VB, j'amais pas mal VB6, j'ai développé pas mal de trucs avec, mais là , non, je préfère continuer en java, plutot que de programmer dans un ersatz de java avec une syntaxe VB-like neutral (d'ailleurs cette histoire de graphique, ça veut dire que toutes mes applis graphiques précédentes ne fonctionnent plus avec cette version de VB)

donc tshaw définitivement à la programmation microsoft.

voila c'était le coup de geule du jour.

edit: même DoEvents marche plus gol j'fais comment moi?

2

tu t'es posé la question de savoir pourquoi t'as monté de version ? sinon fallait garder la 6 (ou la 5 dont l'aide est plus complète offline)
avatar
Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

3

oui, parce que normalement nouveau c'est censé être mieux.

en tout cas ça marche pour NetBeans.

ben pas pour l'éditeur de visual studio on dirait.

OK le design est impeccable mais la refonte du langage, c'est pas ce que j'attendais.

le prochain coup je resterai au java.

4

vb ca sux

le dev rapide il se fait en c#

5

squalyl^2 :
quand en plus on sait que tout ça n'est pas natif mais interprété par leur machine virtuelle .Net à la con, et que c'est la stratégie principale de développement de microsoft, on a pas fini de voir les applications ramer, et faudra pas s'étonner!

Bouah ça rame pas tant que ça, même parfois moins que le Java. Et est-ce que VB.Net est vraiment plus lent que les versions précédentes ?
Pour C++, je suppose que rien n'empêche de continuer à compiler en natif.
squalyl^2 :
pourquoi abandonne ton le natif? pourquoi essaye t on d'émuler un CPU software pourri sur des CPUs x86 de plus en plus puissants? le prétexte c'est protéger les accès mémoire? mais normalement, quand on programme pas comme un porc, y'a pas d'accès mémoire défectueux!

Optimisation JIT, Garbage Collection, réflexion, attributes, ... tout ça happy
Rintintin :
vb ca sux
le dev rapide il se fait en c#


pencil, C# est le seul langage conçu entièrement pour .NET.

6

squalyl^2 :
quand en plus on sait que tout ça n'est pas natif mais interprété par leur machine virtuelle .Net à la con, et que c'est la stratégie principale de développement de microsoft, on a pas fini de voir les applications ramer, et faudra pas s'étonner!

Bouah ça rame pas tant que ça, même parfois moins que le Java. Et est-ce que VB.NET est vraiment plus lent que les versions précédentes ?
Pour C++, je suppose que rien n'empêche de continuer à compiler en natif.
squalyl^2 :
quand on regarde l'aide de VB aussi, on se rend compte que chaque langage microsoft: VB,C#,C++,J# est EXACTEMENT le même avec un analyseur syntaxique différent.

C'est la stratégie Microsoft, elle se comprend parfaitement. Une plateforme pour les gouverner tous, quelque soit le langage final.
squalyl^2 :
pourquoi abandonne ton le natif? pourquoi essaye t on d'émuler un CPU software pourri sur des CPUs x86 de plus en plus puissants? le prétexte c'est protéger les accès mémoire? mais normalement, quand on programme pas comme un porc, y'a pas d'accès mémoire défectueux!

Optimisation JIT, Garbage Collection, réflexion, attributes, ... tout ça happy
Rintintin :
vb ca sux
le dev rapide il se fait en c#

pencil, C# est le seul langage conçu spécifiquement pour .NET.

7

Rintintin :
vb ca sux

le dev rapide il se fait en c#

dim g as Graphics
-> Graphics g;
je suis d'accord.
mais... si tu grattes un peu je pense qu'il suffit de quelques regex pour transformer du vb en c# et réciproquement neutral donc pour moi c'est bonnet blanc et blanc bonnet.
ExtendeD :
Bouah ça rame pas tant que ça, même parfois moins que le Java. Et est-ce que VB.Net est vraiment plus lent que les versions précédentes ?

sisi, y'a pas photo. pour accéder aux pixels d'une image ça va à peu près mais textbox.appendtext() est d'une lenteur roll ça divisait la vitesse de mon prog par au moins 5.
ExtendeD :
Optimisation JIT, Garbage Collection, réflexion, attributes, ... tout ça smile2.gif

oui ben je vois pas ce que le JIT rajoute comme optimisation. parce que l'optimisation ça se fait aussi à la compilation normale. et en plus ça tourne plus rapidement.
le GC ça existe en C++ donc je suppose que la VM n'est pas exactement nécessaire.
et quand on code proprement chaque malloc a un free alors chaque objet doit et peut ^etre détruit.

enfin toussa pour dire que détruire les performances pour privilégier la sécurité la fainéantise du programmeur, ça craint.

moi je vois que deux objectifs à Net:

* Autoriser les programmeurs à coder salement sans coredumper toutes les 5 minutes
* Surtout a mon avis leur stratégie c'est virer tous ces putains de virus windows en les emp^echant de s'exécuter sur le CPU directement.

A la fin tous les programmes devront ^etre en .Net pour fonctionner sous win, et le compilateur JIT deviendra un composant du noyau en appliquant une politique de controle stricte des ressources CPU et en autorisant la compilation de ce que Microsoft a décidé, tout en emp^echant le reste. donc un pogramme natif et un virus, ce sera idem.

8

"et quand on code proprement chaque malloc a un free alors chaque objet doit et peut ^etre détruit. "

De toute maniere ce n'est pas un argument, car le system desalloue automatiquement toutes tes allocations a la fin de l execution d'un programme...

Sinon je n'y connais pas trop en VB etc.. j'aimerai bien qu'on m'explique:
Optimisation JIT, Garbage Collection, réflexion, attributes, ... tout ça

Optimisation JIT:
Les procédures sont soumises à la compilation juste-à-temps (JIT). Une procédure n'est compilée qu'après son premier appel. Le compilateur JIT tente d'effectuer plusieurs optimisations sur une procédure lors de sa compilation, telles que la génération du code en ligne pour les petits appels de procédure. Les procédures extrêmement volumineuses ne peuvent pas bénéficier de ces optimisations. Par exemple, il est peu probable qu'une procédure comportant plus de 1 000 lignes bénéficie d'une optimisation JIT.
-> C est quoi l'avantage par rapport au compilé?
Garbage Collection:
L'os desalloue bien toute allocation du programme a sa fin non?
pour réflexion, attributes j ai pas trouvé :/

9

la réflexion je crois que ça permet de faire object->executeMethod ("tostring", parametres)
j'ai jamais vu un seul programme utile qui utilise ça.
en C on a les pointeurs de fonctions et en objet c'est utile pour quoi faire?

les attributs je sais pas

le JIT c'est la compilation juste à temps, alors autant compiler au départ, vu que le prétexte d'une VM c'est d'^etre cross platform et que .Net est absolument complètement designé pour windows-x86, donc il est parfaitement inutile de compiler juste à temps. (ouais OK on est multiplateforme win9x/win2k/winxp/winvista #modtop# )

encore si on pouvait lancer du .net sur mac ou solaris, ok ça vaudrait le coup, mais ça en est où mono? je doute des performances par rapport à .net windows.
On retourne à l'age de pierre où les programmes QuickBasic 4.3 étaient tokenisés et ajoutés à un interpréteur copié collé dans chaque .exegrin
JackosKing :
De toute maniere ce n'est pas un argument, car le system desalloue automatiquement toutes tes allocations a la fin de l execution d'un programme...


autre citation de toi sur mon blog
1. JackosKing à 17:04 03/01/2006 -
Suppr.
tout a la fin si l OS desalloue tout, mais c est tres crade.
alors c'est un workaroud crados ou une garbage collection officielle?

essaye d'appeler 100 fois en séquence une fonction qui crée 10 000 000 objets en C++ et en java, tu verras la différence. OK c'est désalloué à la fin du processus, mais bon sorry

10

et si tu développes un serveur qui tourne 24h/24, qui ne doit jamais quitter, que ça libère la mémoire à sa mort, tu es bien content... ça veut dire que la mémoire ne sera jamais libérée... (ou que le service ne sera plus rendu ; pas glop)
avatar
Tutorial C (TI-89/92+/v200) - Articles Développement Web (PHP, Javascript, ...)
« What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against? » - Larry Wall

11

syntax error in line 1 near "que ça libère la mémoire à sa mort, tu es bien content... ça veut dire que la mémoire ne sera jamais libérée..." sorry

(grin désolé mais soit tu te contredis soit t'expliques pas 100% clairement grin )

12

oui, enfin un server qui tourne 24h/24 via une machine virtuel, je trouve ca pas tres logique.
Apres oui faut desallouer en C/C++ sau court du programme, mais bon avec de la rigeure on y arrive wink

13

./11> s'il tourne h24, il meurt pas => mémoire pas libérée
avatar
Tutorial C (TI-89/92+/v200) - Articles Développement Web (PHP, Javascript, ...)
« What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against? » - Larry Wall

14

Perso je trouve que le .Net c'est reinventer le java sans l'un de ses plus grands avantages: Portabilité

15

pencil +1

la portabilté .net est censée exister avec mono, mais bon c'est utopique de penser qu'ils arriveront à un résultat semblable à celui de microsoft.

edit: ah tiens je viens d'aller voir mono, ça commence à marcher:
http://www.mono-project.com/Main_Page
http://www.mono-project.com/Screenshots
y'en a m^eme un qui a écrit une VM java pour .net destinée à faire marcher eclipse #tris# non mais c'est n'importe quoi triso

16

heu question con pour l interface graphique de mono il faut utiliser gtk#? ou c'est deja gere par mono?
Parce que gtk c pas top sous autre chose que linux:/

17

y'a gtk et un support wine. je sais rien d'autre.

18

Alalalala les trolls quand vous nous tenez sorry


-> regexp vb.net <-> C#

dans le sens vb.net -> C# c'est peut etre possible (et encore vb.net a des tournures bizzares des fois) mais dans l'autre sens c'est certain que c'est impossible, pourquoi ? parceque c# propose bcp plus que vb.net. La preuve, vb.net a été étendu pour mieux supporter le .net framework dans VS.net 2005

VB.net n'est proposé uniquement pour les "nostalgique" du VB6 qui ne connaissent pas la syntaxe du C.

D'ailleurs si on regarde de plus pret, vb.net n'est que l'évolution de VB6, et oui !
VB6 est deja fortement orienté objet & co, mais qui utilisait reelement l'objet sous VB6 ? pas gd monde.


-> .net plus lent non natif ?

C'est faut, premiere chose que fait le framework (enfin si l'application le demande a l'install) c'est de convertir automatiquement le MSIL en code natif

-> Ya que windows gnagna

x86_64 tu connais ? ben la compilation MSIL -> natif permet d'avoir 1 executable et 2 binaire, un x86_32 et un x86_64, le tout sans rien faire de spécial.

la XBox 360 tu connais ptet aussi nan ?
Ben le proco est un PowerPC, pas un Pentium. Bizzare la programmation en .net est normalement possible

Ha oui j'oubliais

Les Pocket PC ou auters Smartphone sous windows CE, tu crois qu'il on quoi comme proco ? un Pentium ? Non
Ce sont des proco dérivé des ARM. et bizzarement une appli ecrite pour Pocket PC marche sans recompilation sous windows, etrange hein ?

-> Mono pas rapide, complet & co

C'est faut mono est au niveau du framework 1.0/1.1 ce qui est deja plutot bien actuellement. Les seuls points dont il souffre sont lié au GUI

-> Garbage Collector en C++

Non absolument pas, du moins pas du tout dans le sens que le GC prend dans des langagues interprété comme le C# et le Java


pour ce qui est des autres "fonctionnalitée" que peut proposer une approche a la .net, un seul autre langage qui lui n'est pas interpreté (du moins pas de maniere habituelle, car c'est quand meme du compilé natif, mais bon je passe les détails) est l'Objective-C qui permet tout un tas de choses que le C++ n'a pas
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

19

Godzil :
VB6 est deja fortement orienté objet & co, mais qui utilisait reelement l'objet sous VB6 ? pas gd monde.

justement c'est ça qui le rend rapide et facile à développer, et qui a été perdu.
Godzil :
(enfin si l'application le demande a l'install)

jamais rencontré
Godzil :
x86_64 tu connais ? ben la compilation MSIL -> natif permet d'avoir 1 executable et 2 binaire, un x86_32 et un x86_64, le tout sans rien faire de spécial.

les binaires 32 bits sont exécutables sur x86_64. après c'est unehistoire de linker, pas de code binaire. D'ailleurs le x86_64 sous windows est pas particulièrement développé, hein.
Godzil :
Ben le proco est un PowerPC, pas un Pentium. Bizzare la programmation en .net est normalement possible

parce que c'est fait par microsoft, donc ils ont compilé leur code proprio sur leur bécane. d'accord ça marche ptet aussi.
d'ailleurs j'espère que les jeux xbox360 sont pas codés en msil trigic enfin vu les démos à la fnac ça m'étonnerait. donc c'est quoi l'intéret du .net sur xbox?
Godzil :
Ce sont des proco dérivé des ARM. et bizzarement une appli ecrite pour Pocket PC marche sans recompilation sous windows, etrange hein ?

encore. pocket pc c'est microsoft, donc ça veut pas dire grand chose. une appli .net quelconque faite sur PC,j'ai des doutes quant au fonctionnement direct du binaire "msil" sur pocketpc.

20

mais pkoi tu veux utiliser autre chose que du microsoft ?

21

et quand on code proprement chaque malloc a un free alors chaque objet doit et peut ^etre détruit.

Le but est pas de coder proprement mais de gagner du temps smile
JackosKing :
Perso je trouve que le .Net c'est reinventer le java sans l'un de ses plus grands avantages: Portabilité

Exactement. C'est reprendre les avantages de Java, mais en favorisant l'OS maison.
Godzil :
-> .net plus lent non natif ?
C'est faut, premiere chose que fait le framework (enfin si l'application le demande a l'install) c'est de convertir automatiquement le MSIL en code natif

pencil. Ce qui rame c'est pas vraiment le fait que ce soit du bytecode, plutôt qu'on ait parfois à traverser tout le framework avant d'arriver à la WinAPI...
Godzil :
C'est faut mono est au niveau du framework 1.0/1.1 ce qui est deja plutot bien actuellement. Les seuls points dont il souffre sont lié au GUI

J'avais lu qu'ils allaient avoir un tas de problèmes à réimplémenter les nouveaux trucs de réseau des prochaines versions...
Godzil :
x86_64 tu connais ? (etc...)

Doit aussi y'avoir l'Itanium dans la liste non ?
squalyl^2 :
j'ai des doutes quant au fonctionnement direct du binaire "msil" sur pocketpc.

Ca doit probablement marcher, ce qui change c'est le framework très allégé.
squalyl^2
: les binaires 32 bits sont exécutables sur x86_64. après c'est unehistoire de linker, pas de code binaire.

Mais JIT te l'optimise spécialement en 64 bit juste avant l'exécution smile

22

ExtendeD
:
Godzil :
C'est faut mono est au niveau du framework 1.0/1.1 ce qui est deja plutot bien actuellement. Les seuls points dont il souffre sont lié au GUI

J'avais lu qu'ils allaient avoir un tas de problèmes à réimplémenter les nouveaux trucs de réseau des prochaines versions...

Tu as des détails ?
squalyl^2
: les binaires 32 bits sont exécutables sur x86_64. après c'est unehistoire de linker, pas de code binaire.

Mais JIT te l'optimise spécialement en 64 bit juste avant l'exécution smile

Et en plus, comme les structures de données ne sont pas les mêmes en 64 bits, le mode de compatibilité 32 bit n'est une solution que pour les programmes, pas pour les bibliothèques j'imagine...

« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)

23

ExtendeD :
squalyl^2 :
j'ai des doutes quant au fonctionnement direct du binaire "msil" sur pocketpc.
Ca doit probablement marcher, ce qui change c'est le framework très allégé.


Je confirme smile.
«Les gens exigent la liberté d’expression pour compenser la liberté de pensée qu’ils préfèrent éviter.» - Sören Kierkegaard

La République, c’est comme la syphilis : quand on l’a attrapée, soit on se fait sauter le caisson, soit on essaie de vivre avec.

24

-

25

oue mais langage de merde </verite> tongue

26

-

27

le c/c++ c'est lourd

le c#/java ca rox

28

-

29

Faut faire du Prolog tongue
avatar

30

oue du cobol aussi pendant qu'on y est