Je viens de me mettre au C++ depuis 1 petit mois mais il ya
un bon moment que je voulais m'y mettre. Pour le moment je me contente de
lire un maximum de choses pour comprendre les principes de base. Mon but,
c'est de pouvoir d'ici deux ou trois ans de pouvoir créer mon propre
logiciel. Un programme pour gérer une auto-école ( gestion de planning avec
des élèves, facturations etc..) Je sais exactement ce que je veux, c'est a
dire a quoi il va ressembler physiquement, les differents menus, les
fenetres, les outils etc... Je me suis donc tourner vers le C++ puis ensuite
dès que ça ira un peu mieux je me tournerais vers l' API pour réaliser le
tout... C'est le bon itinéraire ?
J'ai commencé "c++ pour les nuls" mais apparemment je dois vraiment être
très nul, car c'est loin d'être clair... Je me suis donc tourné vers des
tutoriaux trouvé sur le net. Je suis actuellement sur :
http://www.librecours.org/documents/7/728.pdf Je l'ai trouvé sur
http://www.developpez.com/ et j'avoue que je trouve ça beaucoup plus clair
même si je n'en suis qu' a la couche objet (chapitre 8)... Voici mes 2 ou 3
soucis...
Le problème c'est que tout ceci me parait encore trop abstrait. J'ai
compris le principe des fonctions, des classes, des structures de contrôles
mais j'ai du mal à les concevoir dans un programme sauf évidement les
structures de contrôles. Je comprends la théorie, c'est la mise en pratique
qui me gêne... Je lis tout ça en gardant en tête mon programme mais j'ai
bien du mal a faire le lien ente le deux. Est-ce normal vu le peu de choses
que je sais sur le c++ ou dois-je consulter ? Je ne suis pas pressé pour mon
programme, et lire ne me dérange pas le moins du monde mais là j'ai
l'impression de passer a coté de quelquechose... en attendant je continue de
lire...
Merci pour vos suggestions, et désolé si je ne suis pas sur le bon groupe.
Si vous avez des liens intéressants je suis preneur
Une dernière petite question. Quel langage serait le plus adapté au programme que j'ai en tête. Logiciel de gestion pour une école de conduite donc gestion des planning, des monos, des élèves, facturations etc... C++, C , Java
Des trois, C++ ou Java, sûrement pas C.
Si je devais faire ça, je regarderais plutôt des côtés de python, php, perl..
-- Loïc
Auden wrote:
Une dernière petite question.
Quel langage serait le plus adapté au programme que j'ai en tête. Logiciel
de gestion pour une école de conduite donc gestion des planning, des monos,
des élèves, facturations etc... C++, C , Java
Des trois, C++ ou Java, sûrement pas C.
Si je devais faire ça, je regarderais plutôt des côtés de python, php,
perl..
Une dernière petite question. Quel langage serait le plus adapté au programme que j'ai en tête. Logiciel de gestion pour une école de conduite donc gestion des planning, des monos, des élèves, facturations etc... C++, C , Java
Des trois, C++ ou Java, sûrement pas C.
Si je devais faire ça, je regarderais plutôt des côtés de python, php, perl..
-- Loïc
Fabien LE LEZ
On Fri, 19 Nov 2004 23:02:17 +0100, Loïc Joly :
je regarderais plutôt des côtés de python, php,
Une solution avec gestion interne des données, sans lien avec une BdD externe, a l'avantage de faciliter le déploiement (on copie l'exécutable et ça marche). Et ça me paraît délicat avec Python ou PHP. Ceci dit, une interface en Python et un moteur en C++ pourrait être sympa.
-- ;-)
On Fri, 19 Nov 2004 23:02:17 +0100, Loïc Joly
<loic.actarus.joly@wanadoo.fr>:
je regarderais plutôt des côtés de python, php,
Une solution avec gestion interne des données, sans lien avec une BdD
externe, a l'avantage de faciliter le déploiement (on copie
l'exécutable et ça marche). Et ça me paraît délicat avec Python ou
PHP.
Ceci dit, une interface en Python et un moteur en C++ pourrait être
sympa.
Une solution avec gestion interne des données, sans lien avec une BdD externe, a l'avantage de faciliter le déploiement (on copie l'exécutable et ça marche). Et ça me paraît délicat avec Python ou PHP. Ceci dit, une interface en Python et un moteur en C++ pourrait être sympa.
-- ;-)
Loïc Joly
Fabien LE LEZ wrote:
On Fri, 19 Nov 2004 22:58:51 +0100, Loïc Joly :
non, ce n'est pas parce que "ca marche" que c'est forcément bien,
En plus, prendre bien soin de compiler ses programmes avec deux ou trois compilateurs différents. Par exemple, développer sous Borland C++ et tester de temps en temps avec gcc -Wall.
En ce moment, on évalue PC-Lint au boulot, et ça procède de la même idée, en allant encore plus loin.
-- Loïc
Fabien LE LEZ wrote:
On Fri, 19 Nov 2004 22:58:51 +0100, Loïc Joly
<loic.actarus.joly@wanadoo.fr>:
non, ce n'est pas parce que "ca marche" que c'est forcément bien,
En plus, prendre bien soin de compiler ses programmes avec deux ou
trois compilateurs différents. Par exemple, développer sous Borland
C++ et tester de temps en temps avec gcc -Wall.
En ce moment, on évalue PC-Lint au boulot, et ça procède de la même
idée, en allant encore plus loin.
non, ce n'est pas parce que "ca marche" que c'est forcément bien,
En plus, prendre bien soin de compiler ses programmes avec deux ou trois compilateurs différents. Par exemple, développer sous Borland C++ et tester de temps en temps avec gcc -Wall.
En ce moment, on évalue PC-Lint au boulot, et ça procède de la même idée, en allant encore plus loin.
-- Loïc
Loïc Joly
Fabien LE LEZ wrote:
On Fri, 19 Nov 2004 23:02:17 +0100, Loïc Joly :
je regarderais plutôt des côtés de python, php,
Une solution avec gestion interne des données, sans lien avec une BdD externe, a l'avantage de faciliter le déploiement (on copie l'exécutable et ça marche).
Je n'envisageais pas vraiment de gérer les données en interne. Une BdD relationnelle me semble quand même être conçue pour traiter de genre de choses. De plus, la mode actuelle consiste à donner une interface web à ce genre d'appli.
-- Loïc
Fabien LE LEZ wrote:
On Fri, 19 Nov 2004 23:02:17 +0100, Loïc Joly
<loic.actarus.joly@wanadoo.fr>:
je regarderais plutôt des côtés de python, php,
Une solution avec gestion interne des données, sans lien avec une BdD
externe, a l'avantage de faciliter le déploiement (on copie
l'exécutable et ça marche).
Je n'envisageais pas vraiment de gérer les données en interne. Une BdD
relationnelle me semble quand même être conçue pour traiter de genre de
choses. De plus, la mode actuelle consiste à donner une interface web à
ce genre d'appli.
Une solution avec gestion interne des données, sans lien avec une BdD externe, a l'avantage de faciliter le déploiement (on copie l'exécutable et ça marche).
Je n'envisageais pas vraiment de gérer les données en interne. Une BdD relationnelle me semble quand même être conçue pour traiter de genre de choses. De plus, la mode actuelle consiste à donner une interface web à ce genre d'appli.
-- Loïc
Fabien LE LEZ
On Fri, 19 Nov 2004 23:13:15 +0100, Loïc Joly :
Je n'envisageais pas vraiment de gérer les données en interne. Une BdD relationnelle me semble quand même être conçue pour traiter de genre de choses.
En théorie, oui. En pratique, si on n'a que quelques Mo de données, une BdD externe n'est pas forcément indispensable.
De plus, la mode actuelle consiste à donner une interface web à ce genre d'appli.
La mode actuelle, c'est aussi oublier C++ au profit de Java.
-- ;-)
On Fri, 19 Nov 2004 23:13:15 +0100, Loïc Joly
<loic.actarus.joly@wanadoo.fr>:
Je n'envisageais pas vraiment de gérer les données en interne. Une BdD
relationnelle me semble quand même être conçue pour traiter de genre de
choses.
En théorie, oui.
En pratique, si on n'a que quelques Mo de données, une BdD externe
n'est pas forcément indispensable.
De plus, la mode actuelle consiste à donner une interface web à
ce genre d'appli.
La mode actuelle, c'est aussi oublier C++ au profit de Java.
Je n'envisageais pas vraiment de gérer les données en interne. Une BdD relationnelle me semble quand même être conçue pour traiter de genre de choses.
En théorie, oui. En pratique, si on n'a que quelques Mo de données, une BdD externe n'est pas forcément indispensable.
De plus, la mode actuelle consiste à donner une interface web à ce genre d'appli.
La mode actuelle, c'est aussi oublier C++ au profit de Java.
-- ;-)
Pierre Maurette
Fabien LE LEZ a écrit:
On Fri, 19 Nov 2004 22:58:51 +0100, Loïc Joly :
non, ce n'est pas parce que "ca marche" que c'est forcément bien, Sauf si l'on décide que ce qui est "bien", c'est ce que "ca marche",
dans le cadre précis du projet. "ca marche" ne signifie pas "ca marche une fois" mais bien que le fonctionnement correspond fiablement aux attentes. En revanche, il est certain qu'une application ne peut être déclarée aboutie dès qu'elle passe quelques tests. En d'autres termes, il s'agit d'être prudent avec l'adverbe "bien", voire de l'éviter dans ce contexte, vu sa forte connotation morale.
En plus, prendre bien soin de compiler ses programmes avec deux ou trois compilateurs différents. Par exemple, développer sous Borland C++ et tester de temps en temps avec gcc -Wall. Ce n'est pas raisonnable. Déconseillez l'utilisation d'un RAD si vous
le sentez, mais ne l'associez pas à une impossible triple compilation.
La conformité à une norme, la portabilité, est une caractéristique technique qui peut éventuellement être inscrite au cahier des charges d'un projet. On peut très bien ne pas l'exiger, de par le choix d'un environnement de développement ou tout simplement parce que l'essence même du travail le rend non portable. Cela ne signifie pas que le programmeur ignore l'existence d'une norme, et ne permet pas d'affirmer qu'il ne fait pas du C++.
J'ajoute que viser l'excellence, la compétence absolue, n'est pas la seule approche respectable d'un langage comme C++. Viser le minimum permettant un résultat est sans doute une bonne idée, quand dans le cadre d'un projet personnel, il faut également procéder à une analyse, découvrir l'EDI, potasser la structure générale et certains points particuliers de l'OS, etc.
-- Pierre
Fabien LE LEZ <gramster@gramster.com> a écrit:
On Fri, 19 Nov 2004 22:58:51 +0100, Loïc Joly
<loic.actarus.joly@wanadoo.fr>:
non, ce n'est pas parce que "ca marche" que c'est forcément bien,
Sauf si l'on décide que ce qui est "bien", c'est ce que "ca marche",
dans le cadre précis du projet. "ca marche" ne signifie pas "ca marche
une fois" mais bien que le fonctionnement correspond fiablement aux
attentes. En revanche, il est certain qu'une application ne peut être
déclarée aboutie dès qu'elle passe quelques tests.
En d'autres termes, il s'agit d'être prudent avec l'adverbe "bien",
voire de l'éviter dans ce contexte, vu sa forte connotation morale.
En plus, prendre bien soin de compiler ses programmes avec deux ou
trois compilateurs différents. Par exemple, développer sous Borland
C++ et tester de temps en temps avec gcc -Wall.
Ce n'est pas raisonnable. Déconseillez l'utilisation d'un RAD si vous
le sentez, mais ne l'associez pas à une impossible triple compilation.
La conformité à une norme, la portabilité, est une caractéristique
technique qui peut éventuellement être inscrite au cahier des charges
d'un projet. On peut très bien ne pas l'exiger, de par le choix d'un
environnement de développement ou tout simplement parce que l'essence
même du travail le rend non portable. Cela ne signifie pas que le
programmeur ignore l'existence d'une norme, et ne permet pas
d'affirmer qu'il ne fait pas du C++.
J'ajoute que viser l'excellence, la compétence absolue, n'est pas la
seule approche respectable d'un langage comme C++. Viser le minimum
permettant un résultat est sans doute une bonne idée, quand dans le
cadre d'un projet personnel, il faut également procéder à une analyse,
découvrir l'EDI, potasser la structure générale et certains points
particuliers de l'OS, etc.
non, ce n'est pas parce que "ca marche" que c'est forcément bien, Sauf si l'on décide que ce qui est "bien", c'est ce que "ca marche",
dans le cadre précis du projet. "ca marche" ne signifie pas "ca marche une fois" mais bien que le fonctionnement correspond fiablement aux attentes. En revanche, il est certain qu'une application ne peut être déclarée aboutie dès qu'elle passe quelques tests. En d'autres termes, il s'agit d'être prudent avec l'adverbe "bien", voire de l'éviter dans ce contexte, vu sa forte connotation morale.
En plus, prendre bien soin de compiler ses programmes avec deux ou trois compilateurs différents. Par exemple, développer sous Borland C++ et tester de temps en temps avec gcc -Wall. Ce n'est pas raisonnable. Déconseillez l'utilisation d'un RAD si vous
le sentez, mais ne l'associez pas à une impossible triple compilation.
La conformité à une norme, la portabilité, est une caractéristique technique qui peut éventuellement être inscrite au cahier des charges d'un projet. On peut très bien ne pas l'exiger, de par le choix d'un environnement de développement ou tout simplement parce que l'essence même du travail le rend non portable. Cela ne signifie pas que le programmeur ignore l'existence d'une norme, et ne permet pas d'affirmer qu'il ne fait pas du C++.
J'ajoute que viser l'excellence, la compétence absolue, n'est pas la seule approche respectable d'un langage comme C++. Viser le minimum permettant un résultat est sans doute une bonne idée, quand dans le cadre d'un projet personnel, il faut également procéder à une analyse, découvrir l'EDI, potasser la structure générale et certains points particuliers de l'OS, etc.
-- Pierre
Fabien LE LEZ
On Sat, 20 Nov 2004 05:16:22 +0100, Pierre Maurette :
Sauf si l'on décide que ce qui est "bien", c'est ce que "ca marche", dans le cadre précis du projet.
Je programme généralement sous Windows, et il y a autant de versions différentes de Windows que de builts de Linux. Du coup, si je ne suis pas rigoureusement la documentation de l'API, je ne peux pas savoir si ça marche partout, car je ne peux pas tester sur toutes les versions de Windows existantes (sans compter les différences dûes aux drivers).
En résumé, quel que soit le nombre de tests effectués, on ne peut jamais dire "ça marche", mais "ça a l'air de marcher".
-- ;-)
On Sat, 20 Nov 2004 05:16:22 +0100, Pierre Maurette
<maurettepierre@wanadoo.fr>:
Sauf si l'on décide que ce qui est "bien", c'est ce que "ca marche",
dans le cadre précis du projet.
Je programme généralement sous Windows, et il y a autant de versions
différentes de Windows que de builts de Linux. Du coup, si je ne suis
pas rigoureusement la documentation de l'API, je ne peux pas savoir si
ça marche partout, car je ne peux pas tester sur toutes les versions
de Windows existantes (sans compter les différences dûes aux drivers).
En résumé, quel que soit le nombre de tests effectués, on ne peut
jamais dire "ça marche", mais "ça a l'air de marcher".
On Sat, 20 Nov 2004 05:16:22 +0100, Pierre Maurette :
Sauf si l'on décide que ce qui est "bien", c'est ce que "ca marche", dans le cadre précis du projet.
Je programme généralement sous Windows, et il y a autant de versions différentes de Windows que de builts de Linux. Du coup, si je ne suis pas rigoureusement la documentation de l'API, je ne peux pas savoir si ça marche partout, car je ne peux pas tester sur toutes les versions de Windows existantes (sans compter les différences dûes aux drivers).
En résumé, quel que soit le nombre de tests effectués, on ne peut jamais dire "ça marche", mais "ça a l'air de marcher".
-- ;-)
Pierre Maurette
Fabien LE LEZ a écrit:
On Sat, 20 Nov 2004 05:16:22 +0100, Pierre Maurette :
Sauf si l'on décide que ce qui est "bien", c'est ce que "ca marche", dans le cadre précis du projet.
Je programme généralement sous Windows, et il y a autant de versions différentes de Windows que de builts de Linux. Du coup, si je ne suis pas rigoureusement la documentation de l'API, je ne peux pas savoir si ça marche partout, car je ne peux pas tester sur toutes les versions de Windows existantes (sans compter les différences dûes aux drivers). C'est effectivement une horreur. Même en ciblant étroit par
vérification positive dans l'init, il faut encore des vérifs dans les modules, des appels à blanc (je pense à TAPI, RAS par exemple). En fait, c'est un point qui me dissuade de mettre en ligne des trucs sympas et qui me servent bien. Avec le fait que je ne suis pas nécessairement cerftain de l'exemplarite de mon code ;-) (euphémisme). Encore que certains trucs que j'ai téléchargé auraient du me rassurer sur ce point.
En résumé, quel que soit le nombre de tests effectués, on ne peut jamais dire "ça marche", mais "ça a l'air de marcher". Of course.
-- Pierre
Fabien LE LEZ <gramster@gramster.com> a écrit:
On Sat, 20 Nov 2004 05:16:22 +0100, Pierre Maurette
<maurettepierre@wanadoo.fr>:
Sauf si l'on décide que ce qui est "bien", c'est ce que "ca marche",
dans le cadre précis du projet.
Je programme généralement sous Windows, et il y a autant de versions
différentes de Windows que de builts de Linux. Du coup, si je ne suis
pas rigoureusement la documentation de l'API, je ne peux pas savoir si
ça marche partout, car je ne peux pas tester sur toutes les versions
de Windows existantes (sans compter les différences dûes aux drivers).
C'est effectivement une horreur. Même en ciblant étroit par
vérification positive dans l'init, il faut encore des vérifs dans les
modules, des appels à blanc (je pense à TAPI, RAS par exemple).
En fait, c'est un point qui me dissuade de mettre en ligne des trucs
sympas et qui me servent bien. Avec le fait que je ne suis pas
nécessairement cerftain de l'exemplarite de mon code ;-) (euphémisme).
Encore que certains trucs que j'ai téléchargé auraient du me rassurer
sur ce point.
En résumé, quel que soit le nombre de tests effectués, on ne peut
jamais dire "ça marche", mais "ça a l'air de marcher".
Of course.
On Sat, 20 Nov 2004 05:16:22 +0100, Pierre Maurette :
Sauf si l'on décide que ce qui est "bien", c'est ce que "ca marche", dans le cadre précis du projet.
Je programme généralement sous Windows, et il y a autant de versions différentes de Windows que de builts de Linux. Du coup, si je ne suis pas rigoureusement la documentation de l'API, je ne peux pas savoir si ça marche partout, car je ne peux pas tester sur toutes les versions de Windows existantes (sans compter les différences dûes aux drivers). C'est effectivement une horreur. Même en ciblant étroit par
vérification positive dans l'init, il faut encore des vérifs dans les modules, des appels à blanc (je pense à TAPI, RAS par exemple). En fait, c'est un point qui me dissuade de mettre en ligne des trucs sympas et qui me servent bien. Avec le fait que je ne suis pas nécessairement cerftain de l'exemplarite de mon code ;-) (euphémisme). Encore que certains trucs que j'ai téléchargé auraient du me rassurer sur ce point.
En résumé, quel que soit le nombre de tests effectués, on ne peut jamais dire "ça marche", mais "ça a l'air de marcher". Of course.
-- Pierre
Fabien LE LEZ
On Sat, 20 Nov 2004 14:25:46 +0100, Pierre Maurette :
Avec le fait que je ne suis pas nécessairement cerftain de l'exemplarite de mon code ;-) (euphémisme). Encore que certains trucs que j'ai téléchargé auraient du me rassurer sur ce point.
Ils n'ont pas à te rassurer sur la qualité de ton code (bien des codes disponibles sur le web sont totalement illisibles) ; par contre, ils prouvent que tu peux toujours publier du code, même s'il est catastrophique -- à condition bien sûr de n'avoir pas beaucoup d'amour-propre...
-- ;-)
On Sat, 20 Nov 2004 14:25:46 +0100, Pierre Maurette
<maurettepierre@wanadoo.fr>:
Avec le fait que je ne suis pas
nécessairement cerftain de l'exemplarite de mon code ;-) (euphémisme).
Encore que certains trucs que j'ai téléchargé auraient du me rassurer
sur ce point.
Ils n'ont pas à te rassurer sur la qualité de ton code (bien des codes
disponibles sur le web sont totalement illisibles) ; par contre, ils
prouvent que tu peux toujours publier du code, même s'il est
catastrophique -- à condition bien sûr de n'avoir pas beaucoup
d'amour-propre...
On Sat, 20 Nov 2004 14:25:46 +0100, Pierre Maurette :
Avec le fait que je ne suis pas nécessairement cerftain de l'exemplarite de mon code ;-) (euphémisme). Encore que certains trucs que j'ai téléchargé auraient du me rassurer sur ce point.
Ils n'ont pas à te rassurer sur la qualité de ton code (bien des codes disponibles sur le web sont totalement illisibles) ; par contre, ils prouvent que tu peux toujours publier du code, même s'il est catastrophique -- à condition bien sûr de n'avoir pas beaucoup d'amour-propre...
-- ;-)
drkm
Pierre Maurette writes:
Fabien LE LEZ a écrit:
En plus, prendre bien soin de compiler ses programmes avec deux ou trois compilateurs différents. Par exemple, développer sous Borland C++ et tester de temps en temps avec gcc -Wall.
Ce n'est pas raisonnable.
Cela me semble au contraire plutôt raisonnable. Pourquoi ne l'est-ce pas ?
Déconseillez l'utilisation d'un RAD si vous le sentez,
Je comprends pas l'allusion ...
mais ne l'associez pas à une impossible triple compilation.
Qu'entends-tu par « impossible triple compilation » ?
--drkm
Pierre Maurette <maurettepierre@wanadoo.fr> writes:
Fabien LE LEZ <gramster@gramster.com> a écrit:
En plus, prendre bien soin de compiler ses programmes avec deux ou
trois compilateurs différents. Par exemple, développer sous Borland
C++ et tester de temps en temps avec gcc -Wall.
Ce n'est pas raisonnable.
Cela me semble au contraire plutôt raisonnable. Pourquoi ne
l'est-ce pas ?
Déconseillez l'utilisation d'un RAD si vous
le sentez,
Je comprends pas l'allusion ...
mais ne l'associez pas à une impossible triple compilation.
Qu'entends-tu par « impossible triple compilation » ?
En plus, prendre bien soin de compiler ses programmes avec deux ou trois compilateurs différents. Par exemple, développer sous Borland C++ et tester de temps en temps avec gcc -Wall.
Ce n'est pas raisonnable.
Cela me semble au contraire plutôt raisonnable. Pourquoi ne l'est-ce pas ?
Déconseillez l'utilisation d'un RAD si vous le sentez,
Je comprends pas l'allusion ...
mais ne l'associez pas à une impossible triple compilation.
Qu'entends-tu par « impossible triple compilation » ?
