[F] [mOved] Mon langage est mieux que le tien - Page 174

C'est ce que j'avais tenté en premier.

y'a ptet un caractère d'échapement (ou un consigne stricte de compilateur pour que pouvoir définir un truc comme ce qui est un espace après son alias)

Je pense que c'est une blague et effectivement ça ne marche pas. Mais sur le principe c'est bon.

En y réfléchissant 30 secondes, ça ne peut clairement pas marcher quelque soit l'encodage. Même si les caractères de type cadre pouvaient être redefinis, il faudrait les espacer à l'utilisation pour que le préprocesseur les traite individuellement.
C'est une idée marante, mais malgré tous les abus possibles du préprocesseur C, ce truc là n'est pas faisable.

Ah oui, bien vu

Je me demande s'il n'y a pas moyen de tricher en utilisant un caractère Unicode qui est considéré comme un espacement, mais qui a une largeur nulle.

Avec une police custom ça pourrait le faire.

Y a pas des caractères rigolos qui écrasent le précédent (genre \08) ?
print('< \x08>') <>

Tu peux aussi toujours avoir un pre-processeur custom

flan > si, mais je doute que les compilateurs C interprètent les séquences de contrôle de terminal (à part ce qui est considéré comme un espacement, comme les tabulations)

En effet ce n'est pas interperté, ca sera juste vu comme un charactere invalide

Ah oui, j'ai déjà vu des trucs comme ça. L'a fallu apprendre à se servir des LLM proprement. Comme les premiers résultats que j'ai eus étaient vraiment aberrants, je n'ai pas tout de suite adopté cette techno. Maintenant je le fais mais en m'attendant à ce genre de bugs subtils (j'ai eu plus bizarre que ça, et en fait le problème de ChatGPT par exemple, c'est qu'il a tendance à mixer des concepts de trucs incompatibles, mais vraisemblables, au cours de sa réponse ; un humain qui ferait ça serait effectivement fou, au sens médical).

Parfait

Y a de l'espoir dans l'humanité !

Pas compris si c'était une blague ou un vrai truc

Comme tu dis, ça devient difficile de faire la différence ^^

Tiens, y'a pas mal de nouveautés sympas dans C23 :
https://en.wikipedia.org/wiki/C23_(C_standard_revision)

En effet, C23 réduit l'écart avec C++. Cependant, pour du nouveau code, ou même pour un certain nombre de modernisations, je ne vois pas C23 être un meilleur choix que C++23, avec son typage qui reste plus faible, des restrictions sur les features ajoutées (constexpr qui ne fonctionne pas sur les fonctions et auto moins puissant, d'après l'article WP), une librairie standard moins étendue, etc.

Ça peut être intéressant pour ceux qui ont une base de code existante en C, et qui n'ont pas envie de switcher vers le C++. Ou pour l'embarqué avec des contraintes qui font que le C++ ne convient pas.

Mis à part ça, c'est sûr que le C n'est pas le meilleur choix pour des nouveaux développement en 2025.

Mon avis sur C23:

* New functions of libc in string.h, stdbit.h, time.h: sympathique mais pas mandatory et peut être récupéré depuis une lib tiers qui aura le mérite de fonctionner partout.
* New functions of libc in math.h: useless en l'état. Il vaut mieux utiliser des lib tiers qui au moins garantissent la précision du résultat.
* binary support: sympathique mais pas mandatory
* Make the functions const aware: good!
* #elifdef and #elifndef: useless
* #embed: good feature simplifiant le process de build.
* #warning: sympathique mais pas mandatory
* __has_include: good feature
* __VA_OPT__: sympathique mais pas mandatory (j'ai déjà appris à coder les macros pour m'en passer )
* nullptr: useless. Ils auraient mieux fait de corriger la définition de NULL qui aurait été plus safe
* _BitInt(N): je me méfie vraiment de voir ce que ca va donner coté compilateur.
* ckd_add(), ckd_sub(), ckd_mul(): sympathique mais existent déjà en lib tiers
* Variably-modified types: déjà supportait par tous les compilateurs sauf celui de MS
* Better support for using const with arrays: enfin des cast à la con en moins!
* typeof: killer feature... mais existait déjà sous forme d'extension dans tous les compilateurs...
* auto: encore pas d'avis dessus. Je n'ai encore jamais eu le réel besoin de m'en servir.
* allow redeclaration of a compatible type with the same tag: good mais anecdotique.
* Exact-width integer may now exceed intmax_t: Connerie! Autant supprimer le type intmax_t!
* Add ' digit separator to literal constants: sympathique
* Add the ability to specify the underlying type of an enum: sympathique
* Add new keywords: violiation du contrat des anciens standards sur le namespace réservé au standard (du code existant aura du mal à être compilé en C23). Bref avec C23, y'a plus de namespace réservé et on fait ce qu'on veut.
* _Decimal32 arithmetic: pas vu l'intérêt. Au début je pensais que c'était pour la finance, mais je me suis fait retoquer en me disant que ce n'était pas les calculs avec n'étaient pas bon pour. Donc je ne vois pas l'intérêt
* Labels can appear before declarations: sympatoche
* Unnamed parameters in function definitions: sympatoche
* Zero initialization with {}: pas vu la différence pratique avec {0}
* Relax requirements for variadic parameter lists: useless simplification
* C++11 attributes: putain que c'est moche!
* single-argument _Static_assert: sympatoche
* removal of K&R function declarations: good
* C++ compatibility: bof... tant que les compound literal ne sont pas supportés par le C++ on va devoir se taper des #if __cplusplus__ comme d'habitude
* u8 prefix: good
* constexpr: useless en l'état. On pouvait tout déjà faire avec un enum
* char8_t / mbrtoc8 / c8rtomb: une bad joke en l'état! A fuir.
* Allow storage class specifiers to appear in compound literal definition: sympatoche

En résumé, sympatoche, mais manquant de killer feature forcant son usage. Et ils n'ont pas corrigé la m***e que sont les locales en C.

Mon avis sur le C++23:

* trop, trop, trop de features.

Nous sommes d'accord qu'Il y a un certain nombre de morceaux de la librairie standard C++ qui ne sont pas adaptés à l'embarqué très contraint, rien n'a changé sur ce point depuis longtemps. Mais c'est plutôt une caractéristique de la librairie standard C++ et de ses implémentations, qu'une caractéristique du langage lui-même.
A choisir entre C23 et C++23 pour produire du nouveau code sur plate-formes embarquées, je choisirais clairement C++23. La pléthore de features de C++ est de plus en plus énorme, c'est un fait, mais il n'y a pas grand chose qu'on soit obligés d'utiliser
Pour des raisons de réduction des bugs et/ou d'amélioration de l'efficacité du code généré, j'ai déjà utilisé des éléments de C++, pas forcément récents d'ailleurs, qui ne sont pas en C à ma connaissance: citons le typage plus strict, RAII (pour les locks, en particulier), constexpr normal (et maintenant consteval, if constexpr, if consteval, avec lesquels je n'ai pas eu l'occasion de jouer) pour déplacer des calculs et/ou des vérifications en temps de compilation, rvalue references / std::move et tout ce qui y est associé (efficacité), unique_ptr (réduction des bugs), un peu de métaprogrammation à base de type traits plus avancée que le _Generic de C ne le permet (efficacité du code généré). Et il y a des choses que je n'ai pas eu l'occasion d'utiliser mais qui peuvent être utilisées pour réduire les bugs dans certaines conditions, comme les concepts.

Si tes préoccupations sont au niveau de la réduction des bugs, je penses que Rust est plus intéressant que C++ pour produire du nouveau code.
Le typage est autrement plus strict. La plupart des fonctionnalités que tu cites sont bien mieux intégrées car le langage a été de base prévu pour. Il est juste moins avancé pour le moment au niveau du const (l'équivalent du constexpr).

Lionel Debroux (./5214) :
La pléthore de features de C++ est de plus en plus énorme, c'est un fait, mais il n'y a pas grand chose qu'on soit obligés d'utiliser

C'est bien çà le problème.
Si tu te mets coté relecteur de code, le C++ est une purge à relire et à valider. Trop de features, trop de détails subtils impossible à cerner lors d'une PR, impossibilité de maîtriser le langage. Et tu peux être sûr que personne ne serra d'accord sur un sous ensemble de feature à utiliser dans ton projet. Ensuite c'est juste mon avis. Rien de plus.

(Mon dieu, PpHd est vivant!)

PpHd (./5213) :
Et ils n'ont pas corrigé la m***e que sont les locales en C.

ça malheureusement ça ne sera jamais corrigé, et même en C++ ça nous tire dans les pattes sauf que c'est encore moins visible.

De ce que je vois ça a l'air d'être grosso merdo un backport de certains trucs ajoutés au C++ (mais pas que).

PpHd (./5216) :
le C++ est une purge à relire et à valider

et ; ça peut rester vachement simple, tout de même. Evidemment, une usine à gaz de templates donnera une migraine à n'importe qui (y compris l'auteur, 3 mois après), mais de l'autre main le fait qu'on s'inquiète quand même vachement moins de façon générale est imho agréable.

Uther (./5215) :
je penses que Rust est plus intéressant que C++

Pour avoir fait du Rust, je trouve que le borrow checker est bien en théorie mais insupportable en pratique, les lifetime polluent tout du moment qu'on veut rester safe, et du coup on se retrouve à écrire de l'unsafe rust, et donc à ne pas bénéficier du borrow checker. Et en plus on peut gagner en performance à faire de l'unsafe rust. Pourquoi s'emmerder du coup?

C'est vrai que le borrow checker peut être chiant, surtout quand on débute, mais c'est le prix a payer pour être sûr de pas faire de bêtises. Les lifetime avec l'habitude ça me dérange pas : il faut voir ça comme la documentation qu'on devrait produire en C pour que le code soit bien utilisé, sauf qu'on est obligé de la produire et l'utilisateur sera obligé de la respecter.
Les cas où on a vraiment besoin de l'unsafe pour améliorer les performances sont plutôt rares, et même quand c'est le cas ça n'est pas si grave car le code à risque est limité aux blocs unsafe qui sont très rares dans un code normal. Le but est que l'on ne puisse pas faire quelque-chose de dangereux par mégarde. Quand on doit utiliser un bloc unsafe, on est conscient qu'on va devoir être particulièrement prudent, et le relecteur aussi.

Plus sérieux (quoi que ?) :

Hidden Unicode characters like bidirectional text markers and zero-width joiners can be used to obfuscate malicious instructions in the user interface and in GitHub pull requests, the researchers noted.

(...)

Once the poisoned rules file is imported to GitHub Copilot or Cursor, the AI agent will read and follow the attacker’s instructions while assisting the victim’s future coding projects.

In an example demonstrated by Pillar, a rules file that appeared to instruct the AI to “Follow HTML5 best practices” included hidden text containing further instructions to add an external script to the end of every file.

The hidden prompt also included a jailbreak to bypass potential security checks, ensuring the AI that adding the script was necessary to secure the project and was part of company policy, as well as instructions to not mention the addition of the script in any responses to the user.

Zerosquare (./5219) :

GitHub - snoack/python-goto: A function decorator, that rewrites the bytecode, to enable goto in PythonGitHubA function decorator, that rewrites the bytecode, to enable goto in Python - snoack/python-goto

Il va se faire des amis lui