Discussion :

[kryptos]

Je suis désolé d'en remettre une couche, mais int *t =new int[10] est une syntaxe C++. Le mot clé new n'existe pas en C.

Plus précisément, C est inclus dans C++ comme un subset. Un nombre limité d'incompatibilités existent tout de même entre les deux.

De plus, Qt utilise lui-même des char* à la place de QString à certains endroits pour des raisons d'optimisations. C'est expliqué dans plusieurs pages de leur documentation.

Pour conclure, je comprend que vous souhaitiez éviter d'utiliser du code C incorrect ou impropre à l'intérieur de classes C++. Mais je persiste à penser qu'utiliser des char et des char* est une bonne manière d'optimiser le programme.

[yan]

Je suis désolé d'en remettre une couche, mais int *t =new int[10] est une syntaxe C++. Le mot clé new n'existe pas en C.

sur celle la je suis allez un peu vite dsl . Mais, l'idée est là, il est beaucoup plus propre d'utiliser un std::vector qu'un tebleau comme cela. ET niveau perf, c'est pareil.

De plus, Qt utilise lui-même des char* à la place de QString à certains endroits pour des raisons d'optimisations. C'est expliqué dans plusieurs pages de leur documentation.

tu aurais un exemple, cela m'intéresse.

[Alp]

Je suis désolé d'en remettre une couche, mais int *t =new int[10] est une syntaxe C++. Le mot clé new n'existe pas en C.

Plus précisément, C est inclus dans C++ comme un subset. Un nombre limité d'incompatibilités existent tout de même entre les deux.

De plus, Qt utilise lui-même des char* à la place de QString à certains endroits pour des raisons d'optimisations. C'est expliqué dans plusieurs pages de leur documentation.

Pour conclure, je comprend que vous souhaitiez éviter d'utiliser du code C incorrect ou impropre à l'intérieur de classes C++. Mais je persiste à penser qu'utiliser des char et des char* est une bonne manière d'optimiser le programme.

Ce que l'on voulait dire, c'est que le C++ de référence qu'on utilise c'est le beau C++ dont on parle beaucoup, le C++ moderne. On appréciera l'approche RAII, la généricité, l'utilisation de l'héritage SEULEMENT quand il faut, le polymorphisme statique lorsqu'il suffit par rapport à un héritage, etc. On va noter par rapport au C++ moderne, pas par rapport au "C/C++" qui n'est qu'une tâche historique dans l'histoire du C++.

Si vous avez d'autres questions n'hésitez pas.

[0x4e84]

La version 4.6 de Qt a été publiée hier.

Je suppose que cette version est acceptée implicitement pour le défi, bien qu'il soit fait mention uniquement des versions "4.5.3 (Windows, Linux, Mac OS X) et 4.6.0 release candidate (Windows, Linux)" ?

Merci, à +!

[Alp]

Oui oui, au moment de la sortie du défi le release n'était pas sortie, mais nous l'accepterons car surtout d'ici 3 mois personne dans le jury n'aura d'excuse pour ne pas avoir accès à Qt 4.6, et d'ailleurs nous l'avons déjà probablement tous installée

[Z3vil]

Bonjour,

c'est intéressant ce challenge & je veux savoir est ce que on peut tout change (algorithme, types, etc...) dans le générateur, au plutôt on peux re-crée un nouveau?

merci!

[yan]

Bonjour,

c'est intéressant ce challenge & je veux savoir est ce que on peut tout change (algorithme, types, etc...) dans le générateur, au plutôt on peux re-crée un nouveau?

merci!

Les sources sont sous licence MIT, donc tu en fait ce que tu veux
En faite, c'est toi qui voie si tu veut te baser dessus, la modifier ou tous refaire à ta sauce.

[Alp]

C'est surtout fait pour aider pour ceux qui auraient du mal à ce niveau là. Afin de ne pas les bloquer, yan a mis cela à disposition. Mais tu peux tout à fait ne pas t'en servir.

[dourouc05]

Bonjour,

Apparemment, l'interdiction du C en choque certains. Voici plus de détails sur ce point.

C et C++ ont une origine commune, c'est vrai. Mais c'est il y a quelques années. Depuis lors, les deux langages ont évolué différemment. Des incompatibilités sont apparues. Autoriser le C, ce serait ne pas l'autoriser entièrement.

Le C++ est réputé pour être un langage de haut-niveau, le C pour un langage de bas-niveau. De nos jours, il est nettement moins important de se préoccuper du bas-niveau : on préfère développer "plus haut", comme Qt. Autoriser le C, c'est aussi revenir en arrière à ce niveau.

Le C++ est nativement multiparadigmes. Le C, biparadigmes : impératif et objet (ce dernier en jouant très fort sur le langage, l'amenant dans ses extrémités - comme GTK+). Le C++ : impératif, objet (principalement), mais aussi fonctionnel et bien d'autres (même s'il n'est pas prévu pour ceux-là). Le C++ est donc plus permissif à ce niveau que le C.

On voit donc aisément que le C n'est pas le C++. Si on autorise le C parce qu'il ressemble au C++, on devra aussi pouvoir supporter des pléthores d'autres langages : le Java, qui ressemble beaucoup au C++ ; le C#, proche du Java ; l'Objective-C ; le D ; le PHP ; et bien d'autres !

Aussi, l'ancêtre C with Classes et autres préversions du C++ ne sont pas autorisées pour les mêmes raisons. De plus, il s'agit de standards plus que dépassés, qui n'apportent pas grand chose à la programmation. Ce standard est aussi très différent du C++ de nos jours : beaucoup de nouveautés qui permettent de rendre un code plus lisible ne sont pas encore arrivées, le "C++ moderne" n'était pas encore dans le jeu.

Il existe quand même une exception : l'ECMAScript. En effet, il est supporté par Qt depuis longtemps (dès l'arrivée du module QtScript dans Qt 4.3, et bien avant avec QSA).

De même, C++ for CUDA n'est pas autorisé (la question du C for CUDA et du Fortran for CUDA est déjà soulevée), même s'il utilise le C++ : personne ne s'est à présent opposé contre l'interdiction de librairies externes, et CUDA en est une.

Aussi, il est possible d'obtenir de meilleures performances grâce au GPGPU : serait-il juste de devoir mieux noter un programme qui tire parti du GPGPU qu'un autre, qui se contente du CPU, alors que le programme sur CPU a subi des optimisations plus profondes ?

J'espère avoir ainsi répondu à ces interrogations sur ces interdits.

[kryptos]

tu aurais un exemple, cela m'intéresse.

Typiquement les fonctions pour le mécanisme de signal/slot utilisent des char*.
Les char* sont aussi utilisés pour les fonctions utilisant une clé (et donc une hashmap en interne) comme setProperty/getProperty.
Enfin char* (ou QByteArray qui est un sorte de wrapper objet) est conseillé partout où l'utilisateur final n'est pas concerné : http://doc.trolltech.com/4.6/interna...r-visible-text

[yan]

Typiquement les fonctions pour le mécanisme de signal/slot utilisent des char*.
Les char* sont aussi utilisés pour les fonctions utilisant une clé (et donc une hashmap en interne) comme setProperty/getProperty.
Enfin char* (ou QByteArray qui est un sorte de wrapper objet) est conseillé partout où l'utilisateur final n'est pas concerné : http://qt.developpez.com/doc/latest/...-l-utilisateur

Ce que tu montre n'est pas vraiment lié à de l'optimisation. Mais à l'utilisation de macro (qui ajoute des informatin dans la string) et l'inutilité de créer de la mémoire pour cela. De plus ce sont des const char * et non char*. Pourquoi ? lorsque tu écrit

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

"salut"

dans le code, cela génère un tableau de char de la taille de la string directement dans le binaire résultat. Elle ne peut donc être modifié.

[TresNulDev]

Je ne sais pas si je vais participer (je ne connais rien à Qt et le "beau" C++ n'est pas mon fort) mais j'ai quand même une question. Puisque OpenGl est autorisé (Qt possédant un module OpenGL), l'utilisation de bibliothèques telles que glee ou glew pour faciliter le chargement des extensions est autorisée également? Parce qu'il faut se contenter de coder à "l'ancienne" avec des display list (à présent dépréciées) bof bof...

[dourouc05]

Puisque OpenGl est autorisé (Qt possédant un module OpenGL), l'utilisation de bibliothèques telles que glee ou glew pour faciliter le chargement des extensions est autorisée également? Parce qu'il faut se contenter de coder à "l'ancienne" avec des display list (à présent dépréciées) bof bof...

Pas de bibliothèque, peu importe la finalité. Dura lex, sed lex.

[TresNulDev]

D'accord c'est très clair, merci. Donc je ne participerai pas.

[yan]

D'accord c'est très clair, merci. Donc je ne participerai pas.

pourquoi?
as tu regardé les nouveauté fournie par Qt 4.6 pour faire de l'opengl?

http://qt.developpez.com/doc/4.6/qt4...#qt3d-enablers

[marco565]

Moi j'ai une question, est-ce possible d'inclure OpenCL pour calculer la fractale avec le GPU pour une meilleure optimisation ?

[yan]

Moi j'ai une question, est-ce possible d'inclure OpenCL pour calculer la fractale avec le GPU pour une meilleure optimisation ?

Temps que OpenCL n'est pas intégrer dans Qt, non.

[LittleWhite]

Comme je l'ai dis, je vais participé ( bon faut encore que je lise les règles ) mais je vais le faire de ce pas.
Par contre, je voulais savoir, lorsque vous allez faire les notations et autres analyse de notre code, vous allez nous dire comment le rendre encore plus "beau C++". Je veux dire, que pour le moment, j'ai quelques doutes sur la beauté de mon code, et sur l'utilisation correct du C++. Donc, je vais surement profité du concours, pour essayé de m'amélioré sur ces points. Du coup, j'espère avoir une tonne de remarque sur mes points faibles .

[Alp]

Je veux bien prendre le temps de le faire pour un certain nombre de participants. Pour les autres je ne sais pas, mais je peux trouver un peu de temps, mais ce n'est pas pour autant envisageable de le faire pour tous s'il y a 100 participants (mais ça serait assez énorme pour un premier défi)

[TresNulDev]

Bonjour, j'ai à peu près compris le principe du Mandelbrot mais j'ai plus de mal avec celui du Buddhabrot. Les explications, en "français" du site Wikipedia, que vous avez reprises' me semblent confuses (en tout cas me rendent confus). Vous allez me prendre pour un neuneu (à juste titre?!...) mais pourriez-vous décrire le Buddhabrot en pseudo-code s'il-vous-plaît?