Version imprimable
si je choisis C++\CLI avec clr:pure autant faire C# :) puisqu'on va perdre tous les avantages de C++ natif.Citation:
Envoyé par metagoto
et je suis d'accord avec toi c'est bien foutu et j'aimerais bien avoir des specs comme ceux d'ECMA pour le c++ natif ça rendra C++ le meilleur langage au monde :)
Non, il faut une norme qui soit respectée par les différentsSGBD du marché. Après il faut que les bibliothèques respectent la norme et c'est tout. Ce qui compte, c'est l'interportabilité entre les différents acteurs.Citation:
mais il nous faut une api commune pour utiliser une base de données.
Qu'il y ait 1, 10 ou 100 bibliothèques, ca change rien (sauf la difficulté à faire ton choix).
Pourquoi vouloir toujours tout centraliser ?
Attention à ne pas confondre /clr:pure et /clr:safe.Citation:
Envoyé par Issam_Lahlali
En /clr:pure, tu peux toujours utiliser des pointeurs et le tas non-managé...
peut être j'étais pas clair sur ce sujet, il y a une différence que la bibliothèque respecte la norme et le fait d'avoir une spec d'api pour accéder a la base.Citation:
Envoyé par Davidbrcz
est ce que t'aimerais pas avoir une seule api pour la couche technique et bien sur plusieurs implémentations, est ce que tu prefere avoir a faire avec enormement de librairies?
on va me dire que c'est impossible, a mon avis il faut la volonté pour le faire et c'est pas du tout impossible , puisque ça impacte pas ceux qui font les librairies, n'importe qui peut après créer des wrappers autour des librairies réels pour implémenter la spec de l'API mais pas de SQL bien sur.
.
effectivement mais en pure il ya plusieurs limitations pour faire du mixte avec le natif.Citation:
Envoyé par Médinoc
Pas vraiment...Citation:
Envoyé par Issam_Lahlali
Soit on considère que le sujet est hyper stable, totalement déblayé, et qu'un statu-quo acceptable a été trouvé pour tous les choix de design, et alors, une seule API me satisfait (et à la limite, je me contrefous totalement d'avoir accès à plusieurs implémentations, tout ce qui compte c'est d'en avoir une pour ma plate-forme).
Soit on considère que ce n'est pas le cas, et dans ce cas là, j'ai bien envie d'avoir plusieurs API, qui présentent différents choix parmi les possibilités d'accéder au sujet.
Après tout, c'est bien ce qui existe en C# (2 API pour gérer le graphique (Winforms et WPF), sans compter les innombrables bibliothèque supplémentaires qui définissent leur propre API sur ce qu'est un bouton, au moins 2 API pour accéder à SQL (ADO et Linq)...).
La principale différence avec le C++ est qu'avec .NET ou Java, le propriétaire du langage fourni des API pour un certain nombre de domaines, API qui deviennent des références de fait, et empêche une concurrence de voir jour.
Avec C++, qui n'a pas de propriétaire, de telles API existent, mais il y a une plus grosse concurrence en pratique. C'est dommage dans certains cas (de l'énergie est dissipée à réinventer la roue ou à adapter sur un même essieu deux roues différentes), mais ça a aussi ses avantages, puisque ça permet une plus grande richesse, par exemple pour définir des langages spécifiques à un domaine, je suis content de pouvoir choisir entre Lex/Yacc, Antlr, boost.spirit, car chacun est adapté à un use-case différent.
non seulement c'est impossible si l'on veut que le langage reste à jour (parce que les specs évoluent de manière indépendante), mais en plus, cela sort du domaine de la spec C++...Citation:
Envoyé par Issam_Lahlali
Il y a déjà des incompatibilités entre la norme du C utilisée par C++ et la norme C en cours, alors que le couplage entre les deux langages est particulièrement fort, alors, imagine ce qu'il peut en être d'une norme qui, de toutes manières, n'intéresse au final qu'une petite partie des programmeurs et qui ne présente aucun couplage.
Et, de toutes manières, pour bien le faire entrer, cela n'entre pas dans le domaine de la norme C++.
Le but d'une norme de langage est de définir les mots clés, la syntaxe et la manière dont les données seront représentées en mémoire.
Par extension, cela peut être de définir une bibliothèque permettant les "choses de base" (conteneurs, I/O, manipulation de chaines ...) qui seront manipulées "en permanence".
Par exemple, si la norme a décidé d'inclure la gestion des threads sans la bibliothèque standard, ce n'est au final que parce que les exécutions concurrentes sont destinées à devenir de plus en plus fréquentes du fait de l'avènement des coeurs multiples.
Mais le but de la norme d'un langage n'est absolument pas de fournir une API permettant la connectivité avec d'autres technologies, simplement parce que ces technologies sont destinées à évoluer de manière tout à fait indépendante.
Il faut aussi te dire que les règles à suivre pour qu'un document puisse être estampillé "ISO" font qu'il est aberrant et contre productif d'essayer d'inclure de telles API dans la norme d'un langage.
Si, par après, tu décide de faire reconnaitre les specs d'un framework particulier comme étant ISO, c'est une autre chose, mais tout à fait en marge de la norme du langage.
c'est ce cas qui m'intéresse et ça peut concerner database,xml,MOM , gestion des répertoires et fichiers, cryptage et peut être d'autres , pour l'interface graphique ça devient chose impossible.Citation:
Envoyé par JolyLoic
le probléme n'est pas que ca soit dans la norme C++ ou omg ou ECMA ou autre.Citation:
Envoyé par koala01
le probléme est d'abord de savoir si ça apporte une valeur ajouté, apparemment ça sert a rien d'unifier ou c'est impossible.
si ça sert a rien alors la je comprends rien de rien :)
et si c'est impossible je me demande comment java et dotnet ont réussi a le faire, est ce que pour la base on peut faire des choses en C++ mais pas en java avec jdbc?
Dans les cas que tu cites, seul le cryptage peut être considéré comme stable, et encore...Citation:
Envoyé par Issam_Lahlali
Comme je l'ai fait remarquer pour les bases de données, tu n'a pas encore un concensus suffisant ni une norme suffisamment respectée.
Pour ce qui est de xml, c'est pareil: la norme est relativement stable (mais toujours sujette à mise à jour), mais entre DOM, SAX et XPath, c'est encore trop volatile.
Et pour la gestion des répertoires et fichiers, n'en parlons pas: entre les philosophies radicalement différentes de windows et des unixoïdes et les différents systèmes de fichiers manipulés par ces systèmes d'exploitation, il y a peu de chances de trouver un jour un concensus stable et définitif :P
dans ce cas est ce que les frameworks dotnet et java ont trop de limitation dans les apis qu'elle proposent et que souvent on doit utiliser une librairie en dehors du framework pour la couche technique de base?Citation:
Envoyé par koala01
Je n'irai pas jusque dire que ca ne sert à rien, quoi que, à l'heure actuelle, les disparités entre les différentes bibliothèques sont telles que cela aurait très certainement un effet négatifCitation:
Envoyé par Issam_Lahlali
Java et dotnet ont seulement présenté, lors de leur lancement, une bibliothèque tierce adaptée, et entièrement mise en oeuvre par les développeurs du langage qui, à défaut de concurrence, s'est révélée être la bibliothèque de référence pour ce genre de chose.Citation:
et si c'est impossible je me demande comment java et dotnet ont réussi a le faire, est ce que pour la base on peut faire des choses en C++ mais pas en java avec jdbc?
Il ne faut pas oublier que le code source de java n'est passé dans le domaine public qu'il n'y a peu, et que C# est à ce jour un langage propriétaire, tout comme l'est VB ou ASP...
Mais les specs de JDBC par exemple n'entrent absolument pas dans la norme java, ce sont des specs qui servent de norme "à défaut de concurrence" et qui sont tout à fait en marge de la norme qui concerne le langage java à proprement parler.
Non. Car il y a plusieurs manière d'arriver à la même chose. Et une seule bibliothèque, c'est imposer ce choix (on revient aux notions de liberté et de choix).Citation:
cest ce que t'aimerais pas avoir une seule api pour la couche technique et bien sur plusieurs implémentations, est ce que tu prefere avoir a faire avec enormement de librairies?
De plus, un langage est un outils et le C++ est un bon outil.
Je n'ai pas envie qu'il devienne un Java/C# like avec des tonnes de choses par défaut disponibles et dont au final je ne me servirai qu'à 2%. J'aime le KISS.
Je code en C++ et je veux manipuler une BDD ? Je prends l'API qui va avec.
Je code en C++ et je veux faire une GUI ? Je prends une autre API.
Je veux faire un explorateur de BDD graphique ? je mélange mes deux libs (pas toujours vrai mais c'est l'idée)
Je veux juster coder en C++ ? Bah je code sans avoir 4 tonnes de trucs à coté.
Dans une certaine mesure, cela existe déjà sous forme de COTS -> OTL.Citation:
Envoyé par Issam_Lahlali
Et non, cela n'a pas à faire parti du langage -- pas plus que JDO qui me semble remplir le même genre de service (à moins qu'il s'agisse d'une alternative?) et qui est chez Apache, et non chez Sun...
Ce n'est guère différent ailleurs.
Accessoirement, ces couches d'intégrations auront toutes leurs limites : parfois quand on choisi une techno à la place d'une autre, c'est pour bénéficier de ce petit truc différent que ne font pas les autres. Comment alors la couche commune LSPisante pourrait supporter cela ?
On en revient à ce que j'avais déjà dit : en Java ils ont entre 3 et 5 techno IHM concurrentes et non unifiées (OK on en a plus chez nous). Ne parlons même pas des webservices (au moins nous n'avons que Wt et CppCMS à s'y attaquer sérieusement). Et de plus (bis) ce n'est pas parce qu'un truc sera standard que les COTS iront se reposer dessus, cf tous ces frameworks qui n'utilisent pas la SL (vector, string, fstream) et qui préfèrent réinventer ... (c'est aussi pour cela que je préfère l'approche de boost + ASL à celle de Qt).
Quelques part je peux comprendre ton chagrin, mais il ne faut pas être naif. Les sociétés qui ne possèdent pas un langage n'ont aucun intérêt à cela (vison à court terme des investissements), et le monde de l'open-source souffre de NIHite aiguë.
Comme toute bibliothèque tirece, tu aura un flottement entre le moment où la norme changera et le moment où les modifications de la norme seront prises en compte.Citation:
Envoyé par Issam_Lahlali
Et, si les specs de cette bibliothèque tierce est estampillée ISO, le flottement sera d'autant plus important du seul fait que ce genre de norme doit respecter certaines contraintes lors de toute modification
Sauf qu'en .NET (je connais mal Java), ces parties ne sont pas normalisées. Il y a juste des bibliothèques pré-installées avec le compilateur, mais elles ne sont pas citées dans la norme C#. Point de vue normalisation, C# est encore plus pauvre en bibliothèques que C++.Citation:
Envoyé par Issam_Lahlali
Et comme je disais, rien que dans ce qui est fourni par Microsoft, et ce pour un langage récent, il y a :
- Databases : Au moins 2 API totalement différentes : ADO et Linq
- XML : Au moins 3 API totalement différentes : Sax, DOM et XmlReader/Writer (je ne suis plus certain si Sax est fourni par Microsoft)
- MOM : Je ne sais pas ce que c'est
- Cryptage : Je ne connais pas le domaine, mais je crois qu'il y a un système interne, et accès aux fonctions de l'OS
- Gestion des répertoires/fichiers : Là, en effet, je ne connais qu'une seule API dans .NET, même si elle est incomplète et oblige parfois à utiliser des fonctions Win32.
- et pire encore, pour les collections de base, il y a 2 API, une à base d'object qui ne respecte pas les principes de la POO, et une autre générique, arrivée plus tard et donc que beaucoup de bibliothèques tierces n'utilise pas...
Médinoc à mentionné /clr:safe. RASCitation:
Envoyé par Issam_Lahlali
Bon, c'est peut être moins le cas maintenant depuis les nouveaux trucs comme LINQ et WPF, mais il n'y a encore pas si longtemps, C++/CLI était considéré comme le meilleur langage pour cibler le CLR (même en clr:safe).
On peut faire du RAII en C++/CLI, on a tout ce que les templates supportent (ne pas confondre avec les generics), on a les destructeurs (et les finalizers). Bref, c'est beaucoup plus expressif que du C# (normal, c'est du C++ à la base :mrgreen:).
Alors c'est vrai que comme c'est beaucoup lié à la puissance d'un IDE, et que MS met le paquet sur C#, le C++/CLI n'est pas aussi poussé qu'il pourrait l'être. Il n'en reste pas moins un excellent "proof of concept"
finalement il n y a pas énormément de façon pour la couche technique , choisir entre 2 alternatives et mieux que de choisir parmi plus qu'une dizaine.Citation:
Envoyé par JolyLoic
et a mon avis il faut a tout prix dépasser cette couche technique, c'est pas du tout la vrai valeur ajoutée, je sais que dans le futur ou on aura bien cerner la tuyauterie technique et on dépassera ce cap.
il faut que ça soit au maximum transparente , ça va accélérer beaucoup le dev et ça nous laissera plus de temps pour l'architecture et la conception.
comment est ce possible que des années d'existence des langages on bataille encore avec cette couche, et comme a signaler luc la communauté open source a accentuer ce fait ou chacun réinvente la roue peut être pour chercher la gloire :)
Dans ma boîte, on a interdiction d'utiliser des librairies "externes". "externe" pour eux veut dire que c'est pas installé en même temps que Visual Studio.
Je vous laisse imaginer comment se passe un projet d'ampleur quand on se retrouve "à poil"...
Bien plus que la recherche de la gloire personnelle (il n'y a aucune gloire à se tirer dans le pied uniquement pour ne pas réutiliser quelque chose qui a été "fait ailleurs"), ce citerais comme raisons principales:Citation:
Envoyé par Issam_Lahlali
les deux premiers points pouvant allègrement être cumulés pour en arriver à l'inadéquation ressentie de l'existant méconnu pour atteindre l'objectif :D
- l'inadéquation de l'existant par rapport à l'objectif poursuivi
- la méconnaissance de l'existant pour atteindre son objectif
- le souhait de limiter au maximum les dépendances externes
On peut, effectivement, déplorer cet état de fait, mais la solution qui consisterait à faire en sorte que la norme du langage (qui n'est absolument pas adaptée à cela) s'attaque à ce problème serait un mal bien pire...