Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ Notation hongroise

Notation hongroise

22 réponses
Avatar
JBB
Y en a t'il parmi vous ( à part Microsoft) qui utilisent encore la
notation hongroise?

Rq: pour ceux qui connaissent pas ça consiste à faire des chose du genre:

class CMaClasse{

int m_iNombre;
long * m_plPointeur;

voif f()
{
char tcTexte[100];
}
};
au lieu de
class MaClasse{

int Nombre;
long * Pointeur;

voif f()
{
char Texte[100];
}
};
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3
Avatar
Fabien LE LEZ
On Mon, 24 Oct 2005 15:14:14 +0200, JBB :

Y en a t'il parmi vous ( à part Microsoft) qui utilisent encore la
notation hongroise?


Rectification : même Microsoft l'a abandonné.

Note qu'au départ, c'était une bonne idée, qui a été détournée pour en
faire un truc assez stupide :
http://www.joelonsoftware.com/articles/Wrong.html

Avatar
JBB
Fabien LE LEZ wrote:
On Mon, 24 Oct 2005 15:14:14 +0200, JBB :

Y en a t'il parmi vous ( à part Microsoft) qui utilisent encore la
notation hongroise?


Rectification : même Microsoft l'a abandonné.

Note qu'au départ, c'était une bonne idée, qui a été détournée pour en
faire un truc assez stupide :
http://www.joelonsoftware.com/articles/Wrong.html

Je note au passage dasn l'article (rapport au sujet précédent):

Don’t use macros to create your own personal programming language.


Avatar
Traquila
En quelque sorte oui, même si c'est pas la notation d'origine, il y a des
similitudes dans les règles de codage que j'utilise comme par exemple :
Les variables membres commencent par _
Les variables finissent par _type

Exemples :
_mainColor_ui16 ---> représente une variable membre de type <unsigned short

colorValues_at ---> variable locale de type <pointeur de structure>


Point négatif : C'est assez lourd si on veut changer de type, on doit tout
renommer :-/
Point positif : Ca permet d'itentifier bien plus rapidement les variables,
leurs limites et leur portées. Les CAST deviennent alors vraiment intuitifs.

Traquila


"JBB" wrote in message
news:435cde26$0$21213$
Y en a t'il parmi vous ( à part Microsoft) qui utilisent encore la
notation hongroise?

Rq: pour ceux qui connaissent pas ça consiste à faire des chose du genre:

class CMaClasse{

int m_iNombre;
long * m_plPointeur;

voif f()
{
char tcTexte[100];
}
};
au lieu de
class MaClasse{

int Nombre;
long * Pointeur;

voif f()
{
char Texte[100];
}
};


Avatar
Patrick 'Zener' Brunet
Bonjour.

Je réponds à JBB
Y en a t'il parmi vous ( à part Microsoft) qui utilisent encore la
notation hongroise?

Rq: pour ceux qui connaissent pas ça consiste à faire des chose du
genre:



Il y a eu une discussion récente ici qui a traité cette question: ça date de
début Août 2005, et le titre était "Recherche QCM C++ type SSII".

Mais donc avec ce type de question, vous partez sur le vieux problème des
goûts et des couleurs...

Pour vous répondre, je suis un fervent utilisateur de cette notation dite
"hongroise préfixée", mais seulement en l'ayant adaptée à mes besoins, car
effectivement le jeu de préfixes de l'éditeur cité est complètement
incohérent et bourré d'archaïsmes.

Je me suis donc doté d'une typologie complète et du jeu cohérent de préfixes
qui va avec, et dans ces conditions, ça devient avantageux par rapport à mon
mode de travail. Au-delà de C/C++, je l'applique en JavaScript, en XHTML,
en SQL, en PHP, DOS, bref partout où les identifiants ne sont pas imposés.

Donc les pincettes sont de mise, mais même sans notation HP, en 15 ans
d'expérience, j'ai pu constater que quelle que soit la stratégie envisagée,
décider d'un protocole de codage satisfaisant toute l'équipe reste toujours
un défi en soi, et ensuite s'y conformer reste toujours un élément de
frustration, surtout pour les passionnés (2/3 experts, 1/3 puristes et
esthètes) qui n'en ont ***pas*** rien à f...

AMHA c'est la raison pour laquelle ce type de concepteur aime bien les
reformateurs et générateurs de code paramétrables, ainsi que les techniques
de conception modulaire permettant de livrer des modules autonomes, plutôt
que de forcer les développeurs à bricoler à tour de rôle dans les mêmes
fichiers.

Cela dit, mon premier chef avait une vision des choses digne d'un
compilateur : l'indentation et la syntaxe des identifiants n'avaient aucun
intérêt pour lui, il relisait son propre code linéairement pour le
comprendre, et le modifiait itérativement jusqu'au résultat voulu.

Je ne résiste pas à l'envie de vous en mettre un aperçu:

<kk_code>====================
if (tag[i] == 'F')
{
if (tag[i+1] != typ) LIBERE_AND_EXIT(TYPES_DIF)
if (typ == 'I') val[i] = val[i + 1]; /*on ecrase le val
correspondant
au 'F' (tableau contigu): on s'en moque car le terme est uniqt en
input*/
else if (typ == 'S')
{
if (myzone_int+2 >= tab_size) LIBERE_AND_EXIT(INSUF_ALLOC)
val[myzone_int++] = (EntierMot) (&(str[val[i+1]]));
val[myzone_int] = 0; /*fin des chaines*/
}
}
if (typ == 'I') *ptr_arg++ = (EntierMot) &(val[deb_liste]); /*adresse
du tableau*/
else if (typ == 'S') {myzone_int++;*ptr_arg++ = (EntierMot) &(val[savint]);}
else *ptr_arg++ = (EntierMot) &(rel[val[deb_liste]]);
/*on suppose que les reels sont ranges de maniere contigue*/
break;
case 'S':
*ptr_arg++ = (EntierMot) &(str[val[ind_tag]]);
break;
case 'T': /******************* OUTPUT****************************/
if (val[val[ind_tag]] < 2) LIBERE_AND_EXIT(ALMOST_DOUBLE)
if (val[val[ind_tag]] == 2 && tag[val[ind_tag]+1] == 'S' &&
strlen(&(str[val[val[ind_tag] + 1]])) == 1 )
typ = str[val[val[ind_tag] + 1]];
/*type de l'ouput (entier,
reel,chaine,tableau)*/
else typ = tag[val[ind_tag]+1];
/**if (tag[val[ind_tag]+2] != 'V' && tag[val[ind_tag]+2] != typ)
LIBERE_AND_EXIT(INCOMPATIBLE_TYPE) fait un echec**/
switch (typ)
{
case 'I': /*<"I",V> ou <int,V>*/
if (tag[val[ind_tag] + 1] != 'S')
val[val[ind_tag]+2] = val[val[ind_tag] + 1];
/*copie de l'input dans l'output*/
*ptr_arg++ = (EntierMot) &(val[val[ind_tag]+2]);
break;
case 'R':
case 'X': /*<"R",V> ou <reel,V>*/
if (tag[val[ind_tag] + 1] != 'S')
...
===================</kk_code>

A vos souhaits !!!!! Et il y en avait des Mo comme ça...

Vous avez déjà deviné que c'est un Unixien, et cette "efficacité" l'amusait
beaucoup. Il manifestait toujours beaucoup de satisfaction quand il avait
réussi à recomprendre un de ses trucs subtils. Il ne me restait alors plus
qu'à faire marcher le résultat sous Windows 3 vite et sans anomalies...

Après un tel traumatisme, vous me pardonnerez d'aimer le code un minimum
esthétique (en plus de la propriété de marcher bien sûr !!!).

Mais donc ça reste une histoire de goûts, et accessoirement de respect des
collègues :-)

Cordialement,

--
/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/

Avatar
Fabien LE LEZ
On Tue, 25 Oct 2005 10:57:19 +0200, "Patrick 'Zener' Brunet" :

===================</kk_code>

A vos souhaits !!!!! Et il y en avait des Mo comme ça...


Qu'est-ce qui te gêne là-dedans ? Du code comme ça, il y en a plein
sur le site de l'IOCCC...

Avatar
Marc Boyer
Fabien LE LEZ a écrit :
On Mon, 24 Oct 2005 15:14:14 +0200, JBB :
Y en a t'il parmi vous ( à part Microsoft) qui utilisent encore la
notation hongroise?


Rectification : même Microsoft l'a abandonné.

Note qu'au départ, c'était une bonne idée, qui a été détournée pour en
faire un truc assez stupide :
http://www.joelonsoftware.com/articles/Wrong.html


Ce qui me fortifie dans cette vieille marote de pouvoir
définir de nouveaux types à partir d'anciens en controlant
les conversions et rapidement.
Ca se fait a peut prêt en C++ avec l'héritage, mais
pas trop sur les types de base.

Un vieux débat sur les double, les kilos, et les
kilos de pommes...

Marc Boyer
--
À vélo, prendre une rue à contre-sens est moins dangereux
que prendre un boulevard dans le sens légal. À qui la faute ?


Avatar
Jean-Marc Bourguet
Marc Boyer writes:

Ce qui me fortifie dans cette vieille marote de pouvoir
définir de nouveaux types à partir d'anciens en controlant
les conversions et rapidement.


La seule proposition que j'avais reellement a coeur de pouvoir faire
pour la prochaine revision de la norme etait un typedef introduisant
un nouveau type. Malheureusement, plus j'ai plonge dans les details
de la chose, moins ca m'a semble possible de maniere saine.

Un probleme fondamental que je ne suis pas arrive a resoudre, c'est de
savoir quelles operations seraient disponibles (quels seraient
l'equivalent des operations primitives d'Ada autrement dit); la piste
la plus interessante est de se baser sur la recherche des noms
dependants; mais d'une part ca trouve souvent beaucoup trop et d'autre
part l'extension de ca a ce qui est defini dans le namespace global et
aux types de base forcent a l'ecriture de regles particulieres d'une
complexite dont parfois j'ai honte de l'avoir envisagee.

J'ai donc abandonne la tache.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Avatar
Fabien LE LEZ
On 25 Oct 2005 11:55:35 +0200, Jean-Marc Bourguet :

La seule proposition que j'avais reellement a coeur de pouvoir faire
pour la prochaine revision de la norme etait un typedef introduisant
un nouveau type.


C'est vrai que ce serait très agréable...

Malheureusement, plus j'ai plonge dans les details
de la chose, moins ca m'a semble possible de maniere saine.


J'avais pensé à appliquer grosso modo les mêmes règles que pour
l'héritage (i.e. on "fait comme si" T hérite de U et U hérite de T),
mais j'avoue manquer de vision d'ensemble pour m'apercevoir de tous
les problèmes.

Avatar
Jean-Marc Bourguet
Fabien LE LEZ writes:

On 25 Oct 2005 11:55:35 +0200, Jean-Marc Bourguet :

La seule proposition que j'avais reellement a coeur de pouvoir faire
pour la prochaine revision de la norme etait un typedef introduisant
un nouveau type.


C'est vrai que ce serait très agréable...

Malheureusement, plus j'ai plonge dans les details
de la chose, moins ca m'a semble possible de maniere saine.


J'avais pensé à appliquer grosso modo les mêmes règles que pour
l'héritage (i.e. on "fait comme si" T hérite de U et U hérite de T),
mais j'avoue manquer de vision d'ensemble pour m'apercevoir de tous
les problèmes.


Un des objectifs d'un typedef fort est justement de ne pas pouvoir
utiliser un type pour l'autre.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org


Avatar
Marc Boyer
Le 25-10-2005, Jean-Marc Bourguet a écrit :
Marc Boyer writes:

Ce qui me fortifie dans cette vieille marote de pouvoir
définir de nouveaux types à partir d'anciens en controlant
les conversions et rapidement.


La seule proposition que j'avais reellement a coeur de pouvoir faire
pour la prochaine revision de la norme etait un typedef introduisant
un nouveau type. Malheureusement, plus j'ai plonge dans les details
de la chose, moins ca m'a semble possible de maniere saine.


Je pense bien.

Un probleme fondamental que je ne suis pas arrive a resoudre, c'est de
savoir quelles operations seraient disponibles (quels seraient
l'equivalent des operations primitives d'Ada autrement dit);


En plus, AMHA, ce doit être configurable par l'utilisateur.
Enfin, je dis ça parce que je ne suis pas capable de dire
quelles seraient les utilisations pertinentes.
J'ai ma propre idée pour mes besoins propres, mais
de là à dire que c'est l'unique solution.

la piste
la plus interessante est de se baser sur la recherche des noms
dependants; mais d'une part ca trouve souvent beaucoup trop et d'autre
part l'extension de ca a ce qui est defini dans le namespace global et
aux types de base forcent a l'ecriture de regles particulieres d'une
complexite dont parfois j'ai honte de l'avoir envisagee.


Oulà, ça devient technique pour moi.

Marc Boyer
--
À vélo, prendre une rue à contre-sens est moins dangereux
que prendre un boulevard dans le sens légal. À qui la faute ?


1 2 3