[Copie d'un message sur fr.comp.lang.c]
Bon, je sais, c'est une question de débutant, mais bon... je n'arrive
pas à trouver de réponses pertinentes sur internet ou dans la FAQ.
En gros, j'hésite à passer au langage C (je maîtrise bien GW Basic,
Turbo Pascal, PHP et quelques autres langages). Et j'hésite entre C et
C++... Je ne trouve pas de comparatif "pertinent" au sens ou je l'entend
(i.e.
pour débutant !), donc je me permets de poser quelques questions simples,
dont les réponses me permettront de choisir :
- quelle est la différence entre C et C++, "à part" que C++ permet la
programmation orientée objet ?
- peut-on programmer en C++ sans se servir dans l'immédiat de la
programmation orientée objet (autrement dit, apprendre progressivement, mais
juste sous C++) ?
- quel compliateur choisir (sur quels critères se baser ?) ? J'ai
téléchargé sans les installer Dév-C++ et MS Visual C++ 2005 Express
(gratuits).
En fait, mon objectif à court terme est de faire un programme spécifique
(évolutif et assez complexe) avec une interface graphique et une base de
données (j'ai l'habitude en PHP) :
- est-ce qu'il est possible (autrement dit pas trop complexe pour
quelqu'un qui débute avec ce langage), en C ou en C++, de faire "sa" base de
données avec des fichiers texte (sans se servir de SQL ou autres) ?
- pour les interfaces graphiques, d'après ce que j'ai lu, on en revient
toujours à l'OS, et puis ce n'est pas le sujet du forum, etc. Néanmoins, je
ne vois pas bien "comment" on peut s'occuper d'une interface graphique : par
l'intégration d'une bibliothèque spécifique ? Pour Windows, y en a-t-il une
qui soit relativement simple d'abord, ou, à défaut, quelle est la plus
répandue (et libre) ?
Tu es en train de me dire quelque chose comme "On peut déclarer une fonction membre en C, puisqu'on peut la déclarer en C++"...
Non.
-- John Deuf
Fabien LE LEZ
On 12 Jul 2006 16:00:43 GMT, John Deuf :
Si je ne me trompe, .Net n'est pas accessible depuis C++.
Je ne veux pas relancer le troll C++/CLI, mais oui c'est bien ce que j'entendais par "accessible en C++".
Bon, reprenons dans l'ordre. L'API .Net est bien accessible depuis le langage C++/CLI, qui est un nouveau langage, basé sur C++ (tout comme C++ est basé sur C). Tout ça est très joli, mais ça ne dit rien sur le langage C++ en lui même.
On 12 Jul 2006 16:00:43 GMT, John Deuf <nomail@dontuseit.com>:
Si je ne me trompe, .Net n'est pas accessible depuis C++.
Je ne veux pas relancer le troll C++/CLI, mais oui c'est bien ce que
j'entendais par "accessible en C++".
Bon, reprenons dans l'ordre.
L'API .Net est bien accessible depuis le langage C++/CLI, qui est un
nouveau langage, basé sur C++ (tout comme C++ est basé sur C).
Tout ça est très joli, mais ça ne dit rien sur le langage C++ en lui
même.
Si je ne me trompe, .Net n'est pas accessible depuis C++.
Je ne veux pas relancer le troll C++/CLI, mais oui c'est bien ce que j'entendais par "accessible en C++".
Bon, reprenons dans l'ordre. L'API .Net est bien accessible depuis le langage C++/CLI, qui est un nouveau langage, basé sur C++ (tout comme C++ est basé sur C). Tout ça est très joli, mais ça ne dit rien sur le langage C++ en lui même.
Remi THOMAS
"John Deuf" écrivit
Pour faire de la base de donnée en fichier texte c'est dans les classes natives en C#, grace aux DataTables qui se serialisent en XML (ne pas dépasser 10000 lignes).
Je ne sais pas si on peut dire qu'elles sont natives au C#. Elles font surtout partie de .Net, qui est la nouvelle API Windows. Ce n'est donc pas specifique au C#, puisqu'elles sont aussi accessibles avec d'autres langages (dont C++).
Exact, j'ai glissé.
Le code complet pour créer une base XML et la relire cela donne: C# et Java offrent une syntaxe bien plus concise.
Je ne vais pas essayer juste pour te contredire, mais avec Boost Serialization, on doit le faire avec autant de lignes sinon moins. Voir les exemples dans la doc Boost. (Et Boost est quand meme l'antichambre du C++ standard.)
Un petit copié/collé ici cela serait super.
Je pratique régulièrement C++ mais il faut bien reconnaître que C# est plus moderne que C++ dans 99% des problématiques.
Je ne crois pas que la modernite d'un langage se resume a la longueur du code necessaire a une tache precise.
Non mais ne plus avoir un .H et un .CPP à synchroniser c'est tellement reposant.
La reflection permet de faire des choses impossibles en C++ Regarder le dernier exemple sur cette page. http://codyx.org/snippet_serialisation-deserialisation-objet-vers-xml_2.aspx
Rémi
"John Deuf" écrivit
Pour faire de la base de donnée en fichier texte c'est dans les
classes natives en C#, grace aux DataTables qui se serialisent en XML
(ne pas dépasser 10000 lignes).
Je ne sais pas si on peut dire qu'elles sont natives au C#.
Elles font surtout partie de .Net, qui est la nouvelle API Windows. Ce
n'est donc pas specifique au C#, puisqu'elles sont aussi accessibles avec
d'autres langages (dont C++).
Exact, j'ai glissé.
Le code complet pour créer une base XML et la relire cela donne:
C# et Java offrent une syntaxe bien plus concise.
Je ne vais pas essayer juste pour te contredire, mais avec Boost
Serialization, on doit le faire avec autant de lignes sinon moins.
Voir les exemples dans la doc Boost.
(Et Boost est quand meme l'antichambre du C++ standard.)
Un petit copié/collé ici cela serait super.
Je pratique régulièrement C++ mais il faut bien reconnaître que C# est
plus moderne que C++ dans 99% des problématiques.
Je ne crois pas que la modernite d'un langage se resume a la longueur du
code necessaire a une tache precise.
Non mais ne plus avoir un .H et un .CPP à synchroniser c'est tellement
reposant.
La reflection permet de faire des choses impossibles en C++
Regarder le dernier exemple sur cette page.
http://codyx.org/snippet_serialisation-deserialisation-objet-vers-xml_2.aspx
Pour faire de la base de donnée en fichier texte c'est dans les classes natives en C#, grace aux DataTables qui se serialisent en XML (ne pas dépasser 10000 lignes).
Je ne sais pas si on peut dire qu'elles sont natives au C#. Elles font surtout partie de .Net, qui est la nouvelle API Windows. Ce n'est donc pas specifique au C#, puisqu'elles sont aussi accessibles avec d'autres langages (dont C++).
Exact, j'ai glissé.
Le code complet pour créer une base XML et la relire cela donne: C# et Java offrent une syntaxe bien plus concise.
Je ne vais pas essayer juste pour te contredire, mais avec Boost Serialization, on doit le faire avec autant de lignes sinon moins. Voir les exemples dans la doc Boost. (Et Boost est quand meme l'antichambre du C++ standard.)
Un petit copié/collé ici cela serait super.
Je pratique régulièrement C++ mais il faut bien reconnaître que C# est plus moderne que C++ dans 99% des problématiques.
Je ne crois pas que la modernite d'un langage se resume a la longueur du code necessaire a une tache precise.
Non mais ne plus avoir un .H et un .CPP à synchroniser c'est tellement reposant.
La reflection permet de faire des choses impossibles en C++ Regarder le dernier exemple sur cette page. http://codyx.org/snippet_serialisation-deserialisation-objet-vers-xml_2.aspx
Rémi
Sylvain
Remi THOMAS wrote on 14/07/2006 21:00:
La reflection permet de faire des choses impossibles en C++ Regarder le dernier exemple sur cette page. http://codyx.org/snippet_serialisation-deserialisation-objet-vers-xml_2.aspx
l'exemple indiqué ne traite que de sérialisation, absolument pas de réflection (qui commencerait par un serializer non spécifiquement initialisé avec un typeof de l'unique classe à gérer - qui miracle heureux arrive à être relue, waouh !).
les infos RTTI du C++ participent à un début de réflection, d'autres langages vont plus loin que C++, soit, parler d'impossibilité ne me parait pas fondé pour autant.
Sylvain.
Remi THOMAS wrote on 14/07/2006 21:00:
La reflection permet de faire des choses impossibles en C++
Regarder le dernier exemple sur cette page.
http://codyx.org/snippet_serialisation-deserialisation-objet-vers-xml_2.aspx
l'exemple indiqué ne traite que de sérialisation, absolument pas de
réflection (qui commencerait par un serializer non spécifiquement
initialisé avec un typeof de l'unique classe à gérer - qui miracle
heureux arrive à être relue, waouh !).
les infos RTTI du C++ participent à un début de réflection, d'autres
langages vont plus loin que C++, soit, parler d'impossibilité ne me
parait pas fondé pour autant.
La reflection permet de faire des choses impossibles en C++ Regarder le dernier exemple sur cette page. http://codyx.org/snippet_serialisation-deserialisation-objet-vers-xml_2.aspx
l'exemple indiqué ne traite que de sérialisation, absolument pas de réflection (qui commencerait par un serializer non spécifiquement initialisé avec un typeof de l'unique classe à gérer - qui miracle heureux arrive à être relue, waouh !).
les infos RTTI du C++ participent à un début de réflection, d'autres langages vont plus loin que C++, soit, parler d'impossibilité ne me parait pas fondé pour autant.
Sylvain.
Remi THOMAS
l'exemple indiqué ne traite que de sérialisation, absolument pas de réflection (qui commencerait par un serializer non spécifiquement initialisé avec un typeof de l'unique classe à gérer - qui miracle heureux arrive à être relue, waouh !).
C'est bien un exemple de reflection car le serializer XML va te générer un fichier avec le nom de tes variables membres. Ce n'est pas un "dump" mémoire de l'objet. Tu peux d'ailleur utiliser l'attribut [XmlAttribute] pour préciser comment est exprimé la valeur dans le XML, exclure des variables avec [XmlIgnore], renommer... Le super avantage de cela est de pouvoir modifier tes classes et utiliser quand même les "anciens" fichiers XML.
Par exemple
public class ReportCapture { public List<ReportElementMain> elementsMain = new List<ReportElementMain>(); public List<ReportElement> elements = new List<ReportElement>(); public List<ReportGraph> graph = new List<ReportGraph>(); [XmlAttribute] public DateTime date = DateTime.Now; [XmlAttribute] public string name; [XmlAttribute] public string type; }
les infos RTTI du C++ participent à un début de réflection, d'autres langages vont plus loin que C++, soit, parler d'impossibilité ne me parait pas fondé pour autant.
.NET est 100% auto descriptif, cela veut dire que tu possèdes le code source ou non d'une bibliothèque, tu peux faire exactement la même chose (charger une assembly (ou DLL), énumérer ses classes, instancier, invoquer.) De toute façon le mécanisme de réflection n'utilise pas le code source.
Le problème de C++ dans ce domaine c'est la multitude des ses implémentations qui rende la chose assez difficile (8, 16, 32, 64 bits, little, big endian...). .NET s'en sort car il génère du pcode normalisé, c'est la machine virtuelle (ou CLR) spécifique au processeur qui s'occupe de compiler et exécuter.
Rémi
l'exemple indiqué ne traite que de sérialisation, absolument pas de
réflection (qui commencerait par un serializer non spécifiquement
initialisé avec un typeof de l'unique classe à gérer - qui miracle
heureux arrive à être relue, waouh !).
C'est bien un exemple de reflection car le serializer XML va te générer
un fichier avec le nom de tes variables membres. Ce n'est pas un "dump"
mémoire de l'objet.
Tu peux d'ailleur utiliser l'attribut [XmlAttribute] pour préciser
comment est exprimé la valeur dans le XML, exclure des variables avec
[XmlIgnore], renommer...
Le super avantage de cela est de pouvoir modifier tes classes et
utiliser quand même les "anciens" fichiers XML.
Par exemple
public class ReportCapture
{
public List<ReportElementMain> elementsMain = new List<ReportElementMain>();
public List<ReportElement> elements = new List<ReportElement>();
public List<ReportGraph> graph = new List<ReportGraph>();
[XmlAttribute]
public DateTime date = DateTime.Now;
[XmlAttribute]
public string name;
[XmlAttribute]
public string type;
}
les infos RTTI du C++ participent à un début de réflection, d'autres
langages vont plus loin que C++, soit, parler d'impossibilité ne me
parait pas fondé pour autant.
.NET est 100% auto descriptif, cela veut dire que tu possèdes le code
source ou non d'une bibliothèque, tu peux faire exactement la même chose
(charger une assembly (ou DLL), énumérer ses classes, instancier, invoquer.)
De toute façon le mécanisme de réflection n'utilise pas le code source.
Le problème de C++ dans ce domaine c'est la multitude des ses
implémentations qui rende la chose assez difficile (8, 16, 32, 64 bits,
little, big endian...). .NET s'en sort car il génère du pcode normalisé,
c'est la machine virtuelle (ou CLR) spécifique au processeur qui
s'occupe de compiler et exécuter.
l'exemple indiqué ne traite que de sérialisation, absolument pas de réflection (qui commencerait par un serializer non spécifiquement initialisé avec un typeof de l'unique classe à gérer - qui miracle heureux arrive à être relue, waouh !).
C'est bien un exemple de reflection car le serializer XML va te générer un fichier avec le nom de tes variables membres. Ce n'est pas un "dump" mémoire de l'objet. Tu peux d'ailleur utiliser l'attribut [XmlAttribute] pour préciser comment est exprimé la valeur dans le XML, exclure des variables avec [XmlIgnore], renommer... Le super avantage de cela est de pouvoir modifier tes classes et utiliser quand même les "anciens" fichiers XML.
Par exemple
public class ReportCapture { public List<ReportElementMain> elementsMain = new List<ReportElementMain>(); public List<ReportElement> elements = new List<ReportElement>(); public List<ReportGraph> graph = new List<ReportGraph>(); [XmlAttribute] public DateTime date = DateTime.Now; [XmlAttribute] public string name; [XmlAttribute] public string type; }
les infos RTTI du C++ participent à un début de réflection, d'autres langages vont plus loin que C++, soit, parler d'impossibilité ne me parait pas fondé pour autant.
.NET est 100% auto descriptif, cela veut dire que tu possèdes le code source ou non d'une bibliothèque, tu peux faire exactement la même chose (charger une assembly (ou DLL), énumérer ses classes, instancier, invoquer.) De toute façon le mécanisme de réflection n'utilise pas le code source.
Le problème de C++ dans ce domaine c'est la multitude des ses implémentations qui rende la chose assez difficile (8, 16, 32, 64 bits, little, big endian...). .NET s'en sort car il génère du pcode normalisé, c'est la machine virtuelle (ou CLR) spécifique au processeur qui s'occupe de compiler et exécuter.
Rémi
Sylvain
Remi THOMAS wrote on 15/07/2006 08:54:
C'est bien un exemple de reflection car le serializer XML va te générer un fichier avec le nom de tes variables membres. Ce n'est pas un "dump" mémoire de l'objet.
alors soit, on s'attendait à cela pour être 'XML' mais l'article aurait pu insérer le fichier généré.
Tu peux d'ailleur utiliser l'attribut [XmlAttribute] pour préciser comment est exprimé la valeur dans le XML, exclure des variables avec [XmlIgnore], renommer...
'transient' est pas mal non plus.
Le super avantage de cela est de pouvoir modifier tes classes et utiliser quand même les "anciens" fichiers XML.
la promotion et la valorisation par défaut peuvent être réalisées de mille façons indépendemment du langage.
..NET est 100% auto descriptif, cela veut dire que tu possèdes le code source ou non d'une bibliothèque, tu peux faire exactement la même chose (charger une assembly (ou DLL), énumérer ses classes, instancier, invoquer.)
?! on peut charger une lib. et instancier une classe, soit la moindre reflection; elle intervient si on veux compter le nombre d'instance d'une classe, énumérer ses champs, lister ses méthodes, en énumérer les paramètres formels, etc.
De toute façon le mécanisme de réflection n'utilise pas le code source.
on n'avait pas parlé de code source.
Le problème de C++ dans ce domaine c'est la multitude des ses implémentations qui rende la chose assez difficile (8, 16, 32, 64 bits, little, big endian...).
je ne vois pas de problème à pouvoir générer du code pour µcontroleur 8 bits ou quadri-xéon 64 bits !...
.NET s'en sort car il génère du pcode normalisé, c'est la machine virtuelle (ou CLR) spécifique au processeur qui s'occupe de compiler et exécuter.
aucun rapport avec la reflection, mais tu as bien fait de mettre 'processeur' au singulier ;)
Sylvain.
Remi THOMAS wrote on 15/07/2006 08:54:
C'est bien un exemple de reflection car le serializer XML va te générer
un fichier avec le nom de tes variables membres. Ce n'est pas un "dump"
mémoire de l'objet.
alors soit, on s'attendait à cela pour être 'XML' mais l'article aurait
pu insérer le fichier généré.
Tu peux d'ailleur utiliser l'attribut [XmlAttribute] pour préciser
comment est exprimé la valeur dans le XML, exclure des variables avec
[XmlIgnore], renommer...
'transient' est pas mal non plus.
Le super avantage de cela est de pouvoir modifier tes classes et
utiliser quand même les "anciens" fichiers XML.
la promotion et la valorisation par défaut peuvent être réalisées de
mille façons indépendemment du langage.
..NET est 100% auto descriptif, cela veut dire que tu possèdes le code
source ou non d'une bibliothèque, tu peux faire exactement la même chose
(charger une assembly (ou DLL), énumérer ses classes, instancier,
invoquer.)
?! on peut charger une lib. et instancier une classe, soit la moindre
reflection; elle intervient si on veux compter le nombre d'instance
d'une classe, énumérer ses champs, lister ses méthodes, en énumérer les
paramètres formels, etc.
De toute façon le mécanisme de réflection n'utilise pas le code source.
on n'avait pas parlé de code source.
Le problème de C++ dans ce domaine c'est la multitude des ses
implémentations qui rende la chose assez difficile (8, 16, 32, 64 bits,
little, big endian...).
je ne vois pas de problème à pouvoir générer du code pour µcontroleur 8
bits ou quadri-xéon 64 bits !...
.NET s'en sort car il génère du pcode normalisé,
c'est la machine virtuelle (ou CLR) spécifique au processeur qui
s'occupe de compiler et exécuter.
aucun rapport avec la reflection, mais tu as bien fait de mettre
'processeur' au singulier ;)
C'est bien un exemple de reflection car le serializer XML va te générer un fichier avec le nom de tes variables membres. Ce n'est pas un "dump" mémoire de l'objet.
alors soit, on s'attendait à cela pour être 'XML' mais l'article aurait pu insérer le fichier généré.
Tu peux d'ailleur utiliser l'attribut [XmlAttribute] pour préciser comment est exprimé la valeur dans le XML, exclure des variables avec [XmlIgnore], renommer...
'transient' est pas mal non plus.
Le super avantage de cela est de pouvoir modifier tes classes et utiliser quand même les "anciens" fichiers XML.
la promotion et la valorisation par défaut peuvent être réalisées de mille façons indépendemment du langage.
..NET est 100% auto descriptif, cela veut dire que tu possèdes le code source ou non d'une bibliothèque, tu peux faire exactement la même chose (charger une assembly (ou DLL), énumérer ses classes, instancier, invoquer.)
?! on peut charger une lib. et instancier une classe, soit la moindre reflection; elle intervient si on veux compter le nombre d'instance d'une classe, énumérer ses champs, lister ses méthodes, en énumérer les paramètres formels, etc.
De toute façon le mécanisme de réflection n'utilise pas le code source.
on n'avait pas parlé de code source.
Le problème de C++ dans ce domaine c'est la multitude des ses implémentations qui rende la chose assez difficile (8, 16, 32, 64 bits, little, big endian...).
je ne vois pas de problème à pouvoir générer du code pour µcontroleur 8 bits ou quadri-xéon 64 bits !...
.NET s'en sort car il génère du pcode normalisé, c'est la machine virtuelle (ou CLR) spécifique au processeur qui s'occupe de compiler et exécuter.
aucun rapport avec la reflection, mais tu as bien fait de mettre 'processeur' au singulier ;)
Sylvain.
John Deuf
Remi THOMAS :
Le code complet pour créer une base XML et la relire cela donne: C# et Java offrent une syntaxe bien plus concise.
Je ne vais pas essayer juste pour te contredire, mais avec Boost Serialization, on doit le faire avec autant de lignes sinon moins. Voir les exemples dans la doc Boost. (Et Boost est quand meme l'antichambre du C++ standard.)
Ce n'est pas avec Boost, c'et avec une autre bibliothèque C++ : http://codesynthesis.com/products/xsd/
-- John Deuf
Remi THOMAS :
Le code complet pour créer une base XML et la relire cela donne:
C# et Java offrent une syntaxe bien plus concise.
Je ne vais pas essayer juste pour te contredire, mais avec Boost
Serialization, on doit le faire avec autant de lignes sinon moins.
Voir les exemples dans la doc Boost.
(Et Boost est quand meme l'antichambre du C++ standard.)
Le code complet pour créer une base XML et la relire cela donne: C# et Java offrent une syntaxe bien plus concise.
Je ne vais pas essayer juste pour te contredire, mais avec Boost Serialization, on doit le faire avec autant de lignes sinon moins. Voir les exemples dans la doc Boost. (Et Boost est quand meme l'antichambre du C++ standard.)
