Marc Boyer writes:
| Je crois que pour envisager une GUI "normalisable"
| à C++, il faut déjà bien comprendre C++ tel qu'il
| existe, et comprendre ou ce situe le projet.
Juste par curiosité, tu crois que quelqu'un comme BS comprend quelque
chose à C++ ?
| N'accordes pas trop d'importance à mon poids dans
| l'avenir de C++...
comme ils disent dans la pub mckay...
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
| Je crois que pour envisager une GUI "normalisable"
| à C++, il faut déjà bien comprendre C++ tel qu'il
| existe, et comprendre ou ce situe le projet.
Juste par curiosité, tu crois que quelqu'un comme BS comprend quelque
chose à C++ ?
| N'accordes pas trop d'importance à mon poids dans
| l'avenir de C++...
comme ils disent dans la pub mckay...
Marc Boyer writes:
| Je crois que pour envisager une GUI "normalisable"
| à C++, il faut déjà bien comprendre C++ tel qu'il
| existe, et comprendre ou ce situe le projet.
Juste par curiosité, tu crois que quelqu'un comme BS comprend quelque
chose à C++ ?
| N'accordes pas trop d'importance à mon poids dans
| l'avenir de C++...
comme ils disent dans la pub mckay...
Marc Boyer writes:
|
| Non, C++ a été conçu comme un "langage" et évolue dans ce sens.
Et qu'est-ce que cela veut dire concrêtement,
« être conçu comme un "langage" et évoluer dans ce sens » ?
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
|
| Non, C++ a été conçu comme un "langage" et évolue dans ce sens.
Et qu'est-ce que cela veut dire concrêtement,
« être conçu comme un "langage" et évoluer dans ce sens » ?
Marc Boyer writes:
|
| Non, C++ a été conçu comme un "langage" et évolue dans ce sens.
Et qu'est-ce que cela veut dire concrêtement,
« être conçu comme un "langage" et évoluer dans ce sens » ?
Marc Boyer writes:
| Si on parle des choses qui AMHA (1) manquent actuellement
| à C++:
| - des types entiers avec détection d'overflow (leur
| arrivée dans la norme permettrait au compilateur de
| se reposer sur les bits d'overflow présents dans de
| nombreux processeurs en faisant "comme si" on testait
| lhs > numeric_limits<..>::max()-rhs)
C++ permeyt actuellement à une implémentation de lever une exception
s'il y a débordement. Mais, en aucun cas ce n'est un préalable pour
introduire un GUI en C++
| - des compilateurs qui donnent des messages plus
| explicites lorsque des templates sont en jeu
Plus concrêtement ?
Encore une fois, je ne vois pas cela comme un préalable à
l'introduction d'un GUI en C++.
| - un moyen de déterminer la signature minimale nécessaire
| à un type pour être argument d'un template (les
| solutions comme la fonction membre "constraint"
| reposent sur le programmeur)
Peux-tu préciser ?
| - je serais séduit pas une gestion de la notion
| de module avec interface/implémentation autre
| que le #include actuellement utilisé.
Plus concrêtement, qu'appelles-tu module avec interface/implémentation ?
| Mais c'est un problème différent.
| "un certain binding à certaines notions de GUI" et
| "une GUI normalisée", sont deux phrases qui évoquent
| des choses très différentes pour moi.
Bah.
| Il me semble que la requette de l'OP, à laquelle je
| répondais, était d'offrir une GUI minimale normalisée.
| Je n'aurais je pense pas fait la même réponse pour
| "des demandes facilités de GUI".
quelques que soient ces facilités de GUI, elles seront toujours
minimales pour un groupe d'utilisateurs ; je ne vois pas la pertinence
de ta distinction.
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
| Si on parle des choses qui AMHA (1) manquent actuellement
| à C++:
| - des types entiers avec détection d'overflow (leur
| arrivée dans la norme permettrait au compilateur de
| se reposer sur les bits d'overflow présents dans de
| nombreux processeurs en faisant "comme si" on testait
| lhs > numeric_limits<..>::max()-rhs)
C++ permeyt actuellement à une implémentation de lever une exception
s'il y a débordement. Mais, en aucun cas ce n'est un préalable pour
introduire un GUI en C++
| - des compilateurs qui donnent des messages plus
| explicites lorsque des templates sont en jeu
Plus concrêtement ?
Encore une fois, je ne vois pas cela comme un préalable à
l'introduction d'un GUI en C++.
| - un moyen de déterminer la signature minimale nécessaire
| à un type pour être argument d'un template (les
| solutions comme la fonction membre "constraint"
| reposent sur le programmeur)
Peux-tu préciser ?
| - je serais séduit pas une gestion de la notion
| de module avec interface/implémentation autre
| que le #include actuellement utilisé.
Plus concrêtement, qu'appelles-tu module avec interface/implémentation ?
| Mais c'est un problème différent.
| "un certain binding à certaines notions de GUI" et
| "une GUI normalisée", sont deux phrases qui évoquent
| des choses très différentes pour moi.
Bah.
| Il me semble que la requette de l'OP, à laquelle je
| répondais, était d'offrir une GUI minimale normalisée.
| Je n'aurais je pense pas fait la même réponse pour
| "des demandes facilités de GUI".
quelques que soient ces facilités de GUI, elles seront toujours
minimales pour un groupe d'utilisateurs ; je ne vois pas la pertinence
de ta distinction.
Marc Boyer writes:
| Si on parle des choses qui AMHA (1) manquent actuellement
| à C++:
| - des types entiers avec détection d'overflow (leur
| arrivée dans la norme permettrait au compilateur de
| se reposer sur les bits d'overflow présents dans de
| nombreux processeurs en faisant "comme si" on testait
| lhs > numeric_limits<..>::max()-rhs)
C++ permeyt actuellement à une implémentation de lever une exception
s'il y a débordement. Mais, en aucun cas ce n'est un préalable pour
introduire un GUI en C++
| - des compilateurs qui donnent des messages plus
| explicites lorsque des templates sont en jeu
Plus concrêtement ?
Encore une fois, je ne vois pas cela comme un préalable à
l'introduction d'un GUI en C++.
| - un moyen de déterminer la signature minimale nécessaire
| à un type pour être argument d'un template (les
| solutions comme la fonction membre "constraint"
| reposent sur le programmeur)
Peux-tu préciser ?
| - je serais séduit pas une gestion de la notion
| de module avec interface/implémentation autre
| que le #include actuellement utilisé.
Plus concrêtement, qu'appelles-tu module avec interface/implémentation ?
| Mais c'est un problème différent.
| "un certain binding à certaines notions de GUI" et
| "une GUI normalisée", sont deux phrases qui évoquent
| des choses très différentes pour moi.
Bah.
| Il me semble que la requette de l'OP, à laquelle je
| répondais, était d'offrir une GUI minimale normalisée.
| Je n'aurais je pense pas fait la même réponse pour
| "des demandes facilités de GUI".
quelques que soient ces facilités de GUI, elles seront toujours
minimales pour un groupe d'utilisateurs ; je ne vois pas la pertinence
de ta distinction.