Retourner un string depuis une fonction en C

Citation:

---

Envoyé par Obsidian

Bonjour,

Oui parce que les directives et les macros en # sont traitées par le pré-processeur. Il n'en reste rien après la compilation… ni même avant ! Elles sont censées avoir toutes été substituées le cas échéant par leur motif final au moment où le compilateur proprement dit est appelé. Avec gcc, tu peux utiliser l'option -E pour lui demander

...

---

Merci, c'est très clair.
Le # permet d'obtenir un exécutable plus propre et plus rapide.
À préférer, même si le calcul obtenu ne change pas.

Citation:

---

Envoyé par Informt2025

Jette un coup d’oïl sur le C# c'est un bon compromis entre la complexité du C++ et la lenteur Python dans l'envirenement windows , un langage disponible sur tous les pc qu'on peut l’utiliser à partir du Notepad++ sans rien d'autre... il supporte les chaînes texte nativement et le surcharge des opérateurs pour implémenter de nouveaux types de donné en math, et supporte également les générateurs ou énumérateurs pausables qui sont très pratiques pour gérer les séquences complexes

---

Merci.
Je ne connaissais pas cette utilisation du C#.
Je vais voir cela mais pour le moment je ne veux pas me disperser.
Je note précieusement.

Citation:

---

Envoyé par henderson

Fluorine #10 :

Alors dans ce cas pourquoi ne pas faire un plus grand plongeon en écrivant un programme qui va transcrire un source BASIC en source C ?

---

Ouille !!! Ce n'est pas rien.
J'y ai songé, c'était un peu mon idée avec MID$.
J'avais commencé une ébauche qui transcode les instructions BASIC ( REM, FOR, WHILE,... ) en parfum C ( //, for, while ), et des ; pour terminer les lignes.
Cela allège l'usage du clavier lors de nombreux polynômes, sauce Horner, transcodé en C.
Cela aide un peu, tout comme la moulinette de l'AI.
Je me retrouve ainsi avec un code BASIC et des instructions parfum C...
C'est plus compliqué pour les boucles, même l'AI cafouille.

Finalement je me contente d'un programme qui me transcode les majuscules en minuscules.

-------------------------------

J'ai un peu avancé dans mes transcodage de BASIC en C.
Cela se passe plutôt bien.
J'avais largement abusé des DOUBLE, je modifie en adaptant vu qu'un double pour un compteur de 1 à 10...
J'étais une débutante, pas de livre "BASIC pour les nulles" et cela n'avait pas de nuisance visible.
Un abus de variables globales. Je transcode en deux temps, de BASIC en C, puis j'intègre les variables globales en locales.
Je constate avec certains programmes que j'étais vraiment une débutante. Heureusement, un code plutôt structuré et des commentaires. Le jour et la nuit, je constate mon évolution ( l'âge aussi :mrgreen: )...
D'autres programmes de sources inconnues sont parfois incompréhensibles. Du spaghetti hors date limite de consommation.
Du code parfois peu judicieux alors que d'autres méthodes existent.

Je continue mes transcodages lorsque j'ai un moment. Cela avance doucement.
J'évite de me disperser hors du C pour le moment.

Merci à tous/toutes pour toutes ces sympathiques informations qui me sont très utiles. Je me sent moins seule dans ce travail de longue haleine.
Je suis en pleine transition du C vers le C, mais de l'ancien vers le moderne.
Des articles pdf sur le forum, que j'ai téléchargés.

En faisant une toute petite recherche, il y aurait ceci : https://www.bcxbasiccoders.com/

Je ne sais pas du tout ce que ça vaut !

Par contre, si ça génère des fichiers *.c ou *.cpp ça te permettrait de voir comment les autres font !

Bonjour,

Citation:

---

Envoyé par Fluorine

Le # permet d'obtenir un exécutable plus propre et plus rapide.
À préférer, même si le calcul obtenu ne change pas.

---

Pas tout-à-fait.

Cela va être indiqué dans le présent pour définir des constantes symboliques sans avoir besoin d'instancier inutilement des ressources dans l'exécutable et ça, c'est une bonne chose en soi. Le préprocesseur sert également à des dizaines d'autres choses, comme par exemple faire de la compilation conditionnelle pour insérer ou non des ressources qui dépendent du système pour lequel on compile, ou pour tenir compte de contextes tel qu'un « mode Debug », par exemple.

Or, il arrive que lorsqu'un programme se complexifie à mesure qu'il évolue, on recoure de plus en plus souvent à ces macros et qu'elles-mêmes deviennent de plus en plus compliquées et on se retrouve parfois à embarquer des fonctions entières dans des macros au point de déléguer au préprocesseur ce qui devrait être de la responsabilité du compilateur.

En outre, même s'il est possible d'écrire des macros imbriquées, elles restent quand même complètement indépendantes de la structure du programme : le préprocesseur lit le fichier linéairement et fait les substitutions partout où nécessaires mais à dire vrai, il pourrait le faire sur un fichier texte ou sur le code source d'un autre langage et ça marcherait tout aussi bien.

Un exemple simple : typedef. Il est évident qu'en langage C, si l'on souhaite définir un nouveau type, en fait un alias d'un type natif ou composé déjà défini comme une structure, il faut utiliser ce mot-clé typedef pour écrire par exemple typedef int entier et non #define entier int. Dans le second cas, ça fonctionnera quand même mais le compilateur ne saura pas que c'est à ça que cela sert, ne tiendra pas compte de la portée locale du bloc où il est défini et en réalité ne verra jamais apparaître le symbole « entier » du tout puisqu'il aura été résolu en amont par le préprocesseur. Or, ces effets deviennent particulièrement sensibles en C++, spécialement avec les template, où il devient nécessaire qu'un symbole soit reconnu non seulement comme identifiant mais également comme un nom de type valable pour que le tout fonctionne.

En ce sens, on pourrait penser qu'il faudrait justement se passer des macros chaque fois qu'on le peut mais ta question est un excellent contre-exemple.

Citation:

---

Envoyé par henderson

En faisant une toute petite recherche, il y aurait ceci : https://www.bcxbasiccoders.com/

Je ne sais pas du tout ce que ça vaut !

Par contre, si ça génère des fichiers *.c ou *.cpp ça te permettrait de voir comment les autres font !

---

Un joli programme qui génère du code C, très complexe mais hélas illisible en tant qu'humain. Mais parfois compilable.
Il y a quelques convertisseurs de ce type, mais toujours un code C humainement inexploitable.
J'avais tenté de voir les sources de QB64 dans ce but, mais même problème.
Le spaghetti a parfois l'avantage de pouvoir suivre le spaghetti sauf parfois adapter une fonction spécifique. Peu de risques de sub/fonction à implémenter en se prenant la tête au risque de calvitie fulgurante.
Le résultat fonctionne, mais incompréhensible; je déteste.

Citation:

---

Envoyé par Obsidian

Bonjour,

Pas tout-à-fait.
....

.

---

Hello,

Logique...
Une explication encore très claire.
Merci.

Bonjour,

La traduction Basic vers C n'a pas besoin d'être faîte entièrement à la main. Il existe des transpileurs (mot clé à utiliser our la recherche) qui font le travail. J'en ai trouvé plusieurs mais ne sais quels sont les meilleurs. Quoiqu'il en soit, le code C résultant (même quand il marche correctement) n'est généralement des plus beaux. Il convient donc de le reprendre ne serai-ce qu'en contrôle.

Salutations

Citation:

---

Envoyé par Guesset

Bonjour,

La traduction Basic vers C n'a pas besoin d'être faîte entièrement à la main. Il existe des transpileurs (mot clé à utiliser our la recherche) qui font le travail.

...

Salutations

---

Hello,

Il y en a quelques-uns en effet.
BCX, BaCo, B2C, QBasicToCpp, BASIC256,...
Hélas le code C obtenu est - humainement - illisible et très compliqué. Pas toujours compilable non plus.
Finalement j'ai mon petit programme en C, une moulinette, qui reconnait les principales commande de mes programmes-code BASIC comme FOR, SIN, COS,... que je convertis en minuscule. Je change les : en ; et ajoute ; en fin de ligne.
J'ai un programme BASIC qui me supprime les numéros de lignes inutiles, fourni par QB4.5, et compilé sous QB64.
Ce sont des anciens programmes même pas toujours QBASIC à l'origine et des LET à supprimer.
Un PRINT devient un printf un peu bizarre, surtout avec des USING et ###.

Bien sûr je me retrouve parfois avec du code aux commandes C mais avec la syntaxe BASIC.
Cela va bien comme un Y=COS( ... ): qui devient Y= cos(...);
J'ai nombre de formules mathématiques, cela aide.
Les boucles FOR, DO, WHILE,... et MID$ sont complètement à réviser à la main.
Des passages par référence ou par valeur (selon les parenthèses) qu'il faut passer en pointeur.

Beaucoup d'adaptation avec les variables globales et mon abus de DOUBLE en débutante.

J'exclus de passer un code source "sensible" sur un transpileur en ligne.
J'ai fait quelques test par AI... Pas terrible.
Tout cela permet de dégrossir sommairement le code concerné en économisant l'usage du clavier.

Merci.

Si on est en mode console, comment fait-on LOCATE ?

Citation:

---

Envoyé par henderson

Si on est en mode console, comment fait-on LOCATE ?

---

Hello,

Aucune idée, je n'ai pas eu le problème.
printf aligne les résultats, à la suite sans adresse particulière de la console.

Peut-être un mode copiant le MSDOS qui répond aux interruptions du processeur en mode assembleur.
Voir:
Ralph Brown Interrupt List
... des odeurs de naphtaline...
J'avais bidouillé avec cela, cela date.

J'ai trouvé:
https://learn.microsoft.com/en-us/wi...sole-functions

Bonjour,

Citation:

---

Envoyé par henderson

Si on est en mode console, comment fait-on LOCATE ?

---

Citation:

---

Envoyé par Fluorine

Aucune idée, je n'ai pas eu le problème.
printf aligne les résultats, à la suite sans adresse particulière de la console.

---

Sans surprise, on commence par vérifier si le viewport (ici la console) en est capable ou non dans l'absolu. C'est évident une fois qu'on le dit, mais le problème concerne en fait beaucoup de projets et est à la source de pas mal d'erreurs de conception. De là, il y a deux possibilités :

• La console en est capable. On honore donc la commande. Sur PC, la console est en général un terminal DEC ANSI plus ou moins bien émulé, donc le curseur peut être replacé avec des commandes CSI. Il y en a plusieurs, mais le placement absolut se fait avec H : la séquence ESC [ 13,8 H (sans les espaces) place le curseur en ligne 13, colonne 8. Sur les Thomson 8 bits, équipés de différentes versions du BASIC Microsoft, c'était le Videotex qui était utilisé et ils pouvaient se piloter comme un Minitel ;
• La console n'en est pas capable : soit on ignore la commande silencieusement, soit on déclenche une erreur Device I/O Error.

Le dernier point soulève un point important, par lequel tout projet devrait commencer ou qui au moins devrait être défini assez tôt dans son développement : l'environnement minimum exigible.

Ici, il y a deux choses à déterminer :

1) doit-on toujours disposer d'une console ? Si on se réfère au fonctionnement du QBasic, le code source se développait soit dans une interface dédiée, soit depuis un éditeur distinct. À l'exécution, par contre, l'interpréteur préparait l'écran au démarrage (ce qui nous paraissait complètement implicite) en le vidant totalement et en le mettant de fait à la disposition du programme. Si les instructions du BASIC en dépendent, il faut peut-être l'émuler en mémoire quitte à ne pas l'afficher. Par contre, on pouvait également faire l'inverse : travailler en mode fichier vers le bon périphérique de sortie : « CASS: » pour écrire sur la cassette (oui…), « LPRT: » pour écrire vers l'imprimante et… « SCRN: » pour écrire vers l'écran, comme on le fait normalement avec PRINT en dehors de tout descripteur ouvert.

2) la prise en charge des erreurs. Jusqu'à présent, on a fait l'hypothèse que les commandes et instructions réussissaient toujours. En cas d'erreur, en revanche, il y a deux cas possibles : soit un arrêt immédiat avec un message (à renvoyer vers la bonne sortie et seulement si elle est disponible), soit une prise en charge avec ON ERROR GOTO/GOSUB puis RESUME.

Ce n'est pas forcément très difficile compte tenu du fait que le jeu d'instruction BASIC est limité et que son environnement l'était aussi, ce qui limite le nombre de cas de figures différents à prendre en charge. Mais il est certain que cela va demander de plancher dessus dès que l'on va dépasser les quelques fonctions initiales exposées ici.

Surtout si on fait face à des sources BASIC très anciens qui effectuaient des appels à des fonctions système ... comme sur l'AMSTRAD et il me semble que c'était aussi le cas avec le ZX81 via l'instruction CALL ...!
Ca remonte a plus de quarante ans !

Citation:

---

Envoyé par henderson

Surtout si on fait face à des sources BASIC très anciens
...
avec le ZX81 via l'instruction CALL ...!
Ca remonte a plus de quarante ans !

---

Hello,

Oui.
J'ai connu avec le Spectrum Sinclair. Les PEEK et POKE pour l'accès direct mémoire, son BASIC et l'extension BetaBasic.
Les cassettes, variante des diskettes.
Et cela fonctionnait avec seulement 64 puis 128K de mémoire. Cela semble impossible maintenant !
Mes débuts en assembleur sur Z80 de Zilog...

Une époque lointaine où chaque octet gagné était une victoire !
Le CPC d'AMSTRAD tournait aussi avec un Z80.
Contrairement à l'idée reçue, le Z80 pouvait adresser 2 * 64K : grâce au bon usage de IN n,(C) et OUT(C),n avec le contenu de B sur le MSB du bus d'adressage et C sur le LSB !
Au niveau des ports on n'utilisait que la partie basse de l'adresse, laissant croire que ...!

Pour en revenir à nos moutons : ne pas oublier la bonne vieille notion de cahier des charges pour aller dans le sens de ce que nous dit Obsidian !
Je pense que le BASIC est suffisamment intuitif pour qu'on puisse assez facilement transcrire ce qu'il fait en C ou C++ quand bien même on puisse y laisser trainer des goto à gogo ou des routines à multiples points d'entrée !
Tout ça, ça ce code non pas pour être contemplé mais pour être exécuté !