[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) ?
Je n'ai pas Windows mais les captures d'écran du Gimp sont plutôt prometteuses. http://www.gimp.org/screenshots/
Voir aussi les captures de Gaim : http://www.softpedia.com/progScreenshots/Gaim-for-Windows-Screenshot-6711.html
Remi THOMAS
Quant au langage, sauf si tu veux vraiment faire du C ou C++ je te conseillerais de passer directement à un langage plus 'moderne' genre Java ou C# si tu veux une syntaxe s'approchant du C/C++, ou encore python.
Oh le beau troll... Je veux bien admettre qu'on puisse comparer C++, C# et Java. Mais mettre C dans le même sac, ou dire que C++ est moins moderne[*], c'est assez ridicule.
Bonjour, C# et Java offrent une syntaxe bien plus concise. 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). Le code complet pour créer une base XML et la relire cela donne:
using System; using System.Data;
namespace ConsoleApplication1 { class Program { static void Main(string[] args) { DataTable dbTexte = new DataTable("Ma table"); dbTexte.Columns.Add("Nom", typeof(string)); dbTexte.Columns.Add("Age", typeof(int)); dbTexte.Columns.Add("Mariage", typeof(DateTime));
DataTable db2 = new DataTable(); db2.ReadXml("potes.xml"); foreach (DataRow row2 in db2.Rows) Console.WriteLine("Nom:{0} Age:{1} Mariage:{2}", row2["Nom"], row2["Age"], ((DateTime)row2["Mariage"]).ToShortDateString()); } } }
Je pratique régulièrement C++ mais il faut bien reconnaître que C# est plus moderne que C++ dans 99% des problématiques.
Rémi
Quant au langage, sauf si tu veux vraiment faire du C ou C++ je te
conseillerais de passer directement à un langage plus 'moderne' genre
Java ou C# si tu veux une syntaxe s'approchant du C/C++, ou encore python.
Oh le beau troll...
Je veux bien admettre qu'on puisse comparer C++, C# et Java.
Mais mettre C dans le même sac, ou dire que C++ est moins moderne[*],
c'est assez ridicule.
Bonjour,
C# et Java offrent une syntaxe bien plus concise.
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).
Le code complet pour créer une base XML et la relire cela donne:
using System;
using System.Data;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
DataTable dbTexte = new DataTable("Ma table");
dbTexte.Columns.Add("Nom", typeof(string));
dbTexte.Columns.Add("Age", typeof(int));
dbTexte.Columns.Add("Mariage", typeof(DateTime));
Quant au langage, sauf si tu veux vraiment faire du C ou C++ je te conseillerais de passer directement à un langage plus 'moderne' genre Java ou C# si tu veux une syntaxe s'approchant du C/C++, ou encore python.
Oh le beau troll... Je veux bien admettre qu'on puisse comparer C++, C# et Java. Mais mettre C dans le même sac, ou dire que C++ est moins moderne[*], c'est assez ridicule.
Bonjour, C# et Java offrent une syntaxe bien plus concise. 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). Le code complet pour créer une base XML et la relire cela donne:
using System; using System.Data;
namespace ConsoleApplication1 { class Program { static void Main(string[] args) { DataTable dbTexte = new DataTable("Ma table"); dbTexte.Columns.Add("Nom", typeof(string)); dbTexte.Columns.Add("Age", typeof(int)); dbTexte.Columns.Add("Mariage", typeof(DateTime));
DataTable db2 = new DataTable(); db2.ReadXml("potes.xml"); foreach (DataRow row2 in db2.Rows) Console.WriteLine("Nom:{0} Age:{1} Mariage:{2}", row2["Nom"], row2["Age"], ((DateTime)row2["Mariage"]).ToShortDateString()); } } }
Je pratique régulièrement C++ mais il faut bien reconnaître que C# est plus moderne que C++ dans 99% des problématiques.
Rémi
kanze
Sylvain wrote:
kanze wrote on 10/07/2006 13:41:
quand tu as accepté un ordre d'un client pour 100.000 actions, il faut les livrer au prix du marché au moment qu'il a passé la commande, même si le prix a augmenté dans les jours qui suivent.
t'es sur ?
Oui. Si le client dit qu'il veut acheter aujourd'hui, il achête au prix d'aujourd'hui. On a une certaine souplesse, mais pas beaucoup.
donnes-moi les coord. de ton trader dans ce cas, je vais faire qlq aller-retours sympa !!
CaLyon Cheuvreux. Mais je doute que tu arriveras à avoir des contrats avec de telles garanties. C'est comme partout : plus tu es gros, plus tu peux négocier des avantages. Et nos clients sont les grosses companies d'assurances, etc.
(on passe pas "commmandes" de titres (sauf sur une OP) mais un "ordre").
Sorry. C'est une erreur de traduction : ce sont des « ClientOrder » dans le code. Et vue que les français avec lesquels je travaille parlent de commandes, je supposais que c'était une traduction correcte.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Sylvain wrote:
kanze wrote on 10/07/2006 13:41:
quand tu as accepté un ordre d'un client pour 100.000 actions,
il faut les livrer au prix du marché au moment qu'il a passé la
commande, même si le prix a augmenté dans les jours qui suivent.
t'es sur ?
Oui. Si le client dit qu'il veut acheter aujourd'hui, il achête
au prix d'aujourd'hui. On a une certaine souplesse, mais pas
beaucoup.
donnes-moi les coord. de ton trader dans ce cas, je vais faire
qlq aller-retours sympa !!
CaLyon Cheuvreux. Mais je doute que tu arriveras à avoir des
contrats avec de telles garanties. C'est comme partout : plus
tu es gros, plus tu peux négocier des avantages. Et nos clients
sont les grosses companies d'assurances, etc.
(on passe pas "commmandes" de titres (sauf sur une OP) mais un
"ordre").
Sorry. C'est une erreur de traduction : ce sont des
« ClientOrder » dans le code. Et vue que les français avec
lesquels je travaille parlent de commandes, je supposais que
c'était une traduction correcte.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
quand tu as accepté un ordre d'un client pour 100.000 actions, il faut les livrer au prix du marché au moment qu'il a passé la commande, même si le prix a augmenté dans les jours qui suivent.
t'es sur ?
Oui. Si le client dit qu'il veut acheter aujourd'hui, il achête au prix d'aujourd'hui. On a une certaine souplesse, mais pas beaucoup.
donnes-moi les coord. de ton trader dans ce cas, je vais faire qlq aller-retours sympa !!
CaLyon Cheuvreux. Mais je doute que tu arriveras à avoir des contrats avec de telles garanties. C'est comme partout : plus tu es gros, plus tu peux négocier des avantages. Et nos clients sont les grosses companies d'assurances, etc.
(on passe pas "commmandes" de titres (sauf sur une OP) mais un "ordre").
Sorry. C'est une erreur de traduction : ce sont des « ClientOrder » dans le code. Et vue que les français avec lesquels je travaille parlent de commandes, je supposais que c'était une traduction correcte.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
H. wrote:
James Kanze :
Il y a aussi la structure naturelle des données : une liste "plate" (liste des clients d'une entreprise, par exemple) est bien adaptée aux BdD ; une structure d'arbre (surtout de profondeur non fixée) s'y prêtera vraisemblablement moins.
Ça dépend, mais c'est vrai qu'on pourrait lui préférer une base hièrarchique à une base relationnelle. Disons LDAP.
Oui, c'est exactement dans ce cas que je me trouve : une structure d'arbre. J'arrive à le faire avec PHP/MySQL, mais c'est vrai que la syntaxe des SELECT devient vite assez lourdre (trop lourde à mon goût ; et ce n'e st pas un problème de programmation, mais un problème lié à mon programm e, parce que les requêtes SELECT dépendent - "plus" que d'habitude - des utilisateurs).
Beaucoup dépend aussi des critères de sélection. LDAP offre une solution parfaitement générique, mais évidemment, il faut avoir accès à une base LDAP. (Il existe des implémentations libres et gratuites de LDAP, mais il faut toujours que tu y ajoutes la gestion de la base même.) Si la sélection est toujours par clé principale à chaque niveau (scope = baseObject, filter = present en termes d'LDAP), et que les données sont toujours locales, une hièrarchie de répertoires pourrait éventuellement servir, au moins si le nombre d'entrées à chaque niveau n'est pas trop grand.
C'est la deuxième raison (la première étant les problèmes de déploiement) qui me poussent à chercher une autre solution que SQL. Une idée ??
Pour des petites bases, où il n'a qu'une seule clé d'accès par niveau, je me suis servi des hièrarchies de répertoires Unix. Dans un cas, au moins, avec toutes les données réeles encodées dans les noms de fichier ; l'utilitaire « find » me faisait alors pratiquement tout ce que pourrait faire une base LDAP. Mais il vaut mieux que la base soit petite, et qu'il n'y a pas trop de requêtes à la fois non plus, parce que c'est une solution qui ne brille pas par ces performances.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
H. wrote:
James Kanze :
Il y a aussi la structure naturelle des données : une
liste "plate" (liste des clients d'une entreprise, par
exemple) est bien adaptée aux BdD ; une structure d'arbre
(surtout de profondeur non fixée) s'y prêtera
vraisemblablement moins.
Ça dépend, mais c'est vrai qu'on pourrait lui préférer une
base hièrarchique à une base relationnelle. Disons LDAP.
Oui, c'est exactement dans ce cas que je me trouve : une structure
d'arbre.
J'arrive à le faire avec PHP/MySQL, mais c'est vrai que la syntaxe des
SELECT devient vite assez lourdre (trop lourde à mon goût ; et ce n'e st pas
un problème de programmation, mais un problème lié à mon programm e, parce
que les requêtes SELECT dépendent - "plus" que d'habitude - des
utilisateurs).
Beaucoup dépend aussi des critères de sélection. LDAP offre une
solution parfaitement générique, mais évidemment, il faut avoir
accès à une base LDAP. (Il existe des implémentations libres et
gratuites de LDAP, mais il faut toujours que tu y ajoutes la
gestion de la base même.) Si la sélection est toujours par clé
principale à chaque niveau (scope = baseObject, filter = present
en termes d'LDAP), et que les données sont toujours locales, une
hièrarchie de répertoires pourrait éventuellement servir, au
moins si le nombre d'entrées à chaque niveau n'est pas trop
grand.
C'est la deuxième raison (la première étant les problèmes de
déploiement) qui me poussent à chercher une autre solution que SQL.
Une idée ??
Pour des petites bases, où il n'a qu'une seule clé d'accès par
niveau, je me suis servi des hièrarchies de répertoires Unix.
Dans un cas, au moins, avec toutes les données réeles encodées
dans les noms de fichier ; l'utilitaire « find » me faisait
alors pratiquement tout ce que pourrait faire une base LDAP.
Mais il vaut mieux que la base soit petite, et qu'il n'y a pas
trop de requêtes à la fois non plus, parce que c'est une
solution qui ne brille pas par ces performances.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Il y a aussi la structure naturelle des données : une liste "plate" (liste des clients d'une entreprise, par exemple) est bien adaptée aux BdD ; une structure d'arbre (surtout de profondeur non fixée) s'y prêtera vraisemblablement moins.
Ça dépend, mais c'est vrai qu'on pourrait lui préférer une base hièrarchique à une base relationnelle. Disons LDAP.
Oui, c'est exactement dans ce cas que je me trouve : une structure d'arbre. J'arrive à le faire avec PHP/MySQL, mais c'est vrai que la syntaxe des SELECT devient vite assez lourdre (trop lourde à mon goût ; et ce n'e st pas un problème de programmation, mais un problème lié à mon programm e, parce que les requêtes SELECT dépendent - "plus" que d'habitude - des utilisateurs).
Beaucoup dépend aussi des critères de sélection. LDAP offre une solution parfaitement générique, mais évidemment, il faut avoir accès à une base LDAP. (Il existe des implémentations libres et gratuites de LDAP, mais il faut toujours que tu y ajoutes la gestion de la base même.) Si la sélection est toujours par clé principale à chaque niveau (scope = baseObject, filter = present en termes d'LDAP), et que les données sont toujours locales, une hièrarchie de répertoires pourrait éventuellement servir, au moins si le nombre d'entrées à chaque niveau n'est pas trop grand.
C'est la deuxième raison (la première étant les problèmes de déploiement) qui me poussent à chercher une autre solution que SQL. Une idée ??
Pour des petites bases, où il n'a qu'une seule clé d'accès par niveau, je me suis servi des hièrarchies de répertoires Unix. Dans un cas, au moins, avec toutes les données réeles encodées dans les noms de fichier ; l'utilitaire « find » me faisait alors pratiquement tout ce que pourrait faire une base LDAP. Mais il vaut mieux que la base soit petite, et qu'il n'y a pas trop de requêtes à la fois non plus, parce que c'est une solution qui ne brille pas par ces performances.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
Fabien LE LEZ wrote:
On 10 Jul 2006 04:00:02 -0700, "kanze" :
L'orientation objet n'est qu'une partie de ce que C++ offre, et sans doute pas la partie la plus importante.
Du moins, pour une définition de l'orientation objet.
je trouve que l'environement de développement natif sous Windows n'est simplement pas assez puissant.
Surtout, pas assez orienté "ligne de commande" pour tes besoins.
Le mot est bien « puissante ». Lorsque je développe du code, je ne travaille pas à la ligne de commande, mais dans l'éditeur vim, qui lui a bien une commande « make » (et rien de plus).
Le problème, c'est ce qu'il faut mettre dans ces fichiers de make. Typiquement, pas mal de code est généré, parfois à partir d'autres programmes C++, mais plus souvent à partir des scripts, qui font un emploi extensif d'awk et de sed. L'intérêt, justement, c'est que je n'ai pas besoin d'entrée ces commandes moi-même ; c'est make qui les invoque pour moi.
Autant que je sache, les plus répandues sont wxWidgets et Qt.
J'en viens même à me demander s'il reste d'autres bibliothèques GUI pour Windows, utilisables en C++.
Il y en a, sûrement. S'ils sont encore bien maintenu, c'est une autre question.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Fabien LE LEZ wrote:
On 10 Jul 2006 04:00:02 -0700, "kanze" <kanze@gabi-soft.fr>:
L'orientation objet n'est qu'une partie de ce que C++ offre,
et sans doute pas la partie la plus importante.
Du moins, pour une définition de l'orientation objet.
je trouve que l'environement de développement natif sous
Windows n'est simplement pas assez puissant.
Surtout, pas assez orienté "ligne de commande" pour tes besoins.
Le mot est bien « puissante ». Lorsque je développe du code,
je ne travaille pas à la ligne de commande, mais dans l'éditeur
vim, qui lui a bien une commande « make » (et rien de plus).
Le problème, c'est ce qu'il faut mettre dans ces fichiers de
make. Typiquement, pas mal de code est généré, parfois à partir
d'autres programmes C++, mais plus souvent à partir des scripts,
qui font un emploi extensif d'awk et de sed. L'intérêt,
justement, c'est que je n'ai pas besoin d'entrée ces commandes
moi-même ; c'est make qui les invoque pour moi.
Autant que je sache, les plus répandues sont wxWidgets et Qt.
J'en viens même à me demander s'il reste d'autres bibliothèques GUI
pour Windows, utilisables en C++.
Il y en a, sûrement. S'ils sont encore bien maintenu, c'est une
autre question.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
L'orientation objet n'est qu'une partie de ce que C++ offre, et sans doute pas la partie la plus importante.
Du moins, pour une définition de l'orientation objet.
je trouve que l'environement de développement natif sous Windows n'est simplement pas assez puissant.
Surtout, pas assez orienté "ligne de commande" pour tes besoins.
Le mot est bien « puissante ». Lorsque je développe du code, je ne travaille pas à la ligne de commande, mais dans l'éditeur vim, qui lui a bien une commande « make » (et rien de plus).
Le problème, c'est ce qu'il faut mettre dans ces fichiers de make. Typiquement, pas mal de code est généré, parfois à partir d'autres programmes C++, mais plus souvent à partir des scripts, qui font un emploi extensif d'awk et de sed. L'intérêt, justement, c'est que je n'ai pas besoin d'entrée ces commandes moi-même ; c'est make qui les invoque pour moi.
Autant que je sache, les plus répandues sont wxWidgets et Qt.
J'en viens même à me demander s'il reste d'autres bibliothèques GUI pour Windows, utilisables en C++.
Il y en a, sûrement. S'ils sont encore bien maintenu, c'est une autre question.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Arnaud Meurgues
Gabriel Dos Reis wrote:
yup, le principe de c'est d'en donner plus à ceux qui n'en ont pas besoin :-)
Non. Ça, c'est le corollaire. Le principe, c'est de donner plus à ceux qui t'en donne plus.
-- Arnaud
Gabriel Dos Reis wrote:
yup, le principe de c'est d'en donner plus à ceux qui n'en ont pas besoin :-)
Non. Ça, c'est le corollaire. Le principe, c'est de donner plus à ceux
qui t'en donne plus.
yup, le principe de c'est d'en donner plus à ceux qui n'en ont pas besoin :-)
Non. Ça, c'est le corollaire. Le principe, c'est de donner plus à ceux qui t'en donne plus.
Mais a ceux qui en on moins, on en prendra quand meme un peu.
On s'eloigne du sujet...
Laurent Deniau
Arnaud Meurgues wrote:
Gabriel Dos Reis wrote:
yup, le principe de c'est d'en donner plus à ceux qui n'en ont pas besoin :-)
Non. Ça, c'est le corollaire. Le principe, c'est de donner plus à ceux qui t'en donne plus.
Ca c'est le 1er principe. Le 2nd principe c'est que pour satisfaire le 1er principe, il faut prendre a ceux qui en ont le moins. Sinon on viole le 2nd principe de la thermo ;-)
a+, ld.
Arnaud Meurgues wrote:
Gabriel Dos Reis wrote:
yup, le principe de c'est d'en donner plus à ceux qui n'en ont pas besoin :-)
Non. Ça, c'est le corollaire. Le principe, c'est de donner plus à ceux
qui t'en donne plus.
Ca c'est le 1er principe. Le 2nd principe c'est que pour satisfaire le
1er principe, il faut prendre a ceux qui en ont le moins. Sinon on viole
le 2nd principe de la thermo ;-)
yup, le principe de c'est d'en donner plus à ceux qui n'en ont pas besoin :-)
Non. Ça, c'est le corollaire. Le principe, c'est de donner plus à ceux qui t'en donne plus.
Ca c'est le 1er principe. Le 2nd principe c'est que pour satisfaire le 1er principe, il faut prendre a ceux qui en ont le moins. Sinon on viole le 2nd principe de la thermo ;-)
a+, ld.
Gabriel Dos Reis
"kanze" writes:
[...]
| CaLyon Cheuvreux. Mais je doute que tu arriveras à avoir des | contrats avec de telles garanties. C'est comme partout : plus | tu es gros, plus tu peux négocier des avantages.
yup, le principe de c'est d'en donner plus à ceux qui n'en ont pas besoin :-)
-- Gaby
"kanze" <kanze@gabi-soft.fr> writes:
[...]
| CaLyon Cheuvreux. Mais je doute que tu arriveras à avoir des
| contrats avec de telles garanties. C'est comme partout : plus
| tu es gros, plus tu peux négocier des avantages.
yup, le principe de c'est d'en donner plus à ceux qui n'en ont pas besoin :-)
| CaLyon Cheuvreux. Mais je doute que tu arriveras à avoir des | contrats avec de telles garanties. C'est comme partout : plus | tu es gros, plus tu peux négocier des avantages.
yup, le principe de c'est d'en donner plus à ceux qui n'en ont pas besoin :-)
-- Gaby
loufoque
Je pratique régulièrement C++ mais il faut bien reconnaître que C# est plus moderne que C++ dans 99% des problématiques.
Il y a un problème dans ta définition de moderne. Fournir en standard des tas de bibliothèques ne fait pas d'un langage qu'il est moderne. D'ailleurs il serait bon de distinguer langage et bibliothèque standard.
Et soyons honnêtes, la même chose se fait facilement en C++, il suffit d'avoir une bibliothèque de sérialisation qui supporte le XML comme boost.serialization.
Je pratique régulièrement C++ mais il faut bien reconnaître que C# est
plus moderne que C++ dans 99% des problématiques.
Il y a un problème dans ta définition de moderne.
Fournir en standard des tas de bibliothèques ne fait pas d'un langage
qu'il est moderne.
D'ailleurs il serait bon de distinguer langage et bibliothèque standard.
Et soyons honnêtes, la même chose se fait facilement en C++, il suffit
d'avoir une bibliothèque de sérialisation qui supporte le XML comme
boost.serialization.
Je pratique régulièrement C++ mais il faut bien reconnaître que C# est plus moderne que C++ dans 99% des problématiques.
Il y a un problème dans ta définition de moderne. Fournir en standard des tas de bibliothèques ne fait pas d'un langage qu'il est moderne. D'ailleurs il serait bon de distinguer langage et bibliothèque standard.
Et soyons honnêtes, la même chose se fait facilement en C++, il suffit d'avoir une bibliothèque de sérialisation qui supporte le XML comme boost.serialization.
