Petite question sur les références
 
quand est-ce que les références ne servent pas?
 
pour un int, l'exemple que plusieurs on se demandait, nous fait il sauver de l'allocation, ca reste pareil que si on faisait un passage par valeur, ou encore c'est pire qu'un passage par valeur?
 
en gros quels sont les cas qu'on ne doit pas utiliser le passage par référence
 
merci encore une fois

Tu veux dire un passage par référence constante ?
 
genre :  

 
Parce que un passage par référence, tu peux modifier ta valeur, alors qu'un passage par valeur, tu ne peux pas.
 
Sinon, pour répondre, dans tous les cas où tu as un type de base (entiers, flottants, pointeurs, bool), un passage par référence constante ne sert à rien ou presque. Dans tous les cas où tu passes un objet (structure, union, classe), ça peut être plus efficace, voire même beaucoup plus efficace (std::string en est un bon exemple, puisque le constructeur de recopie alloue de la mémoire).  
 
Attention, si tu es susceptible de modifier l'objet entre temps (thread ou appel asynchrone), l'utilisation d'une référence peut être dangereux.

 
mouep c'est ca que je veux dire. dans le cas où je dois pas le modifier, bin tu le passe par référence en const
 
mais je voulais savoir exactement, avec quel type on est perdant, avec lesquelles on est égal. (int égal ou perdant? bool égal ou perdant?)
 
merci

bah implicitement, si je dis pas de bêtises, le compilo devrait passer une adresse.
donc c'est moins rentable si le type a une taille plus petite que la taille d'une adresse du cpu. (genre char/short int).
 
ce qui pourrait permetttre de dire que c'est un peu une prise de tête pour rien, c'est que un char ou int ça consomme quand même un registre (la différence se fairait que par rapport à la pile).
 
et que si ta fonction est inlinée, bah on s'en fous, si le compilo optimise bien, c'est transparent car ce n'est que de "l'écriture source".

sans oublier le déréférencement...

pour le inlinée, jsuis pas vraiment au courant de ce que c'est, mais vu que tu viens de le mentionné, je tâcherai de lire un peu sur ca
 
donc je passe par référence sans trop me préocupper du type en me disant que le compilo est pas con
 
merci

avec l'inline, c'est juste que le compilo fusionne tout de manière optimale.
 
par exemple:
 
inline void fadd( int &a, int b)
{
   a+=b;  
}
 
yop()
{
   int c,d;
   cin>>c>>d;
   fadd(c,d);
   cout<<c;
}
 
produira potentiellement le même code machine que:
 
yop()
{
   int c,d;
   cin>>c>>d;
   c+=d;
   cout<<c;
}
 
ce qui permet d'éclater ton code proprement en fonctions isolées, sans avoir les pénalitées d'appel/retour (et le compilo fusionne les instructions et produit un flux optimisé).
 
par exemple dans une classe:
 
class Truc
{
private:
   size_t Size;
public:
  inline size_t GetSize()
  {
    return Size;
  }
};
 
fait que le GetSize() compte comme du beurre (ie pas de coût d'appel/retour de fonction, comme si tu faisais un Truc.Size), et permet de protéger Size.

mais attention l'inilining ne peut fonctionner qu'avec des méthodes de classes implémentées dans la définition de la classe (dans le header quoi), ou des fonctions qui sont dans le même fichier c/cpp (ie le compilo a accès à l'implémentation de toutes les fonctions candidates à l'inlining).

 
En fait, avec VS7, si tu actives le "whole program optimization" l'inlining a une portée plus grande (par contre ca peut te foutre le bronx dans tes objs existants, cf msdn)

 
si seulement... mais malheureusement, la quasi-totalité des implémentations utilisent un constructeur par recopie des std::string qui incrémente un compteur de référence. La mémoire est dupliquée et recopiée uniquement lorsque l'une des référence à la chaine de caractère sous jacente est modifiée.
Dans beaucoup d'utilisations, c'est efficace ; par contre, c'est un plaie dans les applications multithread, car source de nombreux plantages. A manier avec moultes précautions...

As-tu un lien qui parle de ce bronx ?
 
Pour std::string et la COW, le futur semble se tourner vers l'abandon de cette technique vu qu'aparement le standard empêche cette pratique. VC++ >= 7 n'utilise plus le compteur de ref, mais limite le cout d'une allocation grâce à un petit buffer interne de 16 octets qui stocke les petites chaînes.

dans mon cas c'est que pour un petit tp, alors je regarderai une fois que tout sera terminé pour ajouté de l'inline, ca semble bien
 
ca me fera p-e gruger quelques points bonus, j'utilise déjà les vector au lieu de me déclarer un énorme tableau (du genre Segment tab[100000]) lorsqu'il peut n'y avoir que 5 segments

sinon, la pluspart des compilos proposent une option d'auto-inlining.
 

tu genre que t'es pas obligé de mettre tes fonctions en inline, et g++ le fera à chaque fois qu'il en aura l'occasion avant (ou pendant même) sa compilation?
 
interressant

 
ben  
 
http://msdn.microsoft.com/library/ [...] zation.asp
 

Ah okay. J'avais compris que ça pouvais mairdouiller sur ton propre projet.