variable statique dans une méthode de classe C++ - Page 1

salut

#include <iostream>

struct A
{
	void func()
	{
		static int a= 0 ;
		std::cout << ++a << std::endl ;
	}
} ;
	

int main()
{
	A a1 ;
	A a2 ;
	a1.func() ;
	a2.func() ;
}

c'est marrant, mais j'aurais juré que afficherait

1
1

et pas

1
2

Je trouve ça un peu naze que seule la portée change par rapport à un attribut statique :/
Non ?

Bah c'est le comportement normal d'une variable locale statique de conserver sa valeur entre deux appels, tu attends quoi comme réponse ? ^^

Ben, pour une méthode, je pensais que c'était local à l'instance de la classe.
En gros je trouve étrange (pas naturel) que le static d'une variable de méthode remonte au niveau global.

oué mais c'est consistant avec le C

Oui et non, y'avait pas de méthode en C, y'avait que des fonctions. C'est quand même pas pareil :/

Moi je suis de l'avis de Pen^2.
Sinon, il y a moyen d'obtenir le comportement recherché ?

Même si je me serais aussi attendu a la même chose que Pen^2, mais bon ^^
Je pense que ça à voir avec la modularité du langage. Puisque tu peux séparer prototype et implémentation (...) le compilateur ne peut a priori pas simplement faire le lien entre le code de ta fonction et le prototype de ton class/struct. ça ne pose pas nécéssairement de problème dans le cas d'allocation dynamique via new (en fait ça dépendrait de l'implémentation du compilo ), mais pour la création d'objets statiques le compilo ne peut pas déterminer a l'avance la taille à allouer.
Après si tu n'as pas accès au contexte objet il ne reste que le contexte global qui est bien supporté (on dit merci la compilation séparée...)

C'est quoi la différence entre struct et class ? Pourquoi il n'y a pas de new() après la déclaration a1 (et a2) ?

a1 et a2 sont déclarées sur la pile. new() ne te sert que pour l'allocation dynamique.
A *a1 = new A(); par exemple ^^ (mais faut pas oublier le delete qui va avec ...)

Sinon pour les struct et les class a priori c'est une question de visibilité par défaut des membres (struct/public vs class/private).

moi c'est le seul vrai truc honnête qui me fait détester le c++:
le mix entre les pointeurs vers des classes, et les objets classes déclarés sur la pile. Je trouve ça vraiment très caca.

Sans lancer de comparaison, je préfère le java ou tous les objets sont des références, au moins ça a le mérite d'être clair.

Ça me semble pourtant bien plus sain qu'un langage comme Java justement, où on a d'une part des types primitifs (int, char & co) qui sont passés par valeur et placés sur la pile, et d'une autre des objets qui ne fonctionnent pas du tout pareil. Quelle est la justification de cette séparation, et pourquoi on ne peut pas choisir de faire autrement ? Même si ça n'est pas parfait en C++, ça me semble quand même bien plus cohérent de ne pas forcer l'amalgame scalaire/objet et valeur/pointeur (le mieux étant à mon avis les langages pour lesquels il n'y a réellement aucune différence entre les types de base du langage et ceux qu'un utilisateur peut déclarer lui-même).

C'est une des raisons pour lesquelles le Java rame, ça coûte un temps énorme d'allouer n'importe quel petit objet sur le heap et de s'occuper de tous ces objets minuscules dans la GC. Et les objets sur la pile permettent aussi de réaliser facilement le modèle RAII, où les désallocations sont faites automatiquement dans le destructeur, qui est appelé automatiquement quand l'objet sort du scope, donc on ne risque pas de se tromper et donc on n'a pas besoin de GC.

Sasume (./6) :
Moi je suis de l'avis de Pen^2.

Sasume (./6) :
Sinon, il y a moyen d'obtenir le comportement recherché ?

je propose ça :
[nosmile]

#include <iostream>
#include <map>


template<class T1, class T2>
class LocalStatic
{
public:
	LocalStatic( T1* const ptr, T2 value )
	{
		mapValue.insert(std::pair<T1* const, T2>(ptr, value)) ;
	}
	
	T2& get( T1* const ptr )
	{
		return mapValue.find(ptr)->second ;
	}
	
private:
	std::map<T1* const, T2> mapValue ;
	LocalStatic( const LocalStatic& lc ) {}
	LocalStatic& operator=( const LocalStatic& lc) { return NULL ; }
} ;




struct A
{
	void func()
	{
		static LocalStatic<A, int> a(this, 0) ;
		std::cout << ++(a.get(this)) << std::endl ;
	}
} ;





int main()
{
	A a1 ;
	A a2 ;
	
	a1.func() ;
	a2.func() ;
	
	a1.func() ;
	a1.func() ;
	
	a2.func() ;
}

GoldenCrystal (./7) :
Même si je me serais aussi attendu a la même chose que Pen^2, mais bon ^^

²

GoldenCrystal (./7) :
compilo ne peut pas déterminer a l'avance la taille à allouer.

ah, oué, merci

$ g++ -Wall -ansi -s test1.cpp && a.exe
1
1
2
3
2

z'en pensez quoi ?

perso j'en pense (mais ça marche)

squalyl (./15) :
perso j'en pense (mais ça marche)

Tu ferais quoi ? un attribut ?

ben nan, je pense que t'as la solution, mais c'est über-ugly comme truc quoi

(a mon avis c'est pas un truc standard, les statiques locales, mais alors pas du tout )

d'ailleurs un attribut static dans une classe ça fait pas le boulot?

squalyl (./17) :
ben nan, je pense que t'as la solution, mais c'est über-ugly comme truc quoi

(a mon avis c'est pas un truc standard, les statiques locales, mais alors pas du tout )

pourtant ça me semble assez pratique/utile, quand même ^^

d'ailleurs un attribut static dans une classe ça fait pas le boulot?

ben non, un attribut statique est partagé par toutes les instances de la classe, justement.

ce que tu veux c'est pas tout bêtement une variable membre ? (mis à part qu'elle serait visible pour les autres méthodes)
et je ne vois pas du tout ce que tu trouves de pas cohérent à ce fonctionnement. par rapport à une variable membre statique ya juste sa portée qui change puisqu'elle est déclarée dans le scope de la fonction et pas de la classe.
Et perso, les variables statiques dans des fonctions, à part pour du debug je trouve ça assez sale. ou quand la fonction doit retourner à chaque fois un nom unique

aze (./19) :
ce que tu veux c'est pas tout bêtement une variable membre ? (mis à part qu'elle serait visible pour les autres méthodes)

ben oui, disons que conceptuellement cette variable ne devrait pas être un attribut (en gros je veux me faire un cache)

aze (./19) :
et je ne vois pas du tout ce que tu trouves de pas cohérent à ce fonctionnement. par rapport à une variable membre statique ya juste sa portée qui change puisqu'elle est déclarée dans le scope de la fonction et pas de la classe.

Ce n'est tout simplement pas une fonction, c'est une méthode non statique de la classe.
Donc je m'attendais à ce que ça reste local à l'instance de la classe vu que la méthode n'est pas statique.

aze (./19) :
Et perso, les variables statiques dans des fonctions, à part pour du debug je trouve ça assez sale. ou quand la fonction doit retourner à chaque fois un nom unique

ben pour un cache ça serait bien pratique quand même

une variable membre statique n'est pas lié à une instance, il n'y a aucune raison qu'une variable statique devienne liée à une instance Je trouve ça tout à fait cohérent avec les autres utilisations du mot clé static.
après je suis d'accord que ça peut être pratique d'avoir une variable membre qui ne soit visible que depuis une méthode. Mais de là à dire que ta variable ne devrait pas être un attribut, c'est discutable puisqu'elle doit être liée à une instance de classe.

<hs>pour avoir des caches, j'ai fait des trucs super sales une fois en PHP, et en fait ça ressemblait un peu à ça.

J'avais une classe "cache" avec une map <id,objet> qui était stockée dans une variable statique de chaque classe a cacher. et le get de la classe "cachée" faisait un self::$cache->lookup(id) du cache avant d'aller chercher la vraie donnée.

(c'était pour des objets stockés dans une base, en fait)

</hs>

Personnellement, je trouve que c'est quand-même plus propre (et plus efficace) de faire:

class A {
  private:
    int func_cache;
  public:
    A() : func_cache(0) {}
    void func() {
      std::cout << ++func_cache << std::endl ;
    }
};

Il suffit d'une convention de noms raisonnable (func_cache est un cache réservé à func, le premier qui utilise ça ailleurs se fera massacrer ) et des droits d'accès standard du C++ (private) et on ne peut pas faire trop de bêtises.

avec un __attribute__((only_use_from_functions_starting_by "func")) ?

pen^2, si tu déclarais tout simplement une variable globale ?

Ben ça ferait le même résultat que ./1 en plus crade non ?

Oui ! OTAN pour moi.

J'avoue avoir du mal à comprendre pourquoi tu ne mets pas ta variable en membre privé de ta structure (comme l'exemple de KK).

parce qu'il veut une variable locale à la fonction

Ca répond pas à la question. Une variable locale c'est un moyen, pas un but.