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.
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 :(
Mais si ton compilateur n'inline pas quelque chose d'aussi simple, tu seras toujours à même de changer de compilateur ou de définir une macro, ou de faire un rechercher/remplacer pour faire un acces direct.
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 :)
Mon sentiment, juste avec ces lignes et sans autre forme d'analyse, c'est qu'on s'attend oui à ce que Node soit une "structure" (tout public), mais dans SpringSystem, je laisserais privé. Histoire de pouvoir passer d'un pointeur brut à une std::map par exemple, ou un std::vector.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
In article <br7rfc$vqt$1@news-reader3.wanadoo.fr>, YaNn wrote:
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 :(
Mais si ton compilateur n'inline pas quelque chose d'aussi
simple, tu seras toujours à même de changer de compilateur
ou de définir une macro, ou de faire un rechercher/remplacer
pour faire un acces direct.
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 :)
Mon sentiment, juste avec ces lignes et sans autre forme d'analyse,
c'est qu'on s'attend oui à ce que Node soit une "structure" (tout public),
mais dans SpringSystem, je laisserais privé. Histoire de pouvoir
passer d'un pointeur brut à une std::map par exemple, ou un std::vector.
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
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 :(
Mais si ton compilateur n'inline pas quelque chose d'aussi simple, tu seras toujours à même de changer de compilateur ou de définir une macro, ou de faire un rechercher/remplacer pour faire un acces direct.
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 :)
Mon sentiment, juste avec ces lignes et sans autre forme d'analyse, c'est qu'on s'attend oui à ce que Node soit une "structure" (tout public), mais dans SpringSystem, je laisserais privé. Histoire de pouvoir passer d'un pointeur brut à une std::map par exemple, ou un std::vector.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Loïc Joly
Pierre Maurette wrote:
* Getters/Setters sont facultatifs. Mais il vaut mieux AMHA les mettre systématiquement. De toutes façons, inline et non utilisés, ils ne prendront pas beaucoup de place ;-)
AMA, il vaut mieux les éviter, et ne mettre que les fonctions que l'analyse a jugées utiles.
-- Loïc
Pierre Maurette wrote:
* Getters/Setters sont facultatifs. Mais il vaut mieux AMHA les mettre
systématiquement. De toutes façons, inline et non utilisés, ils ne prendront
pas beaucoup de place ;-)
AMA, il vaut mieux les éviter, et ne mettre que les fonctions que
l'analyse a jugées utiles.
* Getters/Setters sont facultatifs. Mais il vaut mieux AMHA les mettre systématiquement. De toutes façons, inline et non utilisés, ils ne prendront pas beaucoup de place ;-)
AMA, il vaut mieux les éviter, et ne mettre que les fonctions que l'analyse a jugées utiles.
