qui peut me dire si il y a une différence de vitesse entre les accés au
membres (publiques ou privés) d'une classe et ceux d'une struct ?
Stroustrup dans sa "bible" nous dit bien qu'une struct est une classe
allégée, un structure de données plus qu'un type mais ne parle pas de la
façon dont c'est compilé.
Je pose cette question car je fais en ce moment un simulateur de
vêtement et j'aimerai savoir si pour les points de mon maillage je dois
faire une classe noeud ou simplement déclarer une struct noeud, sachant
que tous les membres sont publiques, ce qui correspond à la définition
de bjarne dans le choix entre les deux :).
En gros, cela correspond à savoir si les structs sont vraiments gerées
comme des classes ou pas.
qui peut me dire si il y a une différence de vitesse entre les accés au membres (publiques ou privés) d'une classe et ceux d'une struct ?
Il faudrait que tu me donnes la ref, mais j'aurais tendance à dire qu'il faut distinguer deux choses: une "structure" à la C, avec le mot clef struct et que des champs (publics), pas de méthode, et une classe C++, qui peut être bien plus riche, mais peut aussi utiliser le mot clef "struct".
Les mots "class" et "struct" ne changent à ma connaissance que des question de visibilité. Hormis les questions d'héritage, on a struct X { <=> class X { public:
Stroustrup dans sa "bible" nous dit bien qu'une struct est une classe allégée, un structure de données plus qu'un type mais ne parle pas de la façon dont c'est compilé.
La compilation est dépendante de l'implémentation, mais on peut résonnablement imaginer qu'une classe sans aucune méthode virtuelle est stoquée en mémoire comme une structure à la C. Si en plus tu ne définis aucun constructeur par défaut, destructeur ni opérateur de copie et qu'aucun membre n'en a (ni aucun membre de membre, etc..), alors ça doit donner un code vraiment très semblable à une structure à la C.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
YaNn wrote:
qui peut me dire si il y a une différence de vitesse entre les accés au
membres (publiques ou privés) d'une classe et ceux d'une struct ?
Il faudrait que tu me donnes la ref, mais j'aurais tendance à dire
qu'il faut distinguer deux choses: une "structure" à la C, avec
le mot clef struct et que des champs (publics), pas de méthode,
et une classe C++, qui peut être bien plus riche, mais peut aussi
utiliser le mot clef "struct".
Les mots "class" et "struct" ne changent à ma connaissance que
des question de visibilité. Hormis les questions d'héritage,
on a
struct X { <=> class X { public:
Stroustrup dans sa "bible" nous dit bien qu'une struct est une classe
allégée, un structure de données plus qu'un type mais ne parle pas de la
façon dont c'est compilé.
La compilation est dépendante de l'implémentation, mais on
peut résonnablement imaginer qu'une classe sans aucune méthode
virtuelle est stoquée en mémoire comme une structure à la C.
Si en plus tu ne définis aucun constructeur par défaut,
destructeur ni opérateur de copie et qu'aucun membre n'en a
(ni aucun membre de membre, etc..), alors ça doit donner
un code vraiment très semblable à une structure à la C.
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
qui peut me dire si il y a une différence de vitesse entre les accés au membres (publiques ou privés) d'une classe et ceux d'une struct ?
Il faudrait que tu me donnes la ref, mais j'aurais tendance à dire qu'il faut distinguer deux choses: une "structure" à la C, avec le mot clef struct et que des champs (publics), pas de méthode, et une classe C++, qui peut être bien plus riche, mais peut aussi utiliser le mot clef "struct".
Les mots "class" et "struct" ne changent à ma connaissance que des question de visibilité. Hormis les questions d'héritage, on a struct X { <=> class X { public:
Stroustrup dans sa "bible" nous dit bien qu'une struct est une classe allégée, un structure de données plus qu'un type mais ne parle pas de la façon dont c'est compilé.
La compilation est dépendante de l'implémentation, mais on peut résonnablement imaginer qu'une classe sans aucune méthode virtuelle est stoquée en mémoire comme une structure à la C. Si en plus tu ne définis aucun constructeur par défaut, destructeur ni opérateur de copie et qu'aucun membre n'en a (ni aucun membre de membre, etc..), alors ça doit donner un code vraiment très semblable à une structure à la C.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Le Géant Vert
"Marc Boyer" a écrit dans le message de news: br74gn$8gt$
YaNn wrote:
qui peut me dire si il y a une différence de vitesse entre les accés au membres (publiques ou privés) d'une classe et ceux d'une struct ?
Il faudrait que tu me donnes la ref, mais j'aurais tendance à dire qu'il faut distinguer deux choses: une "structure" à la C, avec le mot clef struct et que des champs (publics), pas de méthode, et une classe C++, qui peut être bien plus riche, mais peut aussi utiliser le mot clef "struct".
Les mots "class" et "struct" ne changent à ma connaissance que des question de visibilité. Hormis les questions d'héritage, on a struct X { <=> class X { public:
Stroustrup dans sa "bible" nous dit bien qu'une struct est une classe allégée, un structure de données plus qu'un type mais ne parle pas de la façon dont c'est compilé.
La compilation est dépendante de l'implémentation, mais on peut résonnablement imaginer qu'une classe sans aucune méthode virtuelle est stoquée en mémoire comme une structure à la C. Si en plus tu ne définis aucun constructeur par défaut, destructeur ni opérateur de copie et qu'aucun membre n'en a (ni aucun membre de membre, etc..), alors ça doit donner un code vraiment très semblable à une structure à la C.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
tout pareil que Marc ; une struct n'étant qu'un classe simplifiée (tous les champs publics, etc.), une classe et une struct contenant les memes éléments devraient donner un code tout à fait similaire en terme de temps d'exécution. pour ma part, dans un tel cas je privélégierai des classes avec des membres privates et des getters publics inline ; juste histoire de rester dans le concept objet en fournissant une interface de manipulation pour l'utlisateur.
"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit dans le message
de news: br74gn$8gt$1@news.cict.fr...
YaNn wrote:
qui peut me dire si il y a une différence de vitesse entre les accés au
membres (publiques ou privés) d'une classe et ceux d'une struct ?
Il faudrait que tu me donnes la ref, mais j'aurais tendance à dire
qu'il faut distinguer deux choses: une "structure" à la C, avec
le mot clef struct et que des champs (publics), pas de méthode,
et une classe C++, qui peut être bien plus riche, mais peut aussi
utiliser le mot clef "struct".
Les mots "class" et "struct" ne changent à ma connaissance que
des question de visibilité. Hormis les questions d'héritage,
on a
struct X { <=> class X { public:
Stroustrup dans sa "bible" nous dit bien qu'une struct est une classe
allégée, un structure de données plus qu'un type mais ne parle pas de la
façon dont c'est compilé.
La compilation est dépendante de l'implémentation, mais on
peut résonnablement imaginer qu'une classe sans aucune méthode
virtuelle est stoquée en mémoire comme une structure à la C.
Si en plus tu ne définis aucun constructeur par défaut,
destructeur ni opérateur de copie et qu'aucun membre n'en a
(ni aucun membre de membre, etc..), alors ça doit donner
un code vraiment très semblable à une structure à la C.
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
tout pareil que Marc ; une struct n'étant qu'un classe simplifiée (tous les
champs publics, etc.), une classe et une struct contenant les memes éléments
devraient donner un code tout à fait similaire en terme de temps
d'exécution.
pour ma part, dans un tel cas je privélégierai des classes avec des membres
privates et des getters publics inline ; juste histoire de rester dans le
concept objet en fournissant une interface de manipulation pour
l'utlisateur.
"Marc Boyer" a écrit dans le message de news: br74gn$8gt$
YaNn wrote:
qui peut me dire si il y a une différence de vitesse entre les accés au membres (publiques ou privés) d'une classe et ceux d'une struct ?
Il faudrait que tu me donnes la ref, mais j'aurais tendance à dire qu'il faut distinguer deux choses: une "structure" à la C, avec le mot clef struct et que des champs (publics), pas de méthode, et une classe C++, qui peut être bien plus riche, mais peut aussi utiliser le mot clef "struct".
Les mots "class" et "struct" ne changent à ma connaissance que des question de visibilité. Hormis les questions d'héritage, on a struct X { <=> class X { public:
Stroustrup dans sa "bible" nous dit bien qu'une struct est une classe allégée, un structure de données plus qu'un type mais ne parle pas de la façon dont c'est compilé.
La compilation est dépendante de l'implémentation, mais on peut résonnablement imaginer qu'une classe sans aucune méthode virtuelle est stoquée en mémoire comme une structure à la C. Si en plus tu ne définis aucun constructeur par défaut, destructeur ni opérateur de copie et qu'aucun membre n'en a (ni aucun membre de membre, etc..), alors ça doit donner un code vraiment très semblable à une structure à la C.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
tout pareil que Marc ; une struct n'étant qu'un classe simplifiée (tous les champs publics, etc.), une classe et une struct contenant les memes éléments devraient donner un code tout à fait similaire en terme de temps d'exécution. pour ma part, dans un tel cas je privélégierai des classes avec des membres privates et des getters publics inline ; juste histoire de rester dans le concept objet en fournissant une interface de manipulation pour l'utlisateur.
Magnet
YaNn racontait :
En gros, cela correspond à savoir si les structs sont vraiments gerées comme des classes ou pas.
En un mot, c'est exactement la meme chose excepté que les membres, les méthodes et l'héritage sont publics par défaut avec struct et privés par défaut avec class.
-- Magnet
YaNn <yann.prosper@wanadoo.fr> racontait :
En gros, cela correspond à savoir si les structs sont vraiments gerées
comme des classes ou pas.
En un mot, c'est exactement la meme chose excepté que les membres, les
méthodes et l'héritage sont publics par défaut avec struct et privés par
défaut avec class.
En gros, cela correspond à savoir si les structs sont vraiments gerées comme des classes ou pas.
En un mot, c'est exactement la meme chose excepté que les membres, les méthodes et l'héritage sont publics par défaut avec struct et privés par défaut avec class.
-- Magnet
kanze
YaNn wrote in message news:<br71j9$1hd$...
qui peut me dire si il y a une différence de vitesse entre les accés au membres (publiques ou privés) d'une classe et ceux d'une struct ?
Qu'est-ce que te dit le profiler.
Stroustrup dans sa "bible" nous dit bien qu'une struct est une classe allégée, un structure de données plus qu'un type mais ne parle pas de la façon dont c'est compilé.
C'est une façon pédégogique à présenter la chose. Selon la norme, une struct est une classe -- il n'y a pas de différence. En fait, j'ai déjà créer des struct avec des constructeurs, par exemple.
Je pose cette question car je fais en ce moment un simulateur de vêtement et j'aimerai savoir si pour les points de mon maillage je dois faire une classe noeud ou simplement déclarer une struct noeud, sachant que tous les membres sont publiques, ce qui correspond à la définition de bjarne dans le choix entre les deux :).
Ça dépend de ce que veut la conception. Si la conception veut une simple aggrégation de données, sans autre choses, une struct convient. Si la conception veut que ces données aient un comportement propre à elles, qu'elles aient une cohérence, où qu'elles aient des contraintes, alors, il te faut une classe (avec les données privées, et les fonctions d'accès).
En gros, cela correspond à savoir si les structs sont vraiments gerées comme des classes ou pas.
Une struct est une classe. Formellement, la seule différence, c'est dans les définitions, et là, c'est seulement si le bloc de définition démarre en private ou en public.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
YaNn <yann.prosper@wanadoo.fr> wrote in message
news:<br71j9$1hd$1@news-reader5.wanadoo.fr>...
qui peut me dire si il y a une différence de vitesse entre les accés
au membres (publiques ou privés) d'une classe et ceux d'une struct ?
Qu'est-ce que te dit le profiler.
Stroustrup dans sa "bible" nous dit bien qu'une struct est une classe
allégée, un structure de données plus qu'un type mais ne parle pas de
la façon dont c'est compilé.
C'est une façon pédégogique à présenter la chose. Selon la norme, une
struct est une classe -- il n'y a pas de différence. En fait, j'ai déjà
créer des struct avec des constructeurs, par exemple.
Je pose cette question car je fais en ce moment un simulateur de
vêtement et j'aimerai savoir si pour les points de mon maillage je
dois faire une classe noeud ou simplement déclarer une struct noeud,
sachant que tous les membres sont publiques, ce qui correspond à la
définition de bjarne dans le choix entre les deux :).
Ça dépend de ce que veut la conception. Si la conception veut une simple
aggrégation de données, sans autre choses, une struct convient. Si la
conception veut que ces données aient un comportement propre à elles,
qu'elles aient une cohérence, où qu'elles aient des contraintes, alors,
il te faut une classe (avec les données privées, et les fonctions
d'accès).
En gros, cela correspond à savoir si les structs sont vraiments gerées
comme des classes ou pas.
Une struct est une classe. Formellement, la seule différence, c'est dans
les définitions, et là, c'est seulement si le bloc de définition démarre
en private ou en public.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
qui peut me dire si il y a une différence de vitesse entre les accés au membres (publiques ou privés) d'une classe et ceux d'une struct ?
Qu'est-ce que te dit le profiler.
Stroustrup dans sa "bible" nous dit bien qu'une struct est une classe allégée, un structure de données plus qu'un type mais ne parle pas de la façon dont c'est compilé.
C'est une façon pédégogique à présenter la chose. Selon la norme, une struct est une classe -- il n'y a pas de différence. En fait, j'ai déjà créer des struct avec des constructeurs, par exemple.
Je pose cette question car je fais en ce moment un simulateur de vêtement et j'aimerai savoir si pour les points de mon maillage je dois faire une classe noeud ou simplement déclarer une struct noeud, sachant que tous les membres sont publiques, ce qui correspond à la définition de bjarne dans le choix entre les deux :).
Ça dépend de ce que veut la conception. Si la conception veut une simple aggrégation de données, sans autre choses, une struct convient. Si la conception veut que ces données aient un comportement propre à elles, qu'elles aient une cohérence, où qu'elles aient des contraintes, alors, il te faut une classe (avec les données privées, et les fonctions d'accès).
En gros, cela correspond à savoir si les structs sont vraiments gerées comme des classes ou pas.
Une struct est une classe. Formellement, la seule différence, c'est dans les définitions, et là, c'est seulement si le bloc de définition démarre en private ou en public.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Marc Boyer
Marc Boyer wrote:
Les mots "class" et "struct" ne changent à ma connaissance que des question de visibilité. Hormis les questions d'héritage, on a struct X { <=> class X { public:
J'ajoute qu'il y a ce que dit la norme et les conventions de nommage, et que quelqu'un qui met des fonctions virtuelles à une "struct", c'est un peu comme quelqu'un qui nomme authorName une variable de type float: il a intérêt à avoir une bonne raison.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Marc Boyer wrote:
Les mots "class" et "struct" ne changent à ma connaissance que
des question de visibilité. Hormis les questions d'héritage,
on a
struct X { <=> class X { public:
J'ajoute qu'il y a ce que dit la norme et les conventions
de nommage, et que quelqu'un qui met des fonctions virtuelles
à une "struct", c'est un peu comme quelqu'un qui nomme
authorName une variable de type float: il a intérêt
à avoir une bonne raison.
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
Les mots "class" et "struct" ne changent à ma connaissance que des question de visibilité. Hormis les questions d'héritage, on a struct X { <=> class X { public:
J'ajoute qu'il y a ce que dit la norme et les conventions de nommage, et que quelqu'un qui met des fonctions virtuelles à une "struct", c'est un peu comme quelqu'un qui nomme authorName une variable de type float: il a intérêt à avoir une bonne raison.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
YaNn
Merci merci pour tous ces renseignements :)
En fait j'ai tendance à privilègier la déclaration publique de mes attributs lorsque je fait de la 3D, par soucis d'efficacité. J'ajouterai avoir lu pas mal de papier qui disaient que l'inlining n'était pas systematique et que le compilateur ne l'appliquait pas toujours :(
En fait je pensais faire des structs afin d'encapsuler deux "types" dans celui que je compte offrir dans le programme :
class SpringSystem { public : //constructeurs, destructeurs, méthodes ....
private : Spring *TabSpring; // si je les mets publiques Node *TabNode; // je peux gagner en vitesse non ? };
Voila à quoi je pensais, mais peut être avec des classes est-ce plus concept tout-objet ? j'avoue ne pas être un fan du tout-objet mais s'il faut en passer par la :)
Merci merci pour tous ces renseignements :)
En fait j'ai tendance à privilègier la déclaration publique de mes
attributs lorsque je fait de la 3D, par soucis d'efficacité. J'ajouterai
avoir lu pas mal de papier qui disaient que l'inlining n'était pas
systematique et que le compilateur ne l'appliquait pas toujours :(
En fait je pensais faire des structs afin d'encapsuler deux "types" dans
celui que je compte offrir dans le programme :
class SpringSystem
{
public :
//constructeurs, destructeurs, méthodes ....
private :
Spring *TabSpring; // si je les mets publiques
Node *TabNode; // je peux gagner en vitesse non ?
};
Voila à quoi je pensais, mais peut être avec des classes est-ce plus
concept tout-objet ? j'avoue ne pas être un fan du tout-objet mais s'il
faut en passer par la :)
En fait j'ai tendance à privilègier la déclaration publique de mes attributs lorsque je fait de la 3D, par soucis d'efficacité. J'ajouterai avoir lu pas mal de papier qui disaient que l'inlining n'était pas systematique et que le compilateur ne l'appliquait pas toujours :(
En fait je pensais faire des structs afin d'encapsuler deux "types" dans celui que je compte offrir dans le programme :
class SpringSystem { public : //constructeurs, destructeurs, méthodes ....
private : Spring *TabSpring; // si je les mets publiques Node *TabNode; // je peux gagner en vitesse non ? };
Voila à quoi je pensais, mais peut être avec des classes est-ce plus concept tout-objet ? j'avoue ne pas être un fan du tout-objet mais s'il faut en passer par la :)
Fonzy
"YaNn" a écrit dans le message de news:br7rfc$vqt$ (snip)
Voila à quoi je pensais, mais peut être avec des classes est-ce plus concept tout-objet ? j'avoue ne pas être un fan du tout-objet mais s'il faut en passer par la :)
Visiblement, c'est de la méthode elt. finis. Pour ce genre de code de calcul (qui va se ramener au final à l'inversion d'une grosse matrice, donc qqch de fondamentalement orienté procédure), effectivement l'encapsulation est souvent le seul concept "objet" dont on se sert. En gros, si quelqu'un doit prendre la relève du code derrière toi et l'étendre en spécialisant certains concepts de base rentrant en jeu dans la mef (mais je vois pas trop lesquels), ça vaut le coup. Sinon, il vaut mieux faire comme tu le sens toi... D'un autre côté, je me dis que faire de la mécanique des vêtements doit être assez différent de la méca du solide classique. Il doit y avoir une implémentation particulière que l'on attend de toi. Sinon, pourquoi ne pas utiliser un code mef standard...
Tiens par exemple, est-il envisageable de prendre en compte, en plus du chargement mécanique, un chargement thermique, un mouillage des fibres (et modification des paramètres physiques)? Et si oui, ne peut-ce pas se faire par une spécialisation de mes concepts de base? Ma boîte est-elle adepte du knowledge management :))? Voilà le genre de question qu'il faut que tu te poses pour savoir si oui ou non tu dois faire de l'objet. Mais c'est vrai que si tu t'en tiens à ton cahier des charges, pour un code de calcul mécanique qui tient lieu de petit projet (donc pas une suite logicielle interfaçable avec tout plein de trucs), c'est souvent surfait.
Fonzy
"YaNn" <yann.prosper@wanadoo.fr> a écrit dans le message de
news:br7rfc$vqt$1@news-reader3.wanadoo.fr...
(snip)
Voila à quoi je pensais, mais peut être avec des classes est-ce plus
concept tout-objet ? j'avoue ne pas être un fan du tout-objet mais s'il
faut en passer par la :)
Visiblement, c'est de la méthode elt. finis. Pour ce genre de code de calcul
(qui va se ramener au final à l'inversion d'une grosse matrice, donc qqch de
fondamentalement orienté procédure), effectivement l'encapsulation est
souvent le seul concept "objet" dont on se sert. En gros, si quelqu'un doit
prendre la relève du code derrière toi et l'étendre en spécialisant certains
concepts de base rentrant en jeu dans la mef (mais je vois pas trop
lesquels), ça vaut le coup. Sinon, il vaut mieux faire comme tu le sens
toi...
D'un autre côté, je me dis que faire de la mécanique des vêtements doit être
assez différent de la méca du solide classique. Il doit y avoir une
implémentation particulière que l'on attend de toi. Sinon, pourquoi ne pas
utiliser un code mef standard...
Tiens par exemple, est-il envisageable de prendre en compte, en plus du
chargement mécanique, un chargement thermique, un mouillage des fibres (et
modification des paramètres physiques)? Et si oui, ne peut-ce pas se faire
par une spécialisation de mes concepts de base? Ma boîte est-elle adepte du
knowledge management :))? Voilà le genre de question qu'il faut que tu te
poses pour savoir si oui ou non tu dois faire de l'objet.
Mais c'est vrai que si tu t'en tiens à ton cahier des charges, pour un code
de calcul mécanique qui tient lieu de petit projet (donc pas une suite
logicielle interfaçable avec tout plein de trucs), c'est souvent surfait.
"YaNn" a écrit dans le message de news:br7rfc$vqt$ (snip)
Voila à quoi je pensais, mais peut être avec des classes est-ce plus concept tout-objet ? j'avoue ne pas être un fan du tout-objet mais s'il faut en passer par la :)
Visiblement, c'est de la méthode elt. finis. Pour ce genre de code de calcul (qui va se ramener au final à l'inversion d'une grosse matrice, donc qqch de fondamentalement orienté procédure), effectivement l'encapsulation est souvent le seul concept "objet" dont on se sert. En gros, si quelqu'un doit prendre la relève du code derrière toi et l'étendre en spécialisant certains concepts de base rentrant en jeu dans la mef (mais je vois pas trop lesquels), ça vaut le coup. Sinon, il vaut mieux faire comme tu le sens toi... D'un autre côté, je me dis que faire de la mécanique des vêtements doit être assez différent de la méca du solide classique. Il doit y avoir une implémentation particulière que l'on attend de toi. Sinon, pourquoi ne pas utiliser un code mef standard...
Tiens par exemple, est-il envisageable de prendre en compte, en plus du chargement mécanique, un chargement thermique, un mouillage des fibres (et modification des paramètres physiques)? Et si oui, ne peut-ce pas se faire par une spécialisation de mes concepts de base? Ma boîte est-elle adepte du knowledge management :))? Voilà le genre de question qu'il faut que tu te poses pour savoir si oui ou non tu dois faire de l'objet. Mais c'est vrai que si tu t'en tiens à ton cahier des charges, pour un code de calcul mécanique qui tient lieu de petit projet (donc pas une suite logicielle interfaçable avec tout plein de trucs), c'est souvent surfait.
Fonzy
Pierre Maurette
"Le Géant Vert" a écrit .. [...]
tout pareil que Marc ; une struct n'étant qu'un classe simplifiée (tous les
champs publics, etc.), une classe et une struct contenant les memes éléments
devraient donner un code tout à fait similaire en terme de temps d'exécution. Il me semble également, et sur les implémentations auxquelles j'ai accès
(x86), c'est certain. La "complication" est à la compilation. De façon très simplifiée : A l'exécution, il y a peut-être des cas particuliers, mais une instance de classe est équivalente à l'instance d'une structure qui serait la classe réduite à ses données, publiques ou privées, non statiques. On accède à ces données par l'adresse de l'instance décalée d'un offset ne dépendant que de la donnée. Donc, en termes de performances, on peut penser que Classe ou Structure (même structure "à la C"), c'est du kif. Les méthodes, statiques ou pas, n'existent qu'une fois en mémoire. J'imagine que les méthodes non statiques utilisent le pointeur d'instance (this). Pour une méthode non statique, on écrit NomInstance.Methode(...), mais j'imagine un truc genre NomClasse::Methode(this,...).
pour ma part, dans un tel cas je privélégierai des classes avec des membres
privates et des getters publics inline ; juste histoire de rester dans le concept objet en fournissant une interface de manipulation pour l'utlisateur. Oui, ou alors peut-être :
* Conserver vos données private. * Ecrire les getter/setter pour les accès non critiques. * Centraliser les traitements critiques (devant être rapides) dans une classe ou une fonction déclarée friend dans la classe de vos données. Cordialemnt, Pierre
"Le Géant Vert" <_NOSPAM_legeantvert@tiscali.fr> a écrit ..
[...]
tout pareil que Marc ; une struct n'étant qu'un classe simplifiée (tous
les
champs publics, etc.), une classe et une struct contenant les memes
éléments
devraient donner un code tout à fait similaire en terme de temps
d'exécution.
Il me semble également, et sur les implémentations auxquelles j'ai accès
(x86), c'est certain.
La "complication" est à la compilation. De façon très simplifiée :
A l'exécution, il y a peut-être des cas particuliers, mais une instance de
classe est équivalente à l'instance d'une structure qui serait la classe
réduite à ses données, publiques ou privées, non statiques.
On accède à ces données par l'adresse de l'instance décalée d'un offset ne
dépendant que de la donnée.
Donc, en termes de performances, on peut penser que Classe ou Structure
(même structure "à la C"), c'est du kif.
Les méthodes, statiques ou pas, n'existent qu'une fois en mémoire. J'imagine
que les méthodes non statiques utilisent le pointeur d'instance (this). Pour
une méthode non statique, on écrit NomInstance.Methode(...), mais j'imagine
un truc genre NomClasse::Methode(this,...).
pour ma part, dans un tel cas je privélégierai des classes avec des
membres
privates et des getters publics inline ; juste histoire de rester dans le
concept objet en fournissant une interface de manipulation pour
l'utlisateur.
Oui, ou alors peut-être :
* Conserver vos données private.
* Ecrire les getter/setter pour les accès non critiques.
* Centraliser les traitements critiques (devant être rapides) dans une
classe
ou une fonction déclarée friend dans la classe de vos données.
Cordialemnt,
Pierre
tout pareil que Marc ; une struct n'étant qu'un classe simplifiée (tous les
champs publics, etc.), une classe et une struct contenant les memes éléments
devraient donner un code tout à fait similaire en terme de temps d'exécution. Il me semble également, et sur les implémentations auxquelles j'ai accès
(x86), c'est certain. La "complication" est à la compilation. De façon très simplifiée : A l'exécution, il y a peut-être des cas particuliers, mais une instance de classe est équivalente à l'instance d'une structure qui serait la classe réduite à ses données, publiques ou privées, non statiques. On accède à ces données par l'adresse de l'instance décalée d'un offset ne dépendant que de la donnée. Donc, en termes de performances, on peut penser que Classe ou Structure (même structure "à la C"), c'est du kif. Les méthodes, statiques ou pas, n'existent qu'une fois en mémoire. J'imagine que les méthodes non statiques utilisent le pointeur d'instance (this). Pour une méthode non statique, on écrit NomInstance.Methode(...), mais j'imagine un truc genre NomClasse::Methode(this,...).
pour ma part, dans un tel cas je privélégierai des classes avec des membres
privates et des getters publics inline ; juste histoire de rester dans le concept objet en fournissant une interface de manipulation pour l'utlisateur. Oui, ou alors peut-être :
* Conserver vos données private. * Ecrire les getter/setter pour les accès non critiques. * Centraliser les traitements critiques (devant être rapides) dans une classe ou une fonction déclarée friend dans la classe de vos données. Cordialemnt, Pierre
Loïc Joly
Marc Boyer wrote:
Marc Boyer wrote:
Les mots "class" et "struct" ne changent à ma connaissance que des question de visibilité. Hormis les questions d'héritage, on a struct X { <=> class X { public:
J'ajoute qu'il y a ce que dit la norme et les conventions de nommage, et que quelqu'un qui met des fonctions virtuelles à une "struct", c'est un peu comme quelqu'un qui nomme authorName une variable de type float: il a intérêt à avoir une bonne raison.
Une des raison qui m'a déjà poussé à faire ça, c'est quand je poste u bout de code dans un newsgroup, je vois un fort avantage à la briéveté, et quand je connais suffisemment les autres contributeurs du thread pour savoir que ça ne les dérangera pas, j'ai tendance à écrire struct A : B {} plutôt que struct A : public B { public:}.
Mais dans du vrai code, c'est différent.
-- Loïc
Marc Boyer wrote:
Marc Boyer wrote:
Les mots "class" et "struct" ne changent à ma connaissance que
des question de visibilité. Hormis les questions d'héritage,
on a
struct X { <=> class X { public:
J'ajoute qu'il y a ce que dit la norme et les conventions
de nommage, et que quelqu'un qui met des fonctions virtuelles
à une "struct", c'est un peu comme quelqu'un qui nomme
authorName une variable de type float: il a intérêt
à avoir une bonne raison.
Une des raison qui m'a déjà poussé à faire ça, c'est quand je poste u
bout de code dans un newsgroup, je vois un fort avantage à la briéveté,
et quand je connais suffisemment les autres contributeurs du thread pour
savoir que ça ne les dérangera pas, j'ai tendance à écrire struct A : B
{} plutôt que struct A : public B { public:}.
Les mots "class" et "struct" ne changent à ma connaissance que des question de visibilité. Hormis les questions d'héritage, on a struct X { <=> class X { public:
J'ajoute qu'il y a ce que dit la norme et les conventions de nommage, et que quelqu'un qui met des fonctions virtuelles à une "struct", c'est un peu comme quelqu'un qui nomme authorName une variable de type float: il a intérêt à avoir une bonne raison.
Une des raison qui m'a déjà poussé à faire ça, c'est quand je poste u bout de code dans un newsgroup, je vois un fort avantage à la briéveté, et quand je connais suffisemment les autres contributeurs du thread pour savoir que ça ne les dérangera pas, j'ai tendance à écrire struct A : B {} plutôt que struct A : public B { public:}.
Mais dans du vrai code, c'est différent.
-- Loïc
YaNn
Pierre Maurette wrote:
Oui, ou alors peut-être : * Conserver vos données private. * Ecrire les getter/setter pour les accès non critiques. * Centraliser les traitements critiques (devant être rapides) dans une classe ou une fonction déclarée friend dans la classe de vos données. Cordialemnt, Pierre
Pourriez vous me detailler cette approche s'il vous plait, j'avoue etre intrigué :)
merci d'avance
Pierre Maurette wrote:
Oui, ou alors peut-être :
* Conserver vos données private.
* Ecrire les getter/setter pour les accès non critiques.
* Centraliser les traitements critiques (devant être rapides) dans une
classe
ou une fonction déclarée friend dans la classe de vos données.
Cordialemnt,
Pierre
Pourriez vous me detailler cette approche s'il vous plait, j'avoue etre
intrigué :)
Oui, ou alors peut-être : * Conserver vos données private. * Ecrire les getter/setter pour les accès non critiques. * Centraliser les traitements critiques (devant être rapides) dans une classe ou une fonction déclarée friend dans la classe de vos données. Cordialemnt, Pierre
Pourriez vous me detailler cette approche s'il vous plait, j'avoue etre intrigué :)
