Discussion :

[Davidbrcz]

Bonjour,

Les mots clé new et delete seraient donc obsolète?
Je dois être drôlement en retard

Comme le fait remarquer Jean-Marc.Bourguet , ils sont encapsulés.
En C++, on ne manipule presque plus de pointeur brut, on préfère des pointeurs intelligents (boost, ceux de C++1x) qui garantissent une destruction transparente via le RAII et assure un code exception-safe.

De même, on ne manipule ni new[] pour les tableaux (ni des maillons pour les listes) mais std::vector et std::list qui garantissent un code exception-safe et offrent de nombreuses facilités pour la gestion de la mémoire (en gros, tu n'as plus à t'en soucier).

Si tu veux approfondir cela, regarde la FAQ C++.

[Invité]

Merci,
J'ai pas tout lu dans la FAQ, mais je n'ai que C++ Builder 6.
Je ne peux qu'en déduire que je suis un (void*)NULL.
En matière de développement, ça va pas mal, merci, en matière de programmation, par contre, j'ai certainement beaucoup à apprendre. Mais les langues, ça n'a jamais été mon fort.
D'une façon générale, je considère qu'on ne doit pas demander à une machine de faire ce qu'on ne saurait pas faire à la main, ou qu'on ne saurait pas expliquer. C'est surtout vrai dans un domaine que je connais un peu (CAO - SIG) mais c'est vrai aussi en informatique. Il me parait choquant qu'on apprenne à des étudiants à utiliser std::string s'ils ne savent pas ce qu'est une chaine, un 0 terminal etc.
Cordialement.

[3DArchi]

Tu vas trouver dans le C++ notions de "données allouées sur la pile" , "sur le tas", "données statiques" et enfin "données contiguës en mémoire"

Je peux me tromper mais il me semble que la norme ne parle jamais de tas ou de pile. Ce qui est précisé ce sont les durées de vie, les appels (automatique ou non) aux constructeurs/destructeurs. En revanche, en théorie, rien n'oblige d'avoir un tas et une pile (certains systèmes embarqués ne travaillent qu'avec une pile et n'ont pas de tas).

D'une façon générale, je considère qu'on ne doit pas demander à une machine de faire ce qu'on ne saurait pas faire à la main, ou qu'on ne saurait pas expliquer. C'est surtout vrai dans un domaine que je connais un peu (CAO - SIG) mais c'est vrai aussi en informatique. Il me parait choquant qu'on apprenne à des étudiants à utiliser std::string s'ils ne savent pas ce qu'est une chaine, un 0 terminal etc.

A un moment il faut savoir travailler avec des concepts donnés comme tels. On apprend à compter (au CP) avant de définir les nombres (bac + des bananes) 'mathématiquement'. Une fois qu'on a assimilé un certain nombre de ces concepts, effectivement, il est enrichissant d'aller plus loin. Mais c'est toujours le vieux débat bottom/up vs up/bottom.

[peufeu]

Il est possible de ne pas avoir de tas, dans ce cas tu n'as ni malloc() ni new, et donc toutes tes variables et objets sont soit sur la pile (variables locales, plus alloca()) soit globales (vraies globales, ou static dans un fichier, une classe ou une fonction). Il est courant en embarqué de ne pas avoir de tas. Par exemple le CPU qui est dans ta souris a probablement quelque chose comme 128 octets de RAM et pas vraiment besoin d'allocation dynamique (ni de C++ d'ailleurs !...)

Ne pas avoir de pile ne permettrait pas de faire d'appels de fonctions et t'interdirait les variables locales, par conséquent les programmes que tu pourrais écrire seraient quelque peu limités

Je comprend par cela que les segments cités peuvent être considérés par le compilateur et le linker et pourquoi pas garder cette représentation en segments dans la gestion de la mémoire physique.

Raisons diverses, entre autres le CPU gère la mémoire sous forme de pages (généralement 4k) et les segments de ton exécutables ne sont pas en multiples de 4k. Aussi ce sont 2 choses différentes, l'OS gère toute la RAM pas juste celle où tu charges ton exécutable.

[Jean-Marc.Bourguet]

Ne pas avoir de pile ne permettrait pas de faire d'appels de fonctions et t'interdirait les variables locales, par conséquent les programmes que tu pourrais écrire seraient quelque peu limités

Il y a eu un certain nombre de processeurs sans pile hard. Une partie du folklore sur le cout de la recursivite vient de ces processeurs -- sur lesquels une fonction recursive doit gerer "manuellement" une pile tandis qu'une fonction non recursive peut utiliser d'autres techniques mieux supportees par le processeur. Il y a toujours des processeurs RISC qui n'ont pas de pile, juste une convention bien etablie (et parfois imposee par l'OS) d'utiliser un registre donne comme pointeur de pile; mais ce registre n'a rien de special par rapport aux autres.

[peufeu]

> Il y a toujours des processeurs RISC qui n'ont pas de pile

Quelle que soit l'implémentation (registre spécifié par le hard ou la convention), à partir du moment où tu empiles des trucs dessus, c'est une pile

[Jean-Marc.Bourguet]

> Il y a toujours des processeurs RISC qui n'ont pas de pile

Quelle que soit l'implémentation (registre spécifié par le hard ou la convention), à partir du moment où tu empiles des trucs dessus, c'est une pile

Rien ne t'oblige a faire une pile. C'est juste une convention et en embarque particulièrement, on peut désirer ne pas la suivre. Mais on ne concevra vraisemblablement plus des processeurs sur lesquels avoir une pile est beaucoup plus coûteux que les autres choix.

[koala01]

Salut,

<snip>Il me parait choquant qu'on apprenne à des étudiants à utiliser std::string s'ils ne savent pas ce qu'est une chaine, un 0 terminal etc.
Cordialement.

Il ne faut pas oublier non plus que les notions même d'allocation dynamique, de pointeur ou de 0 terminal sont propres au C et aux autres langages qui s'en sont plus ou moins inspiré.

La notion d'entier elle-même n'est jamais qu'une manière de voir les choses que les développeurs originels de ces langages ont décidé d'utiliser / de reprendre.

Je sais que c'est un vieux langage de niche, mais, si tu venais à t'intéresser un peu à cobol, par exemple, tu aurais de grandes chances de tomber des nues si tu considères ces quelques concepts comme inébranlables et "universels"

[Davidbrcz]

Il me parait choquant qu'on apprenne à des étudiants à utiliser std::string s'ils ne savent pas ce qu'est une chaine, un 0 terminal etc.

Pour conduire, on te donne une formation complète sur comment marche un moteur ?

Et ben pour la programmation c'est pareil. Pas besoin de savoir comment marche une chose pour l'utiliser, suffit de savoir lire un mode d'emploi. Pour utiliser std::string, il suffit de lire la documentation.

[Invité]

Je suis assez d'accord avec la comparaison du permis de conduire, et je crois me souvenir que le code de la route utilisé par mes enfants comportait un chapitre sur les moteurs, la direction et je ne sais quoi.
Mais comme il y a bien longtemps que l'ai passé, je ne me souviens plus les détails, mais je savais très bien comment fonctionnait un moteur.

Pour en revenir à l'informatique, j'ai utilisé beaucoup de langages, mais pas le Cobol. Par contre, je ne crois pas qu'on aurait réussi à me faire écrire une instruction si je ne savais pas ce que ça voulait dire.
Pour vérifier que ma façon de voir les choses n'est pas tout à fait débile, il suffit de lire les questions posées, en particulier à propos de chaines de caractères.

Il ne faut pas oublier non plus que les notions même d'allocation dynamique, de pointeur ou de 0 terminal sont propres au C et aux autres langages qui s'en sont plus ou moins inspiré.

... et le langage C++ est une extension du C (citation d'un modérateur sur ce forum) cf réponse précédente, mais qu'on ne me demande pas de nouveau l'url

C'est un sujet auquel j'attache de l'importance, en programmation comme en utilisation, mais cela fait l'objet d'un autre forum.
J'ai des exemples très précis, mais je ne les expliquerai pas en public.

Bonne soirée.

[Goten]

... et le langage C++ est une extension du C (citation d'un modérateur sur ce forum) cf réponse précédente, mais qu'on ne me demande pas de nouveau l'url

Les modérateurs ne disent pas que des choses vraie... la preuve ici .
Non le langage C++ n'est pas le C. Ni même une extension. (cf le Père).
Y'a déjà eu des tonnes de discussion sur ça ici.