c++, la grosse désillusion

[Schimz]

Concernant Orbiter, le plus simple amha, c'est de développer un vaisseau à partir du SDK en restant dans le même style.
Par exemple faire un Eagle de Cosmos1999 à partir de la shuttleA ou un DGex à partir du DG.

[vinka]

Mustard wrote:
Le problème c'est que y aller très progressivement en plusieurs années c'est un peu trop long. je ne suis pas certain
qu'Orbiter durent encore de longues années.
J'avais une toute petite expérience en Pascal et en Vusal basique mais là je dois avouer que le C++ m'a refroidi.

Vinka, pendant un temps tu m'avais parlé d'un nouveau module avec plus de fonction, l'as tu abandonné ?

Tout dépend de la définition d'abandonner ... c'est pas l'envie qui me manque, c'est le temps !

[MartySpaceLines]

Hey Mustard!

Faut pas se décourager! Moi j'ai commencé le C++ lorsque j'avais 13 ans, à partir de ce tutoriel:

http://www.siteduzero.com/tutoriel-3-11406-apprenez-a-programmer-en-c.html

Il demande une connaissance des bases du C, mais c'est en fait la suite d'un autre tutoriel sur le C:

http://www.siteduzero.com/tutoriel-3-14189-apprenez-a-programmer-en-c.html

Ces tutos, en combinaison avec les exemples de la SDK, sont je pense une voie royale pour faire des add-ons sous Orbiter
(c'est ce que j'ai suivi...et même si j'ai pas encore posté de nouvelles images de Gemini, je peux vous dire que chez-moi ca
marche pas mal!)

Allez, courage!

[Drenake]

Bonsoir M. Mustard

J'ai commencé le c++ il y a environs 2 semaine et je n'y connaissait rien !

Le secret, c'est de commencer par quelque chose de SIMPLE. Personnellement, j'ai commencé par les tutos de Dan et le
shuttlePB. Une fois que ça compile (Dan donne toutes les étape dans le cas du PB), tu lis le code et essais de voir quel
fonction fais quoi. Le noms des fonction est généralement assez explicite.

Bref, après environs 5 heures à regarder des codes (réparti sur 2 semaine quand même...), j'ai converti un addon Spacecraft3
en dll avec les animation et tout.

Tout est possible, et dans le cas du c++, ça prend 3 ingrédients: De la patience, de la volonté et, comme l'explique si bien
Dan dans ses tutos, une bonne méthode!

Sur ce, Bonne chance !

[DanSteph]

Ca fait plaisir de voir des gens qui ce lancent, merci pour ce feedback Drenake.

Dan

[tofitouf]

C'est clair. Très bonne descruiption de ce qui est néccéssaire : patience et volonté. sinon coté méthode, je pense que si un
prof regardais comment je m'y prends il serait effrayé par tant de chaos. Mais au final j'y arrive, alors tant pis pour la
méthode. Quand je me relis j'ai des fois des surprises hallucinantes



Message modifié ( 06-11-2009 11:18 )

[DanSteph]

tofitouf a écrit:
C'est clair. Très bonne descruiptiond e ce qui est néccéssaire : patience et volonté. sinon coté méthode, je pense que si un
prof regardais comment je m'y prends il serait effrayé par tant de chaos. Mais au final j'y arrive, alors tan pis pour la
méthode. Quand je me relis j'ai des fois des surprises hallucinantes

Ah ouais, Le code du "vendredi"

Tu devrais voir le code du Arrow, on dirais des fois que c'est jeté n'importe comment (la bourre)

MAIS !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! (Cour gratos pour les débutants)

1-J'utilise une notation très "enfantine" et basique pas de ça chez moi:

Code: [Select]

if (gear_status >= AnimState::CLOSING) {
double da = simdt * GEAR_OPERATING_SPEED;
if (gear_status == AnimState::CLOSING) { // retract gear
if (gear_proc > 0.0) gear_proc = max (0.0, gear_proc-da);
else                 gear_status = AnimState::CLOSED;
} else {                           // deploy gear
if (gear_proc < 1.0) gear_proc = min (1.0, gear_proc+da);
else                 gear_status = AnimState::OPEN;
}
SetAnimation (anim_gear, gear_proc);
SetGearParameters (gear_proc);
}

Si y a une couille c'est pas lisible du tout au premier abord

Je prend beaucoup plus de place mais je garde la lisibilité:

Code: [Select]

// animate landing gear
if (Gear_status >= DOOR_CLOSING)
{
double da = dSimDT * 0.05;
if (Gear_status == DOOR_CLOSING)
{
if (Gear_Proc > 0.0)
{
Gear_Proc = max (0.0, Gear_Proc-da);
}
else
{
Gear_status = DOOR_CLOSED;
}
}
else
{ // door opening
if (Gear_Proc < 1.0)
{
Gear_Proc = min (1.0, Gear_Proc+da);
}
else
{
Gear_status = DOOR_OPEN;
}
}
SetAnimation (anim_Gear, 1-Gear_Proc);
if(Gear_status==DOOR_OPEN)
{
SetGearParameters (1.0);
strcpy(SendFocusScreenMessage(),"Gear down and locked");
}
else if(Gear_status==DOOR_CLOSED)
{
SetGearParameters (0.0);
strcpy(SendFocusScreenMessage(),"Gear are up and locked");
}
}

Ensuite JAMAIS de truc dans ce genre:

Code: [Select]

if (Gear_Proc < 1.0)
Gear_Proc = min (1.0, Gear_Proc+da);
else
Gear_status = DOOR_OPEN;

Ça marche, c'est nickel, mais un jour on est fatigué on rajoute une ligne et on s'arrache les cheveux pourquoi
ça marche pas ou on release un truc buggé.

Je fais ça, encore une notation de "débutant", mais c'est du "robuste" même si c'est vendredi.

Code: [Select]

if (Gear_Proc < 1.0)
{
Gear_Proc = min (1.0, Gear_Proc+da);
}
else
{
Gear_status = DOOR_OPEN;
}

Ensuite je suis absolument STRICT sur les noms de variables ou fonction.

Code: [Select]

// y a plus qu'a ce pendre si on veux relire ce genre de code:
int EuhCestQuelTypeDeja;
double JeSaisPlusAQuoiCaSert;
void AuSecourQueFaitCetteFonction(void);
bool Merde;
int U;

// la c'est clair: type fonction
int iCompteurNombreDeUMMUaBord;
double dAltitudeMoinsHauteurLandingGear;
void*    ptrPointeurVoidSurStructUMmu;


Enfin bref comme l'erreur est humaine je BLINDE au maximum mon code en gardant une LISIBILITE
absolue. RIEN ne justifie une notation confuse ou compact et surtout pas les performances, c'est
compilé pareil.

Voila vous pouvez vous graver ça dans la tête au fer rouge: la lisibilité c'est la CLE !

Le jour on je veux cleaner un peu mon code arrow je n'aurais aucune peine, c'est jeté un peu n'importe comment (surtout dans
le header) mais les noms et le code étant hyper lisible ça ce bouge facilement.

Dan

[tofitouf]

On a exactement les même principes. C'est drole

Cette méthode a un gros avantage : La lisibilité du code permet d'y retourner en toute situation. Si on a complètement oublié
ce qu'on a voulu faire. le noter comme l'a fait Dan suffit a s'y retrouver très rapidement.

Ca ne sert à rien de blinder son code de commentaire, le nom des variables et des fonctions a par contre une importance
capitale.
Vive les noms à rallonge qui décrive complètement ce que fait la fonctions.
éviter donc de modifier une fonction par commodité sans changer son nom si ce qu'elle fait évolue.
Idem pour les variables, Quand j'ai besoin de changer le comportement de tel ou tel tuc, souvent je commence par changer le
nom de ma variable, à la compilation j'ai alors la liste de tous les cas de test et d'affectation par les messages d'erreur,
ça me permet de relire rapidement ce qui est fait et donc de modifier en conséquence.

C'est très rapide et efficace. Il faut juste avoir le courage de changer tous les appels vers la fonction ou vers la
variable. mais cette méthode permet de ne jamais se perdre même quand le projet prends de l'ampleur.

Souvent au boulot j'ai des collèges qui rechignent à ce genre de choses alors que ca va leur prendre 10 ptites minutes et faire un bon nettoyage en passant.

Le bon nommage des fonction permet de lire du code comme si c'était des phrases de pseudo code. Si la fonction derrière fait
bien ce qu'elle décrit dans son nom (ni plus ni moins) alors plus besoin de débugagge compliqué, on évite en se relisant toutes les erreurs de comportement.

Aerer aussi en ajoutant des lignes par ci par là est très important notre oeil repère bien plus facilement ce qu'il y a d'important.

Les commentaire aussi sont important mais dans une moindre mesure.

Par exemple inutile de commenter une appel comme

this->reorganisationCompleteDesDonneeParOrdreCroissant();

Par contre cette ligne mérite un ptit commentaire

// si la distance à l'objectif est suffisamment petite
if (distance < minDistanceArea)
{
    // on a atteint la zone de sécurité. je commence à freiner
    m_pVessel->set.....





Je n'ai jamais compris les "soit disant bon codeurs" qui produisent du code compact et illisible. Ils se font une fierté de
faire sur une seul ligne des dizaines d'opérations. Au final ils se perdent eux même dans leur propre production.
leur seul mérite est souvent que personne ne pouvant les relire, ils se rendent indispensables.
J'ai vu beaucoup de gens sur le travail fonctionner comme ca. Semblant faire tout pour rendre leur code le plus illisible
possible de manière à ce que personne puisse le modifier sans leur accord.

ca dérive ce thread



Message modifié ( 06-11-2009 15:09 )

[DanSteph]

tofitouf a écrit:
Je n'ai jamais compris les "soit disant bon codeurs" qui produisent du code compact et illisible. Ils se font une
fierté de faire sur une seul ligne des dizaines d'opérations.

Clair, sur les forums C++ c'est bourré de type qui ce la pètent avec leurs notation pourrie et leurs mots savant, le problème
c'est qu'aucun d'entre eux n'a sorti de grosses applications. (ni même des petites souvent)

ca dérive ce thread

Bah non, on parle bien du C++ et c'est intéressant je pense même pour les débutants.
D'ailleurs avec tofitouf on fait des séances de dédicaces à la fin du fil

C'est qu'on est resté modeste en plus

(Nan en fait j'ai de la peine a comprendre qu'on trouve le C++ pour Orbiter impossible à apprendre, peut être c'est juste un manque de temps de patience ou de volontés !?)

Dan



Message modifié ( 06-11-2009 14:11 )

[Coussini]

J'en sais quelque chose mon Cher Mustard. C'est pour cela que je ne suis pas souvent présent sur le site de Dan. Mais mon coeur est avec vous.

Je suis heureusement chanceux d'avoir eu une formation en informatique mais dans un domaine tellement à des
années lumières.... La seule différence c'est que les fameuses instructions suivantes (je les connaissait)

-IF THEN ELSE.
-Boucle while.... for... Until....
-Le principe d'affectation....

ET CELA SE RÉSUME À CELA....

Je me bas actuellement pour conserver mon poste au travail, car il m'ont engagé sans connaissance en langage
orienté objet. Je leur ai expliqué dernièrement, à titre de comparaison... que je suis une personne venant de la lune
et que soudainement, je suis parachuté sur la terre. Je dois respiré de l'air, je vois qu'il y a de la vie, des arbres, des
autos, des maison.... je dois tout réaprendre.... l'orienté objet cela prend un certain temps.... mais on arrive avec de
la persévérence. Mais mes patrons veulent des résultats.... et c'est frustrant parfois... il faut que je travaille plus fort
que mes autres collègue.

-BON SANG QUE J'EN AI RAMÉ.... MAIS JE COMMENCE À POSER MOIN DE QUESTION AU GENS DE MON ENTOURAGE

IL EXISTE DES FORMATIONS GRATUITE SUR LE NET QUI SONT FORMIDABLE....


Voici les liens:

(1-C'ÉTAIS PAR LÀ QUE J'AI DÉBUTÉ ET C'EST TRÈS BIEN )
http://www.siteduzero.com/

(2-SUPERBE COURS POUR APPRENDRE ENTRE AUTRE L'INTERFACE VISUAL STUDIO vc++)
http://msdn.microsoft.com/fr-fr/visualc/bb737992.aspx

(3-SUPERBE SITE QUI TOUCHE À TOUT)
http://www.developpez.com/

après cela tu sera un pro.... et tu comprendras ++  et encore ++



Message modifié ( 06-11-2009 15:12 )

[DagoO]

(1-C'ÉTAIS PAR LÀ QUE J'AI DÉBUTÉ ET C'EST TRÈS BIEN )
http://www.siteduzero.com/

Dansteph :
Faut pas du tout apprendre le C++ mais juste comment marche le "gros batch" orbiter avec ces us et coutumes.

Cerise sur le gâteaux: effectivement vous apprendrez de fait le C++.

Ah d'accord...

[Coussini]

DagoO a écrit:

(1-C'ÉTAIS PAR LÀ QUE J'AI DÉBUTÉ ET C'EST TRÈS BIEN )
http://www.siteduzero.com/

Dansteph :
Faut pas du tout apprendre le C++ mais juste comment marche le "gros batch" orbiter avec ces us et
coutumes.

Cerise sur le gâteaux: effectivement vous apprendrez de fait le C++.

Ah d'accord...

Pas d'accord dans mon contexte, car c'est pour mon travail... et je soupçonne que c'est le cas de Mustard.

[DagoO]

Pas d'accord dans mon contexte, car c'est pour mon travail... et je soupçonne que c'est le cas de Mustard.

Oui c'est surtout un conseil pour celui qui ne veut programmer que pour orbiter.

[Coussini]

en effet.... j'avais compris 8)

[Coussini]

DanSteph a écrit:

tofitouf a écrit:
C'est clair. Très bonne descruiptiond e ce qui est néccéssaire : patience et volonté. sinon coté méthode, je pense que
si un
prof regardais comment je m'y prends il serait effrayé par tant de chaos. Mais au final j'y arrive, alors tan pis pour la
méthode. Quand je me relis j'ai des fois des surprises hallucinantes

Ah ouais, Le code du "vendredi"

Tu devrais voir le code du Arrow, on dirais des fois que c'est jeté n'importe comment (la bourre)

MAIS !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! (Cour gratos pour les débutants)

1-J'utilise une notation très "enfantine" et basique pas de ça chez moi:

Code: [Select]

if (gear_status >= AnimState::CLOSING) {
double da = simdt * GEAR_OPERATING_SPEED;
if (gear_status == AnimState::CLOSING) { // retract gear
if (gear_proc > 0.0) gear_proc = max (0.0, gear_proc-da);
else                 gear_status = AnimState::CLOSED;
} else {                           // deploy gear
if (gear_proc < 1.0) gear_proc = min (1.0, gear_proc+da);
else                 gear_status = AnimState::OPEN;
}
SetAnimation (anim_gear, gear_proc);
SetGearParameters (gear_proc);
}

Si y a une couille c'est pas lisible du tout au premier abord

Je prend beaucoup plus de place mais je garde la lisibilité:

Code: [Select]

// animate landing gear
if (Gear_status >= DOOR_CLOSING)
{
double da = dSimDT * 0.05;
if (Gear_status == DOOR_CLOSING)
{
if (Gear_Proc > 0.0)
{
Gear_Proc = max (0.0, Gear_Proc-da);
}
else
{
Gear_status = DOOR_CLOSED;
}
}
else
{ // door opening
if (Gear_Proc < 1.0)
{
Gear_Proc = min (1.0, Gear_Proc+da);
}
else
{
Gear_status = DOOR_OPEN;
}
}
SetAnimation (anim_Gear, 1-Gear_Proc);
if(Gear_status==DOOR_OPEN)
{
SetGearParameters (1.0);
strcpy(SendFocusScreenMessage(),"Gear down and locked");
}
else if(Gear_status==DOOR_CLOSED)
{
SetGearParameters (0.0);
strcpy(SendFocusScreenMessage(),"Gear are up and locked");
}
}

Ensuite JAMAIS de truc dans ce genre:

Code: [Select]

if (Gear_Proc < 1.0)
Gear_Proc = min (1.0, Gear_Proc+da);
else
Gear_status = DOOR_OPEN;

Ça marche, c'est nickel, mais un jour on est fatigué on rajoute une ligne et on s'arrache les cheveux pourquoi
ça marche pas ou on release un truc buggé.

Je fais ça, encore une notation de "débutant", mais c'est du "robuste" même si c'est vendredi.

Code: [Select]

if (Gear_Proc < 1.0)
{
Gear_Proc = min (1.0, Gear_Proc+da);
}
else
{
Gear_status = DOOR_OPEN;
}

Ensuite je suis absolument STRICT sur les noms de variables ou fonction.

Code: [Select]

// y a plus qu'a ce pendre si on veux relire ce genre de code:
int EuhCestQuelTypeDeja;
double JeSaisPlusAQuoiCaSert;
void AuSecourQueFaitCetteFonction(void);
bool Merde;
int U;

// la c'est clair: type fonction
int iCompteurNombreDeUMMUaBord;
double dAltitudeMoinsHauteurLandingGear;
void*    ptrPointeurVoidSurStructUMmu;


Enfin bref comme l'erreur est humaine je BLINDE au maximum mon code en gardant une
LISIBILITE
absolue. RIEN ne justifie une notation confuse ou compact et surtout pas les performances,
c'est
compilé pareil.

Voila vous pouvez vous graver ça dans la tête au fer rouge: la lisibilité c'est la CLE !

Le jour on je veux cleaner un peu mon code arrow je n'aurais aucune peine, c'est jeté un peu n'importe comment
(surtout dans
le header) mais les noms et le code étant hyper lisible ça ce bouge facilement.

Dan

En passant, tu fais les choses impécablement.

L'indentation et la clarté de ton code est essentiel dans la compréhension d'un objet ou d'une classe. De toute façon,
Visual Studio fait son imbrication de paragraphe de cette manière lorsque tu utilises par exemple des objets ou des
contrôle du framework... mais là, je risque de perdre du monde....

[brainstorm]

Histoire de rassurer du monde, en ce qui me concerne, j'ai beau avoir réussi à développer des DLL pour orbiter en c++, je ne
serais pas foutu demain de développer quoi que ce soit en c++ pour autant.

La sdk de martin y est pour beaucoup. Et juste un peu de logique pour l'utilisation des méthodes / fonctions.
Pour ma part, je suis plutôt "spécialiste java" si j'ose dire ... c'est aussi de l'objet, mais d'un pt de vue différent.
Certes le C reste plus puissant, mais le java est moins lourd d'utilisation.

Bref, tout ça pour dire que des fois, la logique suffit, pas besoin d'être un programmeur chevronné pour y arriver. Juste de
la rigueur et de la logique ...

[DanSteph]

brainstorm a écrit:
Certes le C reste plus puissant, mais le java est moins lourd d'utilisation.

Question d'expérience je pense, je trouve le java imbitable perso.
Et comme je connais le grand frère aucune raison que je m'intéresse
à un truc plus limité pour faire la même chose.

Faut dire qu'au début il y a 20 ans j'ai testé des chiées de languages et chaque fois j'arrivais rapidement à la limite de
performance, ça ce mettais a ramer. Avec le C++ jamais eu ce problème.

Dan

[brainstorm]

Pour moi, c'est plutôt le C qui est imbitable lol Bon, disons que je le comprends, mais c'est toute ces notions de
pointeurs qui me collent dedans ... Pas ce soucis en java.

Et bon, vu que je le pratique depuis presque 10 ans, bon plus trop de secret pour moi. Autant dire que certains de mes
collègues/amis hallucinent de rien comprendre à ce que je code par rapport à l'état de leur connaissance dans ce langage.

Après je dirais que les goûts et les couleurs, hein ... Ceci dit, je ne dis pas fontaine, je ne boirais pas de ton eau, je
pense qu'un jour, je m'intéresserais très sérieusement au C++, quand je deviendrais limité par java tout du moins... pas
encore eu ce soucis pour le moment, encore moins en ce moment depuis que j'ai découvert JOGL ...

[Profil supprimé]

Merci pour ces encouragements mais j'ai fais une croix sur le C++. Il me faudrait il gros investissements temps que je
n'ai pas. J'avais espéré que cette formation me ferait gagné un temps fou mais il n'en fut rien.

[brainstorm]

Je dirais que rien ne t'empêche de récupérer du code d'un truc basique (si tu veux je peux te filer le code d'un zinc ou un
truc dans le genre) avec pas trop de truc complexe et bien documenté.
Après, en analysant le code, y'a moyen de pondre plein de choses intéressantes... A toi de voir après, je respecte ton point
de vue Ce ci dit, si tu veux des exemples de codes pas trop complexe, dis le moi

[siriusfett]

J'ai moi-même profité des exemples des autres, certes je ne suis pas devenu un crac, mais j'ai réussi quelque truc.
Tout comme brainstorm je suis aussi à ta disposition pour te faire parvenir mes codes.

[DanSteph]

Oui bon, l'investissement est pas si énorme mais un moment quand on a pas le temps ou pas énormément envie c'est sur que c'est mort... De Vinci n'a pas non plus peint mona lisa entre deux rendez-vous après un seul stage d'entreprises.

Par contre vu qu'on est dans le sujet, sur une partie "plus facile" en apparence, la modélisation, ca manque vraiment de
tutos. J'en vois pleins qui commencent avec des outils nases avec des méthode à vous dégouter de la modélisation (conversion de format, export)

Quand j'aurais un peu plus de temps courant 2010 j'espère faire un tuto sur gmax le petit frère de 3dsmax.
L'avantage c'est que c'est  l'outil est super bien et pratique et on a aucune limite car on peu passer facilement à 3dsmax
une fois qu'on connait gmax.

C'est encore une connaissance qui peut carrément servir professionnellement.

Dan



Message modifié ( 08-11-2009 14:36 )

[Dosage]

Impec dan, j'osais pas demander ...

[plin2bobo]

Mustard a écrit:
Merci pour ces encouragements mais j'ai fais une croix sur le C++. Il me faudrait il gros investissements temps que je
n'ai pas. J'avais espéré que cette formation me ferait gagné un temps fou mais il n'en fut rien.

euuuhhhhh....
mais....

[brainstorm]

<HS>
Pour infos, j'avais justement fait un ptit tutos sur métasequoia pour le D520 ...

http://orbiter.dansteph.com/forum/index.php?topic=6286.msg94383#msg94383
</HS>