UNE CLIST 100% COMPATIBLE MFC POUR UNIX...

Commentaire de DeAtHCrAsH le 01/10/2004 21:15:46

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 (:

Shell

Commentaire de FredTachet le 02/10/2004 08:48:22

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+

Commentaire de Kaid le 02/10/2004 13:44:00

"A ma connaissance, Microsoft n'a pas racheter le pingouin"

>> De plus, Unix ne se limite pas à Linux ...

Commentaire de coucou747 le 03/10/2004 11:07:19 administrateur CS

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...

Commentaire de Kirua le 04/10/2004 16:33:09

http://www.cplusplus.com/doc/tutorial/tut5-1.html

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.

Commentaire de Kirua le 04/10/2004 18:57:39

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.

Commentaire de magic_Nono le 08/10/2004 20:06:43

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.