5.40 b2 Je ne comprend plus grand chose aux string ...

[Anonyme2]

G-Rom,

on peut passer une variable par sa valeur ou par son adresse quelque soit le type sauf les string et var structurées.

Si on supprime le @ des string (ce que je trouve anormal puisque c'est vraiment l'adresse que l'on passe et pas la valeur), alors pourquoi ne pas le faire pour les variables normales, il devient donc presque impossible simplement de passer une variable en paramètre et pas sa valeur.

J'ai toujours pensé que le compilateur devrait indiquer des erreurs lorsque l'on passe une variable structurée sans le @ mais suis-je puriste ?

Ce que je dis, c'est que les pointeurs sur des chaines peuvent également servir pour recevoir certaines valeurs en retour, crois-tu que que si le compilo oblige à écrire une chaine (c'est aberrant) alors que ce que l'on pourrait recevoir une info voir mettre une valeur de type ATOM et pas qu'un 0, c'est un fonctionnement normal ?

Il y a des milliers d'API, ce n'est pas raisonnable d'en modifier certaines si le cas se présente comme pour DrawText.

Adapter mon code ne me gêne pas mais je pense que Fred ne nous dit pas tout sur les raisons profondes de ce changement voulu par lui (et par qui d'autre ?) et qui gênent énormément.


Mon esprit suspicieux me dit que c'est peut-être un corollaire de SpiderBasic ...

[falsam]

Mon esprit suspicieux me dit que c'est peut-être un corollaire de SpiderBasic ...

Ha bon ?

Un indice : La bibliothéque VectorDrawing.

[Anonyme2]

Mon esprit suspicieux me dit que c'est peut-être un corollaire de SpiderBasic ...

Ha bon ?

Un indice : La bibliothéque VectorDrawing.

Tu sais des choses ?

Simplement, la raison invoquée par Fred est tellement comment dire ... peu crédible, vraiment je ne le crois pas du tout.
Il y a bien longtemps, sur une autre planète heu ... je m'égare; je ne crois plus au père Noël même si ça fait pleurer dans les chaumières

Je pense qu'ici il y a des grands garçons qui savent comprendre les choses.

[falsam]

Tu sais des choses ?

Non je ne sais rien, juste des indices qui me pousse à penser comme toi. Mais surement que je suis en plein fantasme.

[nico]

Code : Tout sélectionner

Sérieusement, pour les codeurs qui veulent sortir des fonctions toutes prêtes, pourquoi compliquer la syntaxe ?
Tu sais utiliser une API, tu gères, tu sais pas tu passes ton chemin...

C'est clair, je ne trouve en rien que ce soit une simplification, non seulement pour l'histoire du in/out mais aussi parce qu'une API, ça peut être aussi des tas de choses avec des callbacks à mettre en place par exemple et des variables d'entrées qui sont souvent des pointeurs.

Ce langage est intéressant pour deux choses, soit pour une initiation à la programmation ou pour une simplification d'écriture, de syntaxe et de rapidité. J'adore PureBasic mais je ne ne le recommanderais jamais comme premier langage à quelqu'un qui veut se lancer sérieusement dans la programmation. PureBasic est génial quand tu comprends en partie ce qu'il y a derrière, il ne t'apprend pas les concepts de programmation et il y a un moment où il faut se sortir les mains des poches.

[Anonyme2]

Mon esprit suspicieux me dit que c'est peut-être un corollaire de SpiderBasic ..

tu penses a une grande union dans le futur Pb et SB , ou plutot une question d'uniformisation pour le développement futur des 2 systemes ?

Plutôt la deuxième, mais rien qui étaye ce que je dis.

[nico]

D'ailleurs si Fred nous lis, il est invraisemblable que dans la Doc fourni de PureBasic qu'il n'y ai pas pas le typage des valeurs retournées par les fonctions, ceci expliquant cela.

[Fred]

OK, je vais formuler autrement. Pour l'instant les API fonctionnement facilement parce que PB a choisi de stocker ses chaines dans un format compatible avec celle de Windows. Mais ce n'est pas le cas sur Linux par exemple, où tout est en UTF8 en entrée:

https://developer.gnome.org/gtk3/stable ... -set-title

gtk_window_set_title_(window, utf8string)

En PB avec la conversion auto, tu peux faire:

gtk_window_set_title_(window, "Mon super titre").

Sans, tu dois te taper la conversion de ton string en UTF8 et ensuite l'envoyer à la fonction (ce qui veut dire probablement une fonction qui alloue/convertit et un autre appel pour librer le string).

Maintenant, imagine qu'on décide que le format des string interne à PB change: on choisit l'UTF-32 car c'est encore plus efficace pour les langues style chinois, toutes tes fonctions API Windows qui assumait que c’était dans le bon format vont foirer, alors que si on force le format string, PB pourra toujours se charger de la conversion. OK, c'est un parti pris, mais pour moi je pense que la facilité de la manipulation des API est primordiale et doit etre integré au language. Quand MS a créé les MFC pour le C++, il a tout wrappé pour que ca colle au C++ en prenant des CString en entrée et pas des pointeurs de string. C'est logique, et c'est ce qui fait qu'un language est plus efficace pour le developpement qu'un autre. Apres chacun ses besoins, si tu penses que tu as besoin de plus de flexibilité, tu peux faire tes imports. Sur le forum anglais, apres la correction, je ne vois pas trop de probleme.

[Fred]

D'ailleurs si Fred nous lis, il est invraisemblable que dans la Doc fourni de PureBasic qu'il n'y ai pas pas le typage des valeurs retournées par les fonctions, ceci expliquant cela.

Comment ca ? Si rien n'est précisé, c'est qu'il retourne un integer, c'est le type de PB par défaut. C'est pas la roulette non plus, faut pas abuser.

[nico]

C'est du bon sens, on indique les types d'entrées et on indique le type de sortie pour chaque fonction et pas seulement quand le type n'est pas un Integer, ç'est des petites choses simples qui facilitent la vie et qui évitent des confusions.

[Fred]

C'est quoi le lien entre API Windows et SpiderBasic ? OK, j'arrete de lire ce thread c'est du grand n'importe quoi .

[Anonyme2]

Fred,

si je comprend bien, il y aura une très forte limite dans l'utilisation des API wrappées par PB sur ce que le pointeur peut prendre comme valeur, cf drawtext_() que tu as modifié.

Mais des API comme cela, il y en plein.

Peut-être une flexibilité sur les types in/out comme dit Nico.


Fred comme tes explications ne tenaient pas la route, de là nait une suspicion légitime. Le seul rapport que je voyais est SPiderBasic avec PB.

[nico]

Le genre de problème dont je parle:

Syntaxe

Resultat = Date([Annee, Mois, Jour, Heure, Minute, Seconde])
Description

Renvoie la valeur du temps système (nombre de secondes écoulées depuis le '01/01/1970 0:00:00').
Arguments

Annee, Mois, Jour, Heure, Minute, Seconde (optionnel) Si les variables Annee, Mois, Jour, Heure, Minute et Seconde sont spécifiées, la représentation en secondes de cette date est renvoyée.

Valeur de retour

Renvoie le nombre de secondes écoulée.


Le temps est t'il différent suivant qu'on sur 32 ou 64 bit ? et si oui pourquoi cela n'est t'il pas spécifié.


Si on en crois la doc, il y aurais des integer partout, (je pense que c'est pour une simplification), mais je ne trouve pas ça correct cette façon de faire.
(Je ne cherche qu'à comprendre le pourquoi du comment)

[nico]

Nous sommes des enfants de PureBasic, on s'amuse beaucoup avec lui et on ne voudrais jamais le quitter. Mais un exemple simple, je commence la programmation, Purebasic n'oblige pas à définir les variables alors je ne le fais pas car je pense que PureBasic a raison et lorsqu'on est passé au 64 bit, j'ai compris la galère. Les critiques de professionnels qui disent, c'est pas sérieux ce langage, on n'est pas obligé de définir les variables, prennent tout son sens d'un coup et on voit tout l'intérêt de respecter certaines pratiques.

La rigueur a du bon car au delà de PureBasic, les choses ne sont plus aussi simple.

[GallyHC]

Tu peux aussi pensé, bien faire en déclarant toutes tes variables en ".l" et avoir de gros problème par la suite en 64 bits, car il faut tout déclarer en ".i" ;p.

Cordialement,
GallyHC