Le topic de la programmation: Et envoyez des sioux!

[Orhin]

Normal c'est un langage de noob.

[vectra]

Des jeux en Python 2.0 et en Java, il a bon dos le Bundle. C'est le pilon numérique qu'ils méritent...

[ducon]

Même pygame est passé à Python 3.

[Mechaick]

Bien le bonjour a tous !

J'aimerais programmer un petit jeu en 2d vue de dessus (disons dans un style the escapist ou rimworld).
J'avais commencé l'année dernière à apprendre le C++ pour cela. Cependant mon programme traînait et avec l'arrivée d'une deuxième année de Prépa, je n'avais plus la tête a ça.
Maintenant que tout ça est fini, j'ai décidé de m'y remettre et sur Unity cette fois. Pensez vous que c'est une bonne idée ? et quels tuto me recommanderiez vous pour mon projet ?

Je vous remercie.

[Frypolar]

Salut, il y a un sous-forum pour les développeurs de jeu vidéo : https://forum.canardpc.com/forums/13...3%A9veloppeurs En complément de celui-ci tu devrais trouver plein d’aide et de retours

[Mechaick]

Merci beaucoup !

[war-p]

Bien le bonjour a tous !

J'aimerais programmer un petit jeu en 2d vue de dessus (disons dans un style the escapist ou rimworld).
J'avais commencé l'année dernière à apprendre le C++ pour cela. Cependant mon programme traînait et avec l'arrivée d'une deuxième année de Prépa, je n'avais plus la tête a ça.
Maintenant que tout ça est fini, j'ai décidé de m'y remettre et sur Unity cette fois. Pensez vous que c'est une bonne idée ? et quels tuto me recommanderiez vous pour mon projet ?

Je vous remercie.

Tu dis que t'avais commencé à faire du c++?
Pourquoi tu partirais pas sur de l'unreal engine ? C'est peut être un peu overkill, mais c'est tout en c++.

[TwinBis]

*un tout petit peu*

[vectra]

Par contre, j'ai un problème sous CLion.

Je n'arrive définitivement pas à MAJ mon CMakeLists.txt et à le faire prendre en compte par CLion. Il m'oublie systématiquement les nouveaux exécutables, alors que le lancement de cmake par le terminal fonctionne parfaitement
J'ai essayé de cliquer sur les petites icônes du mode CMake, genre purge et tout, mais ça fait rien...

[Tramb]

Par contre, j'ai un problème sous CLion.

Je n'arrive définitivement pas à MAJ mon CMakeLists.txt et à le faire prendre en compte par CLion. Il m'oublie systématiquement les nouveaux exécutables, alors que le lancement de cmake par le terminal fonctionne parfaitement
J'ai essayé de cliquer sur les petites icônes du mode CMake, genre purge et tout, mais ça fait rien...

Essaie avec QtCreator, pour voir si ça fonctionne mieux.

[TarteAuxFleurs]

Par contre, j'ai un problème sous CLion.

Je n'arrive définitivement pas à MAJ mon CMakeLists.txt et à le faire prendre en compte par CLion. Il m'oublie systématiquement les nouveaux exécutables, alors que le lancement de cmake par le terminal fonctionne parfaitement
J'ai essayé de cliquer sur les petites icônes du mode CMake, genre purge et tout, mais ça fait rien...

Normalement quand tu modifies ton CMake il faut faire un "reload project" mais il y aune feature pour le faire automatiquement

[vectra]

Essaie avec QtCreator, pour voir si ça fonctionne mieux.

Sans oublier spacemacs
Je l'ai lancé juste pour voir: c'est quand-même stylé.

[Tramb]

Sans oublier spacemacs
Je l'ai lancé juste pour voir: c'est quand-même stylé.

Ils (Qtcreator) ont choisi CMake comme format de projet, c'est pour ça que je te suggère ça.

[vectra]

Ah désolé, je savais pas si c'était une blague hermétique en rapport avec le titre ou si c'était sérieux
Par contre, la dernière édition de Visual s'est mise au CMake également. Ils peuvent importer le projet directement, et il n'est donc plus nécessaire de générer un projet Visual à partir de CMake (ce qui était une chouette performance, cela dit).

[William Vaurien]

Question pour les 'dieux du C':

le code du projet en cours est du code issue du protozoaire.
Avant il était compilé sur des serveurs unix HP puis SUN.

Il se compile maintenant avec gcc -ansi.
Sauf que pour la migration vers Linux nous avons du rajouter des flags (notamment POSIX et GNU_SOURCE).
Migration qui a coïncidée avec mon arrivée, et j'ai été un peu en roue libre depuis: un collègue ma filé son K&R illustré vintage (1987) et m'a dit démerde toi.

J'ai sans trop faire gaffe utilisé des idiomes qui oscillent entre du C 99 et du C GNU:
- déclaration et assignation des variables sur une seule ligne et n'importe où dans la fonction (au plus près de l'utilisation)
- pas de prototype des functions static en tête du fichier source
- utilisation des varargs et des v[x]printf
- init de tableaux avec taille dynamique
- sûrement tout un tas d'autres horreurs qui rendraient chauve un adepte du C89

Mine de rien tous ces petits trucs rendent le code plus lisible, plus compacte et plus maintenable (pour mes yeux et mon cerveau endommagé par des années de Java).

Maintenant je commence à lorgner sur les nested fonctions:

qui permettent de faire une sorte d'encapsulation dans le cadre d'un code utilisant beaucoup de callback 'locaux' sous forme de pointeurs de fonctions:

schématiquement:

void genericFunction(Callback callback) {
 
  //fait des trucs génériques
  
  callback();
  
  //fait des trucs génériques

}

/*Sans nested fonction*/
void callbackA() {...}
int clientEntryPointA() { genericFunction(callbackA); }

/*Avec nested fonction*/
int clientEntryPointB() { 
  int toto=0+0;
  void callbackB() {
     //accès aux variables déclarées dans clientEntryPointB: 
     //très pratique pour éviter de faire des contorsions pour avoid accès au contexte de la fonction parent
     if(toto) {...}
  }
  genericFunction(callbackB); 
} 

Mais je commence à avoir quelques scrupules: le code n'est plus ANSI même si en même temps il est GNU...
A priori il n'y aura plus de changement majeur d'OS: terminé les serveurs proprio et hors de prix.
Les binaires s'exécutent uniquement sur le même type d'infra: dev sur Linux, exécution sur Linux. Il n'y a aucune raison de vouloir rendre ce code portable.

Quelles sont les risques de basculer des parties du code hors des normes C et d'utiliser des features non standards ?
Je trouve amusant de voir la tête de mes collègues vintages voir du C qu'il ne comprenne pas vraiment (c'est pas le but de les faire chier, mais ça reste drôle quand même : je suis à leurs yeux le petit junior et eux les grands manitous...), mais je n'ai pas non plus envie d'entasser des problèmes sans trop m'en rendre compte.

[Tramb]

A priori il n'y aura plus de changement majeur d'OS: terminé les serveurs proprio et hors de prix.
Les binaires s'exécutent uniquement sur le même type d'infra: dev sur Linux, exécution sur Linux. Il n'y a aucune raison de vouloir rendre ce code portable.

Non, non, et non.
Il n'y a aucune raison *aujourd'hui*. Si tu savais le nombre de fois où j'ai entendu ça et les suppositions ont été brisées 1, 3, 5 ou 10 ans plus tard....
Ne sacrifie pas trop la portabilité pour pas grand chose.
D'ailleurs certains de tes problèmes aujourd'hui viennent un peu de ce genre de raisonnements dans le passé

- - - Mise à jour - - -

PS: Pour ce cas précis, tu vas faire chier toute personne qui essaierait de le porter en C++ plus tard.

[William Vaurien]

Il n'y aura jamais de portage C++. Certifié 100%: il n'y a aucune compétence c++, ni dans l'équipe ni dans l'entreprise et ce n'est absolument pas dans la stratégie long terme.

La stratégie actuelle c'est de migrer l'existant progressivement vers du Java (langage officiel pour le reste des dev de l'entreprise).
En gros le programme actuel devrait 'fondre' doucement pendant une dizaine d'année.


Après je ne suis sûr de rien au niveau de l'OS qui fera tourner l'appli dans 10 ans (pas Windows, c'est sûr !).
Effectivement là j'ai un peu peur.
Maintenant gcc est (et devrait rester) dispo dans les décennies à venir.
Est-ce que du code GNU style devient non-portable pour le coup ?

Ce qui est certain c'est que le code est de l'applicatif 'de gestion'. Il ne tournera jamais sur des micro-contrôleurs embarqués ou des OS exotiques...

Quels sont vraiment les risques ? Je trouve un peu con de rester bloqué sur un style de programmation très rudimentaire, mais j'ai pas non plus envie de me planter.

Pour poser autrement la question: quand est-il sûr d'utiliser les extensions gcc ?

[Cwningen]

- init de tableaux avec taille dynamique

Tu parles des tableaux de taille variable dans la pile ? Il y a un qui m'a mordu un jour, depuis je ne les aime pas. C'est à éviter si le tableau peut être gros.

[William Vaurien]

Tu parles des tableaux de taille variable dans la pile ? Il y a un qui m'a mordu un jour, depuis je ne les aime pas. C'est à éviter si le tableau peut être gros.

Bon ce truc là je ne l'ai pas utilisé souvent (1 fois en fait) et pour un petit truc.
C'est quoi le risque ? de faire péter la pile en y réservant un énorme espace mémoire ?

Les fonctions imbriquées je peux m'en passer aussi, mais ça réduit un peu les tours de passe-passe nécessaire dans certaines conditions.

Après je ne vais pas non plus me mettre à utiliser toutes les extensions de gcc...
Celles qui m'intéressent principalement sont les points suivant:
- déclaration et assignation des variables sur une seule ligne et n'importe où dans la fonction (au plus près de l'utilisation)
- pas de prototype des functions static en tête du fichier source
- utilisation des varargs et des v[x]printf

[Cwningen]

C'est ça, il y a généralement moins de place dans la pile que dans le tas. Et tu ne peux même pas savoir si l'allocation a échouée.

Celles qui m'intéressent principalement sont les points suivant:
- déclaration et assignation des variables sur une seule ligne et n'importe où dans la fonction (au plus près de l'utilisation)
- pas de prototype des functions static en tête du fichier source
- utilisation des varargs et des v[x]printf

Il me semble que tout ça est standard. Les deux premiers sont surtout une question de style. Les varargs peuvent être dangereux puisqu'il n'y a pas de vérification du type. Si tu utilises les extensions GNU et que c'est pour passer à des v*printf à la fin, il y a un attribut "format" qui permet d'avoir les mêmes avertissements que *printf.

[William Vaurien]

ok, bon je vire cette 'feature' de mon esprit

[Tramb]

D'ici à ce que ça finisse en emscripten pour encore 20 piges ton truc ^^
Et oui les tableaux de taille non-constante sur la stack c'est du sucre pour alloca, et c'est plutôt dangereux. Mais très utile.

[vectra]

Ca vient d'où, ce besoin de passer par la pile?

Je croyais que c'était une histoire de convenience dans la déclaration du tableau. Dans lequel cas, autant faire une macro qui masque un bon calloc des familles.
(Tu peux même prendre une version SSE pour aligner le tableau en mémoire: quitte à faire du bas niveau, autant le faire utilement )

[Tramb]

La lifetime est très claire sur une allocation sur la pile, ça meurt en sortant du scope.
Allouer sur un heap, ça nécessite du boulot, c'est long.
Sur la pile, c'est juste ajuster un registre, c'est incomparablement plus rapide.
Quand tu alloues/désalloues souvent, ça change tout niveau perf !

[TiNitro]

voilà.

[vectra]

Rah purée, sur CLion, j'ai des commits qui passent pas
Je demande une vérif du code et ça passe crème en général. Là, j'ai intégré des exemples sortis par un mec qu'est un cador mais qui code avec ses pieds (de cador), et ça passe simplement pas de chez pas.
Le truc tourne en boucle, forever.

Alors OK, je peux désactiver la vérification de code pour ce commit, mais enfin zut quoi.

[war-p]

Rah purée, sur CLion, j'ai des commits qui passent pas
Je demande une vérif du code et ça passe crème en général. Là, j'ai intégré des exemples sortis par un mec qu'est un cador mais qui code avec ses pieds (de cador), et ça passe simplement pas de chez pas.
Le truc tourne en boucle, forever.

Alors OK, je peux désactiver la vérification de code pour ce commit, mais enfin zut quoi.

C'est donc pas un cador, non? Sinon vous avez un bon IDE pour lua?

[vectra]

Le mec est plutôt célèbre dans le landerneau, mais je trouve que pas mal de ses codes sont pour le moins discutables.

[Nattefrost]

C'est donc pas un cador, non? Sinon vous avez un bon IDE pour lua?

ZeroBrane Studio. Sinon VSCode avec le plugin Lua ça fait le job.

[William Vaurien]

Oui, mais est-ce qu'il les imprime ses codes discutables ?