magic_Nono
Messages postés1878Date d'inscriptionjeudi 16 octobre 2003StatutMembreDernière intervention16 mars 2011 8 oct. 2004 à 20:07
met-> mais
magic_Nono
Messages postés1878Date d'inscriptionjeudi 16 octobre 2003StatutMembreDernière intervention16 mars 2011 8 oct. 2004 à 20:06
Je part du principe que les proto et le corps des fonctions doivent etre ds des fichiers différents
ptet que G tord
ceci dit, le src n'était js inclu ds le prj met en include ds le header ce qui revient au meme
CT juste pour des histoire de gestion standard
chaque fichier est dispatché entre un .hpp ou .h ou .hh
& un .cpp ou .cc
voilu
met effectivement, ça revient au meme
Juste une histoire d'être toujours face au même shémat (but de standardisation)
et il est vrai qu'on est obligé de déroger à cette regle pour les fonctions inline...
Magicalement
Nono.
coucou747
Messages postés12303Date d'inscriptionmardi 10 février 2004StatutMembreDernière intervention30 juillet 201244 4 oct. 2004 à 19:00
merci
cs_Kirua
Messages postés3006Date d'inscriptiondimanche 14 avril 2002StatutMembreDernière intervention31 décembre 2008 4 oct. 2004 à 18:57
souvrir-au-monde.fr ...
en résumé, ça veut dire que qd tu fais des templates, tu dois tt mettre ds le même fichier. pour les raisons et la justification: apprendre l'anglais, ... de tte façon en prog, c'est quasiment un pré-requis.
coucou747
Messages postés12303Date d'inscriptionmardi 10 février 2004StatutMembreDernière intervention30 juillet 201244 4 oct. 2004 à 18:30
translate.com...
cs_Kirua
Messages postés3006Date d'inscriptiondimanche 14 avril 2002StatutMembreDernière intervention31 décembre 2008 4 oct. 2004 à 16:33
Templates and multiple-file projects
From the point of view of the compiler, templates are not normal functions or classes. They are compiled on demand, meaning that the code of a template function is not compiled until an instantiation is required. At that moment, when an instantiation is required, the compiler generates a function specifically for that type from the template.
When projects grow it is usual to split the code of a program in different source files. In these cases, generally the interface and implementation are separated. Taking a library of functions as example, the interface generally consists of the prototypes of all the functions that can be called. These are generally declared in a "header file" with .h extension, and the implementation (the definition of these functions) is in an independent file of c++ code.
The macro-like functionality of templates, forces a restriction for multi-file projects: the implementation (definition) of a template class or function must be in the same file as the declaration. That means we cannot separate the interface in a separate header file and we must include both interface and implementation in any file that uses the templates.
Going back to the library of functions, if we wanted to make a library of function templates, instead of creating a header file (.h) we should create a "template file" with both the interface and implementation of the function templates (there is no convention on the extension for this type of file other than there be no extension at all or to keep the .h). The inclusion more than once of the same template file with both declarations and definitions in a project doesn't generate linkage errors, since they are compiled on demand and compilers that allow templates should be prepared to not generate duplicate code in these cases.
magic_Nono
Messages postés1878Date d'inscriptionjeudi 16 octobre 2003StatutMembreDernière intervention16 mars 2011 4 oct. 2004 à 11:07
à mon avi ce code risque de po marché si le .h est inclus plusieurs fois...avec les mm templates
En gros, met donc des includes ou fait deux fichiers
En clair, ce fichier est une réécriture des BListeIndir avec des fonctions en moins et quelques-unes en plus (personnellement inusitées)
en version MFC ie plutot po pratiq (y a des choses pratiq en MFC mais les CListes...)
++
Nono
_____________________
un truc relevé:
for (; nCount--; pElements++)
pElements->~TYPE();
T sur que ça passe tjs ça...
en tt cas, difficile d'etre moins clair
et l'appel est vraiement curieux... mé ça marche il faut le reconnaitre...
mé un rien de commentaire aurait été bienvenu...
coucou747
Messages postés12303Date d'inscriptionmardi 10 février 2004StatutMembreDernière intervention30 juillet 201244 3 oct. 2004 à 11:07
une centaine de copyleft... le kernel apartient a une centaine de personnes, donc, et donc, pour le vendre, il faudrait que toutes ces personnes veuillent bien le vendre...
plus_plus_fab
Messages postés232Date d'inscriptionvendredi 9 janvier 2004StatutMembreDernière intervention 8 janvier 2005 3 oct. 2004 à 01:54
oui, et mandrake n'est qu'une distribution de Linux ...
coucou747> Le noyau appartient donc à ceux qui on déposé le copyleft, non ?
Je suis completement pour la portabilité, aussi, n'aurait-il pas été plus simple (et plus sur !) d'adapter le code existant en utilisant la classe std::list ?
cs_Kaid
Messages postés949Date d'inscriptionmardi 2 octobre 2001StatutMembreDernière intervention 8 juillet 20061 2 oct. 2004 à 13:44
"A ma connaissance, Microsoft n'a pas racheter le pingouin"
>> De plus, Unix ne se limite pas à Linux ...
coucou747
Messages postés12303Date d'inscriptionmardi 10 février 2004StatutMembreDernière intervention30 juillet 201244 2 oct. 2004 à 11:12
"A ma connaissance, Microsoft n'a pas racheter le pingouin (:" => Linux est inrachetable, il n'apartient à personne, Torvald n'est pas le seul a avoir mis un copyleft sur le kernel, ils sont une centaine, pour que le noyau soit vendu, il faudrait que chacune de ces personne veuille bien le vendre... c'est une philo et une comunauté plus qu'un tas de programme, ce qui explique la vitesse de dévelopement des projets... (mandrake 10.1 est sorti deux mois après la 10.0... on a des linux en 64 bits, alros que windows, c'est encore une béta... plus de logiciels, ect...)
Moi je penses que c'est bien de faire des trucs portables, ou qui aident a porter, plus on a de choix niveau logiciels, plus on a de chance d'en avoir un de bon.
Bon travail
FredTachet
Messages postés1Date d'inscriptionmercredi 11 août 2004StatutMembreDernière intervention 2 octobre 2004 2 oct. 2004 à 08:48
Bravo Kirua, c'est exactement ce que j'explique dans la description de la source... DeAtHCrash, Il aurait fallu lire un peu plus avant de poser une question ...
J'ai juste "porté" un code de base Microsoft qui est pas mal écrit et très pratique pour qu'il puisse passer sur n'importe quel Compilo...
Il existe des produits pour permettre de porter des applis ecrites pour Windows, mais vu le prix, quand on a besoin que de peu de fonctionnalités, autant refaire.
a+
cs_Kirua
Messages postés3006Date d'inscriptiondimanche 14 avril 2002StatutMembreDernière intervention31 décembre 2008 2 oct. 2004 à 03:15
je pense qu'il veut dire que c'est une classe qui permet de compiler un code qui utilise les CList des MFC, car a priori ne devant tourner que sous windows, sous un environnement Unix. tout simplement... de la même manière qu'il y a OpenGL Microsoft, Mesa, et encore un autre là... enfin, c'est juste une implémentation d'exactement la même chose, mais pour un autre environnement.
DeAtHCrAsH
Messages postés2670Date d'inscriptionvendredi 25 janvier 2002StatutMembreDernière intervention 6 février 2013 1 oct. 2004 à 21:15
J'ai pas regardé la source mais rien que le titre ne m'inspire rien qui vaille.
Quote: "Un CLIST compatible MFC pour Unix" ?????
Faut que tu nous expliques la.
MFC = Microsoft Foundation Classes.
A ma connaissance, Microsoft n'a pas racheter le pingouin (:
8 oct. 2004 à 20:07
8 oct. 2004 à 20:06
ptet que G tord
ceci dit, le src n'était js inclu ds le prj met en include ds le header ce qui revient au meme
CT juste pour des histoire de gestion standard
chaque fichier est dispatché entre un .hpp ou .h ou .hh
& un .cpp ou .cc
voilu
met effectivement, ça revient au meme
Juste une histoire d'être toujours face au même shémat (but de standardisation)
et il est vrai qu'on est obligé de déroger à cette regle pour les fonctions inline...
Magicalement
Nono.
4 oct. 2004 à 19:00
4 oct. 2004 à 18:57
en résumé, ça veut dire que qd tu fais des templates, tu dois tt mettre ds le même fichier. pour les raisons et la justification: apprendre l'anglais, ... de tte façon en prog, c'est quasiment un pré-requis.
4 oct. 2004 à 18:30
4 oct. 2004 à 16:33
Templates and multiple-file projects
From the point of view of the compiler, templates are not normal functions or classes. They are compiled on demand, meaning that the code of a template function is not compiled until an instantiation is required. At that moment, when an instantiation is required, the compiler generates a function specifically for that type from the template.
When projects grow it is usual to split the code of a program in different source files. In these cases, generally the interface and implementation are separated. Taking a library of functions as example, the interface generally consists of the prototypes of all the functions that can be called. These are generally declared in a "header file" with .h extension, and the implementation (the definition of these functions) is in an independent file of c++ code.
The macro-like functionality of templates, forces a restriction for multi-file projects: the implementation (definition) of a template class or function must be in the same file as the declaration. That means we cannot separate the interface in a separate header file and we must include both interface and implementation in any file that uses the templates.
Going back to the library of functions, if we wanted to make a library of function templates, instead of creating a header file (.h) we should create a "template file" with both the interface and implementation of the function templates (there is no convention on the extension for this type of file other than there be no extension at all or to keep the .h). The inclusion more than once of the same template file with both declarations and definitions in a project doesn't generate linkage errors, since they are compiled on demand and compilers that allow templates should be prepared to not generate duplicate code in these cases.
4 oct. 2004 à 11:07
En gros, met donc des includes ou fait deux fichiers
En clair, ce fichier est une réécriture des BListeIndir avec des fonctions en moins et quelques-unes en plus (personnellement inusitées)
en version MFC ie plutot po pratiq (y a des choses pratiq en MFC mais les CListes...)
++
Nono
_____________________
un truc relevé:
for (; nCount--; pElements++)
pElements->~TYPE();
T sur que ça passe tjs ça...
en tt cas, difficile d'etre moins clair
et l'appel est vraiement curieux... mé ça marche il faut le reconnaitre...
mé un rien de commentaire aurait été bienvenu...
3 oct. 2004 à 11:07
3 oct. 2004 à 01:54
coucou747> Le noyau appartient donc à ceux qui on déposé le copyleft, non ?
Je suis completement pour la portabilité, aussi, n'aurait-il pas été plus simple (et plus sur !) d'adapter le code existant en utilisant la classe std::list ?
2 oct. 2004 à 13:44
>> De plus, Unix ne se limite pas à Linux ...
2 oct. 2004 à 11:12
Moi je penses que c'est bien de faire des trucs portables, ou qui aident a porter, plus on a de choix niveau logiciels, plus on a de chance d'en avoir un de bon.
Bon travail
2 oct. 2004 à 08:48
J'ai juste "porté" un code de base Microsoft qui est pas mal écrit et très pratique pour qu'il puisse passer sur n'importe quel Compilo...
Il existe des produits pour permettre de porter des applis ecrites pour Windows, mais vu le prix, quand on a besoin que de peu de fonctionnalités, autant refaire.
a+
2 oct. 2004 à 03:15
1 oct. 2004 à 21:15
Quote: "Un CLIST compatible MFC pour Unix" ?????
Faut que tu nous expliques la.
MFC = Microsoft Foundation Classes.
A ma connaissance, Microsoft n'a pas racheter le pingouin (:
Shell