On 2009-07-09, Michael Doubez wrote:
>> souvent pas de pointeur, et parfois
>> même pas de variable sur la pile (tout en static).
> Le standard C++ ne prévoit pas de stack, juste un temps de vie des
> variables.
Ne pinaille pas: tu parles de "dépassement de pile" dans le paragra phe
au dessus, qui n'est prévu ni par le standard C, ni le C++.
On 2009-07-09, Michael Doubez <michael.dou...@free.fr> wrote:
>> souvent pas de pointeur, et parfois
>> même pas de variable sur la pile (tout en static).
> Le standard C++ ne prévoit pas de stack, juste un temps de vie des
> variables.
Ne pinaille pas: tu parles de "dépassement de pile" dans le paragra phe
au dessus, qui n'est prévu ni par le standard C, ni le C++.
On 2009-07-09, Michael Doubez wrote:
>> souvent pas de pointeur, et parfois
>> même pas de variable sur la pile (tout en static).
> Le standard C++ ne prévoit pas de stack, juste un temps de vie des
> variables.
Ne pinaille pas: tu parles de "dépassement de pile" dans le paragra phe
au dessus, qui n'est prévu ni par le standard C, ni le C++.
> Je ne saurait que vous conseiller deux ouvrages d'Andrew Tanenbaum,
"les réseaux" et "systèmes d'exploitation". Et puis
"Accelerated C++" aussi, de Koenig et Moo.
Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.http://www.inega lites.fr/spip.php?article1&id_mot0
> Je ne saurait que vous conseiller deux ouvrages d'Andrew Tanenbaum,
"les réseaux" et "systèmes d'exploitation". Et puis
"Accelerated C++" aussi, de Koenig et Moo.
Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.http://www.inega lites.fr/spip.php?article1&id_mot=130
> Je ne saurait que vous conseiller deux ouvrages d'Andrew Tanenbaum,
"les réseaux" et "systèmes d'exploitation". Et puis
"Accelerated C++" aussi, de Koenig et Moo.
Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.http://www.inega lites.fr/spip.php?article1&id_mot0
On 2009-07-08, wrote:Bonjour,
Je commence à apprendre le C le soir et le week-end sans expérience
particulière en informatique ni mathématique ou électronique. Je suis
comptable de formation. La programmation peut être intéressante je
pense pour des systèmes de gestion de données comme Oracle. A
condition d'élargir l'apprentissage de la programmation à java.
De toute façon, une formation d'informaticien ne saurait se
restreindre à un seul langage, surtout un impératif type C. Il
faudrait aussi un moins un langage orienté objet (C++ ou Java),
un langage fonctionnel (Caml, Haskell, Lisp...), et puis une
formation en algorithmique.
Et puis un peu de compilation, un peu de réseau, un soupson
de complexité, un peu de base de donnée, de l'architecture
des ordinateurs, etc.
Enfin, il suffit d'aller regarder le programme des DUT d'info quoi...Je
pense que sur 3 ou 5 ans, je peux acquérir une petite adresse. Si
j'ajoute un congé de 3-6 mois pour une formation intensive en Inde,
peut-être je peux devenir l'auxiliaire d'un consultant
Pourquoi pas un DUT en un an tout simplement ?
Pour en revenir à la discussion sur les différents langages
informatiques, il me semble comprendre que le C permet de faire des
choses variées.
On devrait même pouvoir dire qu'il permet de tout faire
de ce qu'on peut faire avec un ordinateur, ou presque (pour
aller positionner certains flags du processeur, il faut
aller taper directement l'ASM).
On 2009-07-08, bpascal123@googlemail.com <bpascal123@googlemail.com> wrote:
Bonjour,
Je commence à apprendre le C le soir et le week-end sans expérience
particulière en informatique ni mathématique ou électronique. Je suis
comptable de formation. La programmation peut être intéressante je
pense pour des systèmes de gestion de données comme Oracle. A
condition d'élargir l'apprentissage de la programmation à java.
De toute façon, une formation d'informaticien ne saurait se
restreindre à un seul langage, surtout un impératif type C. Il
faudrait aussi un moins un langage orienté objet (C++ ou Java),
un langage fonctionnel (Caml, Haskell, Lisp...), et puis une
formation en algorithmique.
Et puis un peu de compilation, un peu de réseau, un soupson
de complexité, un peu de base de donnée, de l'architecture
des ordinateurs, etc.
Enfin, il suffit d'aller regarder le programme des DUT d'info quoi...
Je
pense que sur 3 ou 5 ans, je peux acquérir une petite adresse. Si
j'ajoute un congé de 3-6 mois pour une formation intensive en Inde,
peut-être je peux devenir l'auxiliaire d'un consultant
Pourquoi pas un DUT en un an tout simplement ?
Pour en revenir à la discussion sur les différents langages
informatiques, il me semble comprendre que le C permet de faire des
choses variées.
On devrait même pouvoir dire qu'il permet de tout faire
de ce qu'on peut faire avec un ordinateur, ou presque (pour
aller positionner certains flags du processeur, il faut
aller taper directement l'ASM).
On 2009-07-08, wrote:Bonjour,
Je commence à apprendre le C le soir et le week-end sans expérience
particulière en informatique ni mathématique ou électronique. Je suis
comptable de formation. La programmation peut être intéressante je
pense pour des systèmes de gestion de données comme Oracle. A
condition d'élargir l'apprentissage de la programmation à java.
De toute façon, une formation d'informaticien ne saurait se
restreindre à un seul langage, surtout un impératif type C. Il
faudrait aussi un moins un langage orienté objet (C++ ou Java),
un langage fonctionnel (Caml, Haskell, Lisp...), et puis une
formation en algorithmique.
Et puis un peu de compilation, un peu de réseau, un soupson
de complexité, un peu de base de donnée, de l'architecture
des ordinateurs, etc.
Enfin, il suffit d'aller regarder le programme des DUT d'info quoi...Je
pense que sur 3 ou 5 ans, je peux acquérir une petite adresse. Si
j'ajoute un congé de 3-6 mois pour une formation intensive en Inde,
peut-être je peux devenir l'auxiliaire d'un consultant
Pourquoi pas un DUT en un an tout simplement ?
Pour en revenir à la discussion sur les différents langages
informatiques, il me semble comprendre que le C permet de faire des
choses variées.
On devrait même pouvoir dire qu'il permet de tout faire
de ce qu'on peut faire avec un ordinateur, ou presque (pour
aller positionner certains flags du processeur, il faut
aller taper directement l'ASM).
Tout à fait. Il te faut faire une "vraie" formation à l'informatique.
A part quelques exceptions, tous les "informaticiens" que j'ai côtoyés
et qui s'étaient formés tout seul, c'était une catastrophe...
Tout à fait. Il te faut faire une "vraie" formation à l'informatique.
A part quelques exceptions, tous les "informaticiens" que j'ai côtoyés
et qui s'étaient formés tout seul, c'était une catastrophe...
Tout à fait. Il te faut faire une "vraie" formation à l'informatique.
A part quelques exceptions, tous les "informaticiens" que j'ai côtoyés
et qui s'étaient formés tout seul, c'était une catastrophe...
En fait, je voulais savoir si on peut tronquer un signal gps. Par
exemple, je commets une infraction du code de la route sur une route
x, à une heure t, est-ce que je peux modifier la mémoire du téléphone
et dire que j'étais dans une autre ville...dans une rue piétonne...?
En fait, je voulais savoir si on peut tronquer un signal gps. Par
exemple, je commets une infraction du code de la route sur une route
x, à une heure t, est-ce que je peux modifier la mémoire du téléphone
et dire que j'étais dans une autre ville...dans une rue piétonne...?
En fait, je voulais savoir si on peut tronquer un signal gps. Par
exemple, je commets une infraction du code de la route sur une route
x, à une heure t, est-ce que je peux modifier la mémoire du téléphone
et dire que j'étais dans une autre ville...dans une rue piétonne...?
On 9 juil, 10:37, Marc Boyer wrote:On 2009-07-09, Michael Doubez wrote:
[snip]>> souvent pas de pointeur, et parfois
>> même pas de variable sur la pile (tout en static).
> Le standard C++ ne prévoit pas de stack, juste un temps de vie des
> variables.
Ne pinaille pas: tu parles de "dépassement de pile" dans le paragraphe
au dessus, qui n'est prévu ni par le standard C, ni le C++.
Pardon.
Enfin, si je voudrais pinailler un peu parce que la plupart des
langages font qu'une stack est très utile et je ne pense pas que c'est
ce qu'ils entendent pas sous-ensemble safe.
Mais qu'ils disent qu'il y a des parites *unsafe*... j'aimerais en
savoir plus sur leur motivation.
On 9 juil, 10:37, Marc Boyer <Marc.Bo...@cert.onera.fr.invalid> wrote:
On 2009-07-09, Michael Doubez <michael.dou...@free.fr> wrote:
[snip]
>> souvent pas de pointeur, et parfois
>> même pas de variable sur la pile (tout en static).
> Le standard C++ ne prévoit pas de stack, juste un temps de vie des
> variables.
Ne pinaille pas: tu parles de "dépassement de pile" dans le paragraphe
au dessus, qui n'est prévu ni par le standard C, ni le C++.
Pardon.
Enfin, si je voudrais pinailler un peu parce que la plupart des
langages font qu'une stack est très utile et je ne pense pas que c'est
ce qu'ils entendent pas sous-ensemble safe.
Mais qu'ils disent qu'il y a des parites *unsafe*... j'aimerais en
savoir plus sur leur motivation.
On 9 juil, 10:37, Marc Boyer wrote:On 2009-07-09, Michael Doubez wrote:
[snip]>> souvent pas de pointeur, et parfois
>> même pas de variable sur la pile (tout en static).
> Le standard C++ ne prévoit pas de stack, juste un temps de vie des
> variables.
Ne pinaille pas: tu parles de "dépassement de pile" dans le paragraphe
au dessus, qui n'est prévu ni par le standard C, ni le C++.
Pardon.
Enfin, si je voudrais pinailler un peu parce que la plupart des
langages font qu'une stack est très utile et je ne pense pas que c'est
ce qu'ils entendent pas sous-ensemble safe.
Mais qu'ils disent qu'il y a des parites *unsafe*... j'aimerais en
savoir plus sur leur motivation.
On 2009-07-09, Michael Doubez wrote:
> On 9 juil, 10:37, Marc Boyer wrote:
>> On 2009-07-09, Michael Doubez wrote:
> [snip]
>> >> souvent pas de pointeur, et parfois
>> >> même pas de variable sur la pile (tout en static).
>> > Le standard C++ ne prévoit pas de stack, juste un temps de vie des
>> > variables.
>> Ne pinaille pas: tu parles de "dépassement de pile" dans le para graphe
>> au dessus, qui n'est prévu ni par le standard C, ni le C++.
> Pardon.
> Enfin, si je voudrais pinailler un peu parce que la plupart des
> langages font qu'une stack est très utile et je ne pense pas que c'es t
> ce qu'ils entendent pas sous-ensemble safe.
Pourtant, "stack overflow" est une erreur bien connue, et en C,
je ne connais aucun moyen de s'en prémunir.
> Mais qu'ils disent qu'il y a des parites *unsafe*... j'aimerais en
> savoir plus sur leur motivation.
Tu dois renverser ton raisonnement quand tu parles de système criti que.
La question n'est pas d'identifier les paries "unsafe", mais les
parties certifiables dans un contexte matériel, environnemental,
le tout dans un processus de certification/d'assurance.
On 2009-07-09, Michael Doubez <michael.dou...@free.fr> wrote:
> On 9 juil, 10:37, Marc Boyer <Marc.Bo...@cert.onera.fr.invalid> wrote:
>> On 2009-07-09, Michael Doubez <michael.dou...@free.fr> wrote:
> [snip]
>> >> souvent pas de pointeur, et parfois
>> >> même pas de variable sur la pile (tout en static).
>> > Le standard C++ ne prévoit pas de stack, juste un temps de vie des
>> > variables.
>> Ne pinaille pas: tu parles de "dépassement de pile" dans le para graphe
>> au dessus, qui n'est prévu ni par le standard C, ni le C++.
> Pardon.
> Enfin, si je voudrais pinailler un peu parce que la plupart des
> langages font qu'une stack est très utile et je ne pense pas que c'es t
> ce qu'ils entendent pas sous-ensemble safe.
Pourtant, "stack overflow" est une erreur bien connue, et en C,
je ne connais aucun moyen de s'en prémunir.
> Mais qu'ils disent qu'il y a des parites *unsafe*... j'aimerais en
> savoir plus sur leur motivation.
Tu dois renverser ton raisonnement quand tu parles de système criti que.
La question n'est pas d'identifier les paries "unsafe", mais les
parties certifiables dans un contexte matériel, environnemental,
le tout dans un processus de certification/d'assurance.
On 2009-07-09, Michael Doubez wrote:
> On 9 juil, 10:37, Marc Boyer wrote:
>> On 2009-07-09, Michael Doubez wrote:
> [snip]
>> >> souvent pas de pointeur, et parfois
>> >> même pas de variable sur la pile (tout en static).
>> > Le standard C++ ne prévoit pas de stack, juste un temps de vie des
>> > variables.
>> Ne pinaille pas: tu parles de "dépassement de pile" dans le para graphe
>> au dessus, qui n'est prévu ni par le standard C, ni le C++.
> Pardon.
> Enfin, si je voudrais pinailler un peu parce que la plupart des
> langages font qu'une stack est très utile et je ne pense pas que c'es t
> ce qu'ils entendent pas sous-ensemble safe.
Pourtant, "stack overflow" est une erreur bien connue, et en C,
je ne connais aucun moyen de s'en prémunir.
> Mais qu'ils disent qu'il y a des parites *unsafe*... j'aimerais en
> savoir plus sur leur motivation.
Tu dois renverser ton raisonnement quand tu parles de système criti que.
La question n'est pas d'identifier les paries "unsafe", mais les
parties certifiables dans un contexte matériel, environnemental,
le tout dans un processus de certification/d'assurance.
On 9 juil, 12:54, Marc Boyer wrote:On 2009-07-09, Michael Doubez wrote:
Pourtant, "stack overflow" est une erreur bien connue, et en C,
je ne connais aucun moyen de s'en prémunir.
En C ou dans d'autre langage.
AMA, c'est une erreur au même titre qu'une FPE, ça ne tiens pas au
langage même si le langage peut masquer ces aspects.
> Mais qu'ils disent qu'il y a des parites *unsafe*... j'aimerais en
> savoir plus sur leur motivation.
Tu dois renverser ton raisonnement quand tu parles de système critique.
La question n'est pas d'identifier les paries "unsafe", mais les
parties certifiables dans un contexte matériel, environnemental,
le tout dans un processus de certification/d'assurance.
D'accord donc qu'est ce qu'ils n'ont pas pu certifier ?
Quelle partie du langage amènerait un programme unsafe (je parle pas
des fonctions unsafe par nature comme strlen ...) ?
On 9 juil, 12:54, Marc Boyer <Marc.Bo...@cert.onera.fr.invalid> wrote:
On 2009-07-09, Michael Doubez <michael.dou...@free.fr> wrote:
Pourtant, "stack overflow" est une erreur bien connue, et en C,
je ne connais aucun moyen de s'en prémunir.
En C ou dans d'autre langage.
AMA, c'est une erreur au même titre qu'une FPE, ça ne tiens pas au
langage même si le langage peut masquer ces aspects.
> Mais qu'ils disent qu'il y a des parites *unsafe*... j'aimerais en
> savoir plus sur leur motivation.
Tu dois renverser ton raisonnement quand tu parles de système critique.
La question n'est pas d'identifier les paries "unsafe", mais les
parties certifiables dans un contexte matériel, environnemental,
le tout dans un processus de certification/d'assurance.
D'accord donc qu'est ce qu'ils n'ont pas pu certifier ?
Quelle partie du langage amènerait un programme unsafe (je parle pas
des fonctions unsafe par nature comme strlen ...) ?
On 9 juil, 12:54, Marc Boyer wrote:On 2009-07-09, Michael Doubez wrote:
Pourtant, "stack overflow" est une erreur bien connue, et en C,
je ne connais aucun moyen de s'en prémunir.
En C ou dans d'autre langage.
AMA, c'est une erreur au même titre qu'une FPE, ça ne tiens pas au
langage même si le langage peut masquer ces aspects.
> Mais qu'ils disent qu'il y a des parites *unsafe*... j'aimerais en
> savoir plus sur leur motivation.
Tu dois renverser ton raisonnement quand tu parles de système critique.
La question n'est pas d'identifier les paries "unsafe", mais les
parties certifiables dans un contexte matériel, environnemental,
le tout dans un processus de certification/d'assurance.
D'accord donc qu'est ce qu'ils n'ont pas pu certifier ?
Quelle partie du langage amènerait un programme unsafe (je parle pas
des fonctions unsafe par nature comme strlen ...) ?
On 9 juil, 12:54, Marc Boyer wrote:On 2009-07-09, Michael Doubez wrote:
> On 9 juil, 10:37, Marc Boyer wrote:
>> On 2009-07-09, Michael Doubez wrote:
> [snip]
>> >> souvent pas de pointeur, et parfois
>> >> même pas de variable sur la pile (tout en static).
>> > Le standard C++ ne prévoit pas de stack, juste un temps de vie des
>> > variables.
>> Ne pinaille pas: tu parles de "dépassement de pile" dans le paragraphe
>> au dessus, qui n'est prévu ni par le standard C, ni le C++.
> Pardon.
> Enfin, si je voudrais pinailler un peu parce que la plupart des
> langages font qu'une stack est très utile et je ne pense pas que c'est
> ce qu'ils entendent pas sous-ensemble safe.
Pourtant, "stack overflow" est une erreur bien connue, et en C,
je ne connais aucun moyen de s'en prémunir.
En C ou dans d'autre langage.
AMA, c'est une erreur au même titre qu'une FPE, ça ne tiens pas au
langage même si le langage peut masquer ces aspects.
Tu dois renverser ton raisonnement quand tu parles de système critique.
La question n'est pas d'identifier les paries "unsafe", mais les
parties certifiables dans un contexte matériel, environnemental,
le tout dans un processus de certification/d'assurance.
D'accord donc qu'est ce qu'ils n'ont pas pu certifier ?
On 9 juil, 12:54, Marc Boyer <Marc.Bo...@cert.onera.fr.invalid> wrote:
On 2009-07-09, Michael Doubez <michael.dou...@free.fr> wrote:
> On 9 juil, 10:37, Marc Boyer <Marc.Bo...@cert.onera.fr.invalid> wrote:
>> On 2009-07-09, Michael Doubez <michael.dou...@free.fr> wrote:
> [snip]
>> >> souvent pas de pointeur, et parfois
>> >> même pas de variable sur la pile (tout en static).
>> > Le standard C++ ne prévoit pas de stack, juste un temps de vie des
>> > variables.
>> Ne pinaille pas: tu parles de "dépassement de pile" dans le paragraphe
>> au dessus, qui n'est prévu ni par le standard C, ni le C++.
> Pardon.
> Enfin, si je voudrais pinailler un peu parce que la plupart des
> langages font qu'une stack est très utile et je ne pense pas que c'est
> ce qu'ils entendent pas sous-ensemble safe.
Pourtant, "stack overflow" est une erreur bien connue, et en C,
je ne connais aucun moyen de s'en prémunir.
En C ou dans d'autre langage.
AMA, c'est une erreur au même titre qu'une FPE, ça ne tiens pas au
langage même si le langage peut masquer ces aspects.
Tu dois renverser ton raisonnement quand tu parles de système critique.
La question n'est pas d'identifier les paries "unsafe", mais les
parties certifiables dans un contexte matériel, environnemental,
le tout dans un processus de certification/d'assurance.
D'accord donc qu'est ce qu'ils n'ont pas pu certifier ?
On 9 juil, 12:54, Marc Boyer wrote:On 2009-07-09, Michael Doubez wrote:
> On 9 juil, 10:37, Marc Boyer wrote:
>> On 2009-07-09, Michael Doubez wrote:
> [snip]
>> >> souvent pas de pointeur, et parfois
>> >> même pas de variable sur la pile (tout en static).
>> > Le standard C++ ne prévoit pas de stack, juste un temps de vie des
>> > variables.
>> Ne pinaille pas: tu parles de "dépassement de pile" dans le paragraphe
>> au dessus, qui n'est prévu ni par le standard C, ni le C++.
> Pardon.
> Enfin, si je voudrais pinailler un peu parce que la plupart des
> langages font qu'une stack est très utile et je ne pense pas que c'est
> ce qu'ils entendent pas sous-ensemble safe.
Pourtant, "stack overflow" est une erreur bien connue, et en C,
je ne connais aucun moyen de s'en prémunir.
En C ou dans d'autre langage.
AMA, c'est une erreur au même titre qu'une FPE, ça ne tiens pas au
langage même si le langage peut masquer ces aspects.
Tu dois renverser ton raisonnement quand tu parles de système critique.
La question n'est pas d'identifier les paries "unsafe", mais les
parties certifiables dans un contexte matériel, environnemental,
le tout dans un processus de certification/d'assurance.
D'accord donc qu'est ce qu'ils n'ont pas pu certifier ?
Tout à fait. Il te faut faire une "vraie" formation à l'informatique.
A part quelques exceptions, tous les "informaticiens" que j'ai côtoyés
et qui s'étaient formés tout seul, c'était une catastrophe...
Tout à fait. Il te faut faire une "vraie" formation à l'informatique.
A part quelques exceptions, tous les "informaticiens" que j'ai côtoyés
et qui s'étaient formés tout seul, c'était une catastrophe...
Tout à fait. Il te faut faire une "vraie" formation à l'informatique.
A part quelques exceptions, tous les "informaticiens" que j'ai côtoyés
et qui s'étaient formés tout seul, c'était une catastrophe...