Discussion :

[ManusDei]

Bonjour,

j'ai résolu un petit problème que j'avais, mais je ne comprend pas pourquoi.

J'ai deux version du même code, une version pour Linux et une version pour Windows.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
#if defined(__LINUX)
class SystemInStream: public io::UnixInStream {
protected:
	friend class System;
	inline SystemInStream(int fd): UnixInStream(fd) { }
	inline ~SystemInStream(void) { }
};
#elif defined(__WIN32) || defined(__WIN64)
class SystemInStream: public io::WinInStream {
protected:
	friend class System;
public:
	inline SystemInStream(HANDLE fd): WinInStream(WinInStream::fd()) { }
	inline ~SystemInStream(void) { }
};
#endif

La seule différence entre les deux est que sous la version windows, j'ai dû mettre les fonctions en public au lieu de protected (sinon mingw-gcc refusait la compilation, parce que c'était en protected).

Pourquoi ? Y a t'il une différence entre public et protected selon que l'on est sous Windows ou sous Linux (et pourquoi donc ?) ?

[Klaim]

protected, public et private n'ont rien de dépendant à l'OS ni même au compilateur.

En revanche la "vrai" différence entre tes deux codes c'est le handle/int qui est différent selon l'os puisque c'est justement à utiliser avec les api de l'os.

Donc théoriquement, tu pourrais avoir les mêmes protected/private/public dans les deux, SI le code qui manipule cet objet est le même quel que soit la plateforme. Si ce n'est pas le cas, vérifie le code d'appel voir si lui aussi il ne serait pas spécifique à la plateforme.

Dans tous les cas, ici c'est le type du handle qui diffère. Les macro de plateforme sont utiles pour ce genre de chose.

[3DArchi]

Bonjour,
Je suis surpris par le nom de tes classes et l'héritage mis en œuvre. Je me serais attendu
=> soit à un héritage inverse : io::XXXXInStream hérite de SystemInStream car SystemInStream est l'abstraction et io::XXXXInStream son implémentation concrète vers windows (XXX=Win) ou *nix (XXXX=Unix).
=> soit à une composition (ou au pire un héritage privé) SystemInStream étant l'interface s'appuyant io::XXXXInStream pour la réalisation. Mais alors, une approche générique ?

En tout cas, déclarer le destructeur ~SystemInStream inline me semble très certainement une anomalie.

comment bien déclarer son destructeur
inlining de fonctions et fonctions virtuelles

F.A.Q : Pourquoi le destructeur d'une classe de base doit être public et virtuel ou protégé et non virtuel ?

[ManusDei]

@Klaim : effectivement, le code d'appel est spécifique à la plateforme, ça doit venir de là.

@3DArchi : Initialement la partie windows n'était pas prévue (et initialement je connais pas le C++, juste le C ). Possible que ça soit lié à ça, j'avoue que je n'en sais rien vu que je reprend du code déjà fait (WinInStream et UnixInStream héritent toutes deux de InStream.h). Mais j'en parlerais.


En tout cas merci à vous deux pour les réponses.