Equivalent 'with' en C++? - Page 1

Hello ^^
Je me demandais s'il y avait un équivalent du bloc 'with' en C++, présent dans la plupart des langages objets tels que VB ou Java. Je n'ai rien trouvé à ce sujet, mais ça améliorerait bien la lisibilité du programme
Merci d'avance

Il n'y en a pas.

Disons qu'au mieux, tu peux trafiquer un truc avec des références :

Type& o = mon_objet_complique.avec_un_acces_a_un_champ;
o.fonction();
o += 2;

Brunni
: résent dans la plupart des langages objets tels que (...) Java.

Mmm ?

moui, je suppose qu'il veut parler du javascript

Java euh ca m'etonnerait par contre en pascal oue ca existe tout comme en vb comme tu le soulignes.

Je crois bien que ça existe aussi en C#, mais je n'en suis pas sûr.

Non, ça n'existe pas et c'est bien mieux comme ça. (D'autant plus que ça ne sert vraiment a rien )

Ok merci.
GC> Ha bon depuis quand ça sert à rien?

c'est carrément pratique oué...

GoldenCrystal :
Non, ça n'existe pas et c'est bien mieux comme ça. (D'autant plus que ça ne sert vraiment a rien )

hmm si y'a using ^^ (using (...) { })

Hmm non, using crée (ou au moins référence) un objet qui implémente l'interface IDisposable, pour appeller sa méthode Dispose a la fin du bloc... C'est pour utiliser un objet pendant un court temps, à la manière des for (int i = 0; i < n; i++) { /* code */ } où i n'existe ni avant ni après le for

Et sinon, oué with c'est *pratique* mais pas indispensable... Les languages comme le C++ ou C# ont été créés de manière que seul ce qui est vraiment utile à la programmation existe... With apportera à la facilité d'écriture du code (mais pas a la facilité de lecture... ) mais n'apportera au final rien au code compilé. Donc pour moi oué ça sert a rien.

GoldenCrystal
: Les languages comme le C++ (...) ont été créés de manière que seul ce qui est vraiment utile à la programmation existe...

Mouais, bof.

yAro voulait peut-être parler de l'utilisation de using pour l'aliasing de nom de classe.

Même dans ce cas ça n'est pas un équivalent du with With ne s'applique pas aux namespaces/classes mais aux objets eux même (de manière immonde soit il dit en passant... ça entre en conflit avec toute tentative de structuration propre du code)
Le With c'est un truc pour les flemmards. (Pourtant le copier coller fait très bien la même chose...)

With MaVariableAvecUnNomLongPourQueToutLeMondeCompreneCeQueCest
  .Membre = 3
  With .MembreAvecUnNomPasForcementCourt
    .Membre = .Membre + 1 ' Et là tu appelles comment le .Membre du précédent ?? (< - syntaxe foireuse)
    ' Un tas d'autres trucs
  End With
  .Membre2 = .Membre1 + 2 'Si jamais le début du bloc est plus visible t'es dans la merde pour savoir ce que ça veut dire...
  ' Etc...
End With

Moi je trouve ça crade...

chacun son truc hein, perso je trouve que

with user
   id = 1337;
   name = 'toto';
   pass = 'plop';
   age = 27;
end

c'est vachement plus élegant que réécrire 4 fois (et encore c'est un petit exemple) de suite le même préfixe... comme de toutes façons ça n'empêche absolument pas d'utiliser l'autre méthode en cas de conflit de champs (ça arrive quand même pas souvent hein, faut pas être de mauvaise foi non plus), je vois pas ce qu'on peut reprocher à cette syntaxe qui ne fait qu'éviter des patés de code super lourds amha ^^

Zephyr :
chacun son truc hein, perso je trouve que

with user
   id = 1337;
   name = 'toto';
   pass = 'plop';
   age = 27;
end

Si tu as un éditeur qui permet l'édition en colonne, en 1 seconde chrono tu aurais pu rajouter "user." au début de chaque ligne...

conflit de champs (ça arrive quand même pas souvent hein, faut pas être de mauvaise foi non plus)

Le problème n'est pas "est-ce que ça arrive souvent", le problème c'est "est-ce que ça peut arriver sans qu'on s'en rende compte", et là la réponse est oui... Et surtout ça peut casser sans prévenir même si le code fonctionnait parfaitement avant, par exemple si FooBarLib 1.1 rajoute un membre "size" à sa classe de marmottes en tutu, la variable locale "size" de ta fonction deviendra magiquement la "size" de la marmotte en tutu, bref c'est vraiment la fête du slip ^^

Pollux
: Si tu as un éditeur qui permet l'édition en colonne, en 1 seconde chrono tu aurais pu rajouter "user." au début de chaque ligne...

Même sans ça, un copier coller c'est pas particulièrement long non plus, je parlais du code plus léger *une fois écrit*, rien à battre que ça prenne 1 seconde de plus ou de moins à taper ^^

Le problème n'est pas "est-ce que ça arrive souvent", le problème c'est "est-ce que ça peut arriver sans qu'on s'en rende compte", et là la réponse est oui... Et surtout ça peut casser sans prévenir même si le code fonctionnait parfaitement avant, par exemple si FooBarLib 1.1 rajoute un membre "size" à sa classe de marmottes en tutu, la variable locale "size" de ta fonction deviendra magiquement la "size" de la marmotte en tutu, bref c'est vraiment la fête du slip ^^

Là aussi on ne parle pas de la même chose, perso quand j'utilise ça déjà c'est pour remplacer un petit bloc de code (du même genre que mon exemple du post précedent), souvent des initialisations ou ce genre de choses, avec des structures qui sont à moi... Sachant que le champ le plus local a la priorité, bien sûr que je ne vais pas m'amuser à faire un "with" sur une structure que je ne connais pas... mais ça s'appelle du bon sens. J'ai rarement tendance à chercher volontairement les bugs quand je code, et franchement les règles à respecter ici ne me semblent pas des plus difficiles à suivre ^^

Zephyr
: Même sans ça, un copier coller c'est pas particulièrement long non plus, je parlais du code plus léger *une fois écrit*, rien à battre que ça prenne 1 seconde de plus ou de moins à taper ^^

Si tu parles de lisibilité, c'est pas un problème non plus :

   user.id = 1337; 
   user.name = 'toto'; 
   user.pass = 'plop'; 
   user.age = 27;

c'est parfaitement lisible aussi, parce que les "user." sont bien en colonne

Le problème n'est pas "est-ce que ça arrive souvent", le problème c'est "est-ce que ça peut arriver sans qu'on s'en rende compte", et là la réponse est oui... Et surtout ça peut casser sans prévenir même si le code fonctionnait parfaitement avant, par exemple si FooBarLib 1.1 rajoute un membre "size" à sa classe de marmottes en tutu, la variable locale "size" de ta fonction deviendra magiquement la "size" de la marmotte en tutu, bref c'est vraiment la fête du slip ^^

Là aussi on ne parle pas de la même chose, perso quand j'utilise ça déjà c'est pour remplacer un petit bloc de code (du même genre que mon exemple du post précedent), souvent des initialisations ou ce genre de choses, avec des structures qui sont à moi... Sachant que le champ le plus local a la priorité, bien sûr que je ne vais pas m'amuser à faire un "with" sur une structure que je ne connais pas... mais ça s'appelle du bon sens. J'ai rarement tendance à chercher volontairement les bugs quand je code, et franchement les règles à respecter ici ne me semblent pas des plus difficiles à suivre ^^

Oui, ton exemple est correct, mais il faut bien voir que ça t'empêche d'utiliser des variables externes dans tes initialisations (il faut te contenter de constantes ou de membres de la classe), sinon tu as des chances de tomber sur le piège dont je parle Bref, avec ces règles ça a un usage *très* restreint, et même quand c'est utilisable c'est facilement remplaçable avec un truc moins piégeux et plus flexible... (plus flexible au sens où tu peux remplacer les constantes par des variables sans risque d'erreur)


Disons que c'est un peu comme le goto, dans un langage qui le propose, ce n'est pas grave de l'utiliser dans le cadre très restreint dont tu parles, mais ce n'est pas non plus une feature utile au point d'être un réel avantage pour le langage. Et, comme pour le goto, il y a des raisons de propreté qui font que ce n'est pas stupide pour un concepteur de langage ou un programmeur de dire "je ne veux pas utiliser/permettre ça parce que même si dans certains cas ça fait quelque chose de raisonnable et un chouilla plus concis, dans bcp d'autres cas ça a un impact négatif sur la lisibilité/maintenabilité" ^^

Pollux :
Si tu parles de lisibilité, c'est pas un problème non plus :

   user.id = 1337; 
   user.name = 'toto'; 
   user.pass = 'plop'; 
   user.age = 27;

c'est parfaitement lisible aussi, parce que les "user." sont bien en colonne

Moui enfin ça c'est une question de gout, t'auras autant de mal à me faire croire que cette version est plus lisible que celle avec "with", de même que moi l'inverse, pour la simple et bonne raison que c'est faux dans les deux cas... J'ai juste posté pour expliquer à GoldenCrystal que non, cette syntaxe n'est pas parfaitement inutile, perso je la préfere largement à celle qui consiste à répeter les préfixes et je trouve que c'est un gros manque pour un langage de ne pas la proposer. Point.

Oui, ton exemple est correct, mais il faut bien voir que ça t'empêche d'utiliser des variables externes dans tes initialisations (il faut te contenter de constantes ou de membres de la classe), sinon tu as des chances de tomber sur le piège dont je parle Bref, avec ces règles ça a un usage *très* restreint, et même quand c'est utilisable c'est facilement remplaçable avec un truc moins piégeux et plus flexible... (plus flexible au sens où tu peux remplacer les constantes par des variables sans risque d'erreur)

Quel problème au fait que ce soit restreint ? C'est ça que j'arrive pas à comprendre... y'a des cas où c'est utilisable sans aucun risque, c'est dans ceux là que j'ai tendance à utiliser cette syntaxe, et partout où effectivement ça peut poser un problème, tant pis, j'utilise l'autre écriture que je trouve lourde. Ça me semblerait totalement stupide de m'interdire quelque chose que je trouve plus joli pour la simple raison qu'il existe des cas où on ne peut pas l'utiliser (rien qu'en écrivant la phrase ça me semble completement crétin comme raisonnement en tout cas, j'espere au moins avoir réussi à transmettre l'idée )

Disons que c'est un peu comme le goto, dans un langage qui le propose, ce n'est pas grave de l'utiliser dans le cadre très restreint dont tu parles, mais ce n'est pas non plus une feature utile au point d'être un réel avantage pour le langage. Et, comme pour le goto, il y a des raisons de propreté qui font que ce n'est pas stupide pour un concepteur de langage ou un programmeur de dire "je ne veux pas utiliser/permettre ça parce que même si dans certains cas ça fait quelque chose de raisonnable et un chouilla plus concis, dans bcp d'autres cas ça a un impact négatif sur la lisibilité/maintenabilité" ^^

Bah oui mais ça ça dépend beaucoup de l'endroit où c'est utilisé, et faire une géneralisation c'est tomber précisément dans ce que je décris au [cite] précedent.

Zephyr :
Quel problème au fait que ce soit restreint ? C'est ça que j'arrive pas à comprendre... y'a des cas où c'est utilisable sans aucun risque, c'est dans ceux là que j'ai tendance à utiliser cette syntaxe, et partout où effectivement ça peut poser un problème, tant pis, j'utilise l'autre écriture que je trouve lourde. Ça me semblerait totalement stupide de m'interdire quelque chose que je trouve plus joli pour la simple raison qu'il existe des cas où on ne peut pas l'utiliser (rien qu'en écrivant la phrase ça me semble completement crétin comme raisonnement en tout cas, j'espere au moins avoir réussi à transmettre l'idée )

Le problème, c'est que tu ne peux pas transformer trivialement un with(user){bidule} en user.bidule, donc tu perds en maintenabilité. De même que, je sais pas, programmer dans un langage 5% meilleur qu'un autre mais qui par exemple ne peut pas faire de multitâche ou de réseau, peut-être que c'est suffisant pour la version 1 d'un projet, et dans ce cas-là tu as gagné 5%, mais peut-être que pour la version 2 tu auras besoin de ces fonctions supplémentaires, et tu auras perdu bien plus que 5% puisqu'il faudra reprogrammer ou interfacer les deux langages, donc ce n'est pas une bonne idée de choisir ce langage... Bref, si tu estimes que with(user){bidule} n'apporte que 5% de lisibilité, c'est une mauvaise idée de l'utiliser ; évidemment, je présume que tu vas dire que pour toi with(user){bidule} est 1000 fois mieux, et que donc c'est une très bonne idée. Mais je dis juste qu'il y a là un tradeoff subjectif à faire entre l'utilisation d'une syntaxe ad-hoc et la perte de généralité qui va avec, ce n'est pas "totalement stupide"

Encore une fois tu raisonnes dans un cas completement géneral, et donc pour moi completement hs. Prenons simplement ça : "tu ne peux pas transformer trivialement un with(user){bidule} en user.bidule". Je l'ai utilisé, donc si, sinon je ne l'aurais pas fait... Mais je commence à avoir légerement l'impression de me répeter, là.
Donc non, ce n'est pas "1000 fois mieux", peut être seulement 5%, mais 5% sans *aucun* point négatif dans *le* cas dont je suis en train de parler, et uniquement celui-ci.

La perte de géneralité... si c'est pour expliquer que tout sucre syntaxique (puisque le "with" n'est rien d'autre que ça) ne permet pas forcément d'obtenir exactement la même chose que son équivalent développé, oui effectivement et ça n'a pas grand chose d'une révelation, mais personne n'a (à ma connaissance) pour l'instant été assez stupide pour dire non à ça dans un langage digne de ce nom : c'est même précisément l'inverse.

(puisque la discussion semble se diriger vers du théorique pas vraiment fondé et que je n'ai jamais trouvé ça constructif, je précise que ce ne sont pas les exemples qui manquent, au besoin ^^)

Les cas que tu cites sont réglés en VB ou en FoxPro par exemple:

size = 2
with object
   .propriete = 1
   .size = size
endwith

Donc même si dans certains cas ça peut induire en erreur comme pour size si on oublie le '.' (mais faut le faire quand même), ça reste beaucoup plus lisible à mon avis.
Et pour ton histoire d'objet parent on a ça:

with tonObjet.tonAutreObjet.unNomBienLongEtImpossibleATaperSurtoutUnLundiMatin
   .parent.size = 1
endwith

Et comme c'est relatif à l'objet en question, ça a l'avantage d'être plus facilement réutilisable.
Et pour les problèmes de with imbriqués, en FoxPro c'est impossible:

o = createobject('custom')
p = createobject('custom')
o.AddProperty('test')
with o
	.test = 1   -> ok
	with p
		.test = 2   -> error: property 'test' not found
	endwith
endwith

Bref, si le 'with' est bien pensé, je pense qu'il n'y a vraiment aucun souci à ce niveau là.

Si on suit ton principe, le 'switch' est inutile, mieux vaut utiliser les if / else if. Les 'for' sont aussi inutiles, autant faire un 'while'. En fait même les 'while' sont inutiles, on peut le faire avec des if/goto.
Sauf que voilà, ça devient légèrement chiant pour les tâches répétitives, et dans le cas cité ci-dessus y'a aucun risque de se tromper. Si le gars met un bloc with sur 200000 lignes de long là oui ça peut poser un souci de lisibilité, tout comme le code suivant:
for(i=3,j=-((h&63)<<2);j+=2-t[h&15],--h;++i) *ptr--+=*(char*)(((OBJET*)f+(h>>2))-> data);
Et c'est pas pour ça qu'on bannit les 'for' du langage...

Brunni
: Si on suit ton principe, le 'switch' est inutile, mieux vaut utiliser les if / else if. Les 'for' sont aussi inutiles, autant faire un 'while'. En fait même les 'while' sont inutiles, on peut le faire avec des if/goto.

N'importe quoi...

Perso j'aime pas les with, et je ne les utilisais pas en delphi.


sinon:

user.id = 1337;  
user.name = 'toto';  
user.pass = 'plop';  
user.age = 27;

> c'est pas bien niveau conception objet (foutrut de merde en perspective bonjour )

tu peux faire ça avec des if/else ?

swhith (i) // int i
{
  case 1:
    j += 1;
    break;
  case 2:
    j = 1;
    goto case 1;
  case 3:
    return j;
}

Quand au goto, considère que ce n'est qu'un héritage de l'assembleur, qui permet dans certains cas de se sortir de situations sans alourdir le code. Mais le goto dans son principe de base est incompatible avec la structuration (voulue) des langages actuels, c'est pour ça qu'on a les boucles while... Tu as un contrôle de ce qui se passe que tu n'as pas avec le goto. Si tu oublies le "end with" ou le ";" ou encore le "}" Le compilateur te dira directement que ton code ne fera pas ce que tu veux, si tu oublies le goto, ça compilera sans erreur mais ça marchera pas
Ensuite vient le cas où tu veux toujours éxécuter le code de la boucle au moins une fois -> le while ne marche pas simplement dans ce cas -> on a la boucle do pour ces raisons ansi que les précédentes.
Le for, lui c'est un cas à part... Autant en VB si tu tentes d'assigner la variable compteur dans le for ça te balancera une erreur (ou si ça n'est plus comme ça, ça l'a tout de même été pendant un bout de temps), autant en C le seul avantage c'est que tu sépares bien ta boucle du reste du code, contrairement à initialisation;while(condition){code;itération;} où l'initialisation est mélangée au code commun du bloc parent, et l'itération au code de la boucle, et donc où tu peux rajouter ce que tu veux après l'initialisation et l'itération, ce qui n'est généralement pas souhaité.
Bref toutes ces structures n'apportent que à la sécurité d'écriture du code (contrairement au with hein ) mais si on en a pas besoin on peut aussi retourner a l'assembleur qui n'est pas portable ^^

Zephyr :
Encore une fois tu raisonnes dans un cas completement géneral, et donc pour moi completement hs. Prenons simplement ça : "tu ne peux pas transformer trivialement un with(user){bidule} en user.bidule". Je l'ai utilisé, donc si, sinon je ne l'aurais pas fait... Mais je commence à avoir légerement l'impression de me répeter, là. Donc non, ce n'est pas "1000 fois mieux", peut être seulement 5%, mais 5% sans *aucun* point négatif dans *le* cas dont je suis en train de parler, et uniquement celui-ci.

Ben si, le fait que le jour où tu veux remplacer user.age par un calcul qui dépend de la date, tu devras tout convertir, c'est bien un point négatif... Evidemment, il y a des cas où tu écris du code juste pour une fois et ensuite tu le balances à la poubelle, dans ce cas-là c'est pas grave, mais je ne parle pas de ça ^^ (et je suppose que toi non plus)

La perte de géneralité... si c'est pour expliquer que tout sucre syntaxique (puisque le "with" n'est rien d'autre que ça) ne permet pas forcément d'obtenir exactement la même chose que son équivalent développé, oui effectivement et ça n'a pas grand chose d'une révelation, mais personne n'a (à ma connaissance) pour l'instant été assez stupide pour dire non à ça dans un langage digne de ce nom : c'est même précisément l'inverse.

Ben je suis désolé si tu penses ça, mais tout sucre syntaxique n'est pas bon à prendre. Et inversement, il y a plein de sucres syntaxiques qui ne tombent pas dans l'écueil du with, dans la mesure où il ne perdent pas de généralité : int i=0; while (i<42) { ...; i++; } -> for (int i=0;i<42;i++) ...;, ou bien replaceword($my_word,$value+1) -> s/\b$my_word\b/$value+1/e.
Notamment, je pense que ne pas permettre d'utiliser des variables en lieu et place de constantes à chaque fois que des constantes sont permises, c'est un gros inconvénient. Ce n'est pas unique au with, hein : par exemple le switch du C présente aussi cet inconvénient, et c'est bien dommage, cela dit c'est bcp moins grave que with{} pour deux raisons :
- il permet d'utiliser des constantes du préprocesseur ou bien des valeurs d'enum, ce qui évite les constantes numériques
- généralement on a besoin de peu de flexibilité quand on veut distinguer 50 cas selon la valeur d'une variable, parce que les valeurs en question seront souvent des constantes immuables ; dans le cas de with{}, c'est déjà moins clair que quand je vais initialiser user.id je n'aurai jamais à faire appel à une fonction, ou bien que si je rajoute un champ style user.joindate ça sera aussi une constante...

Brunni :
Les cas que tu cites sont réglés en VB ou en FoxPro par exemple:

size = 2
with object
   .propriete = 1
   .size = size
endwith

Donc même si dans certains cas ça peut induire en erreur comme pour size si on oublie le '.' (mais faut le faire quand même), ça reste beaucoup plus lisible à mon avis.

Oui, alors là pour le coup c'est une solution propre (même si c'est dommage que ça ne soit pas imbricable, mais c'est pas grave puisque ça ne pose pas de pb de maintenabilité)
On a les 5% d'avantage sans les inconvénients du with de Bob ^^

Bref, si le 'with' est bien pensé, je pense qu'il n'y a vraiment aucun souci à ce niveau là.

Si on suit ton principe, le 'switch' est inutile, mieux vaut utiliser les if / else if.

C'est pratique notamment à cause des fallthrough et des break (qui sont pénibles à réaliser avec des if), cela dit comme dit dans mon post à Bob en C/C++ c'est dommage qu'on ne puisse pas utiliser autre chose que des constantes... (et en C++ ce serait sympa de pouvoir utiliser des types autres que des entiers, par exemple des chaînes : je crois qu'entre autres C# et Ruby permettent ça)

Les 'for' sont aussi inutiles, autant faire un 'while'.

Non, ils sont plus concis, permettent en C++/C99/C# de masquer le compteur de boucle du reste de la fonction, et ne perdent pas en généralité sur les while.

En fait même les 'while' sont inutiles, on peut le faire avec des if/goto.

Encore une fois, on perd le scoping lexical (à moins de rajouter des accolades autour de la boucle), c'est plus verbeux, ça oblige à définir un tas de label nommés qui sont implicites dans le while, et ça ne permet rien de plus.

moi j'aime bien le with de caml
---> []

Lol c'était pas sérieux le coup des if/else, c'était pour montrer hein (je savais que j'aurais mieux fait de me taire )
Mais bon je trouve juste dommage que ça manque en C++, et c'est pas la seule chose (pour ne citer que le '__super' à microsoft ).

JackosKing-VNR :
> c'est pas bien niveau conception objet (foutrut de merde en perspective bonjour )

c'est pas trop le sujet ds ce topic, mais si tu arrives à trouver un défaut de modelisation sur 4 lignes qui ne définissent même pas une seule structure, pourquoi pas

Pollux
: Ben si, le fait que le jour où tu veux remplacer user.age par un calcul qui dépend de la date, tu devras tout convertir, c'est bien un point négatif... Evidemment, il y a des cas où tu écris du code juste pour une fois et ensuite tu le balances à la poubelle, dans ce cas-là c'est pas grave, mais je ne parle pas de ça ^^ (et je suppose que toi non plus)

Bah non je n'aurai pas tout à convertir, seulement dans le cas hautement improbable où tout à coup, manque de bol, j'ai besoin d'initialiser avec une variable externe qui se trouve avoir le même nom qu'un champ de ma structure, faut quand même le chercher (d'autant plus que la structure n'a pas évolué, et que donc c'est la variable qui est venue s'ajouter, ce qui signifie que j'ai volontairement ajouté une variable qui pose problème avec mon propre code ? non, géneralement j'évite de me mettre des batons dans les roues ^^)

Pollux :
Ben je suis désolé si tu penses ça, mais tout sucre syntaxique n'est pas bon à prendre. Et inversement, il y a plein de sucres syntaxiques qui ne tombent pas dans l'écueil du with, dans la mesure où il ne perdent pas de généralité : int i=0; while (i<42) { ...; i++; } -> for (int i=0;i<42;i++) ...;, ou bien replaceword($my_word,$value+1) -> s/\b$my_word\b/$value+1/e.

En gros pour toi, tout sucre syntaxique qui limite le domaine d'utilisation est bon à jeter ? Pour reprendre ton exemple du switch, l'extension qui consiste à pouvoir remplacer "case 1: case 2: case 3: case 4" par "case 1 ... 4:" est une abomination puisque si par hasard un jour je veux exclure le 3 de mes cas, il faut tout réécrire ? Après tout pourquoi pas, chacun son niveau de fanatisme, mais là aussi c'est un truc que j'utilise sans la moindre hésitation dès qu'il devient utile. Donc oui je pense que tout sucre syntaxique est bon à prendre, à partir du moment où il est raisonnable, et je préfere des écritures élegantes et lisibles à des blocs immondes mais évolutifs quand je sais que l'évolution en question n'a que très peu de chances d'arriver. Tu peux effectivement programmer de la façon la plus modulaire possible, et ne jamais reposer sur le fait qu'une portion de code risque de rester inchangée pendant longtemps... ...mais à quel prix