Début en C et C++

Pascal J. Bourguignon a écrit :

Fabien LE LEZ <gramster@gramster.com> writes:

Or pour implémenter ce nouveau langage, il faut savoir programmer en
C, car on ne peut utiliser que C pour implementer un stl::vector.

On a surtout besoin de pointeurs, mais a part ca il n'y a vraiement
pas besoin du C pour faire un std::vector.

pjb@informatimago.com (Pascal J. Bourguignon) writes:

[...]

| Le C est déjà un raccourci, le mieux serait de commencer par
| l'assembleur. ;-)

Le C est tout sauf un raccourci. Surtout, si le but est de progammmer
en C++.

| Bon, mais serrieusement, concernant le C++, le problème c'est que
| c'est un langage qui n'est pas fini.

Pardon ?

| Pour pouvoir l'utiliser en tant que C++ comme l'entendent ceux qui
| préconisent son apprentissage sans passer par C, il faut avoir
| implémenté une sacré bibliothèque de mécanismes de base (comme les
| soit-disant "Smart Pointer"), et d'objets, et il faut bien sur
| s'interdir d'utiliser tous les opérateurs du C problématiques.

C'est curieux, je n'ai jamais eu à faire ça. Les bibliothèqu es standard
me suffisent largement pour les choses d'ordre général -- et je
soupçonne qu'elle suffisent largement pour un débutant, comparà © au C.
Pour une application dans un domaine spécifique, ben il faut de toute
façon implémenter les abstractions du domaine considére, per tinentes
pour l'application considérée. Que ce soit du C ou C++.
La différence que c'est plus simple et facile de le faire de manià ¨re
robuste en C++. Et si on a commencé avec le C, il faudra désappen dre
ce qu'on appris en C pour écrire du C++ natif.

D'expérience, d'enseignant aux débutants (freshmen || sophomore), j'ai
vue une nette différence (e.g. amélioration) depuis qu'on enseign e du C++
natif (sans encombrement). Au deuxième cours, ils utilisent déj à
std::vector<> et std::list<>. Au cinquième cours, ils apprennent à  
gérer les erreurs avec les exceptions.

La recette est simple (et tu peux déjà la commander au cas oà ¹ tu es
curieux de savoir comment c'est possible) :

http://www.research.att.com/~bs/programming.html

-- Gaby

Pascal J. Bourguignon schrieb:

Bon, mais sérieusement, concernant le C++, le problème c'est que
c'est un langage qui n'est pas fini.

Non - on attend avec impatience la sortie de la nouvelle norme C++0x et
des compilateurs qui l'implémentent...

Pour pouvoir l'utiliser en tant que C++ comme l'entendent ceux qui
préconisent son apprentissage sans passer par C, il faut avoir
implémenté une sacré bibliothèque de mécanismes de base (comme les
soit-disant "Smart Pointer"), et d'objets, et il faut bien sur
s'interdire d'utiliser tous les opérateurs du C problématiques. En
clair, il faut avoir implémenté au dessus de C++ un nouveau langage et
n'utiliser que celui-ci.

Mais cette bibliothèque existe déjà, et on en dispose partout où il y a
un compilateur C++ puisqu'il s'agit de la bibliothèque Standard. Enfin,
pour certaines choses ayant un intérêt commun (shared_ptr, array,
thread, regex...) on est obligé d'aller chercher dans Boost, mais ça
devrait s'arranger avec C+0x.

Or pour implémenter ce nouveau langage, il faut savoir programmer en
C, car on ne peut utiliser que C pour implémenter un stl::vector.

On ne peut pas utiliser C pour implémenter std::vector car contrairement
à un compilateur C++, un compilateur C ne saura quoi faire d'une
définition du genre

namespace std
{
template<typename _Tp, typename _Alloc = allocator<_Tp> >
class vector
{
// ...
};
}

Et finalement, la bibliothèque standard actuelle de C++, la stl,
essaye bizarrement de simuler le plus possible le comportement des
opérateurs C. Un seul exemple, les itérateurs qui se comportent comme
des pointeurs. Je trouve qu'on a drôlement intérêt à bien comprendre
les pointeurs C avant d'utiliser un itérateur C++...

Ce sont plutôt les pointeurs qui se comportent comme des itérateurs -
une fois qu'on a compris ces derniers, on sait se servir correctement
des pointeurs et de leur arithmétique pour traverser un tableau :-P

Falk

On Thu, 28 Aug 2008 16:17:14 +0200, pjb@informatimago.com (Pascal J.
Bourguignon):

Donc la première chose à apprendre, c'est à ne pas faire de faute
d'orthographe ou de grammaire.

Je suis parfaitement d'accord avec toi. Mais le dire sur Usenet est
une pente savonneuse, puisque tu as écrit, le 29/8 à 14:26, ceci :

Bon, mais serrieusement, [...] implémenté une sacré bibliothèque [...]

On Sat, 30 Aug 2008 02:31:01 +0200, pjb@informatimago.com (Pascal J.
Bourguignon):

| Bon, mais serrieusement, concernant le C++, le problème c'est que
| c'est un langage qui n'est pas fini.

Effectivement, si par "fini" tu entends "achevé, qui n'évolue plus".
Une nouvelle norme est en préparation.

Il y a plein d'expressions en C++ qui sont
catastrophique pour le programme.

Je suis d'accord sur ce point. C'est le gros problème du C++ : il a
plein de fonctionnalités qu'il ne faut *pas* utiliser.

Afin de pouvoir écrire un programme
qui tourne, il faut définir des constructions de plus haut niveau,
comme par exemple std::vector<T> au lieu de T* ou T[].

Ou utiliser celles qui sont déjà définies. std::vector<> est décrit
dans la norme, donc fait partie du langage.
On ne peut pas reprocher à C++ de ne pas avoir une classe "tableau",
mais on peut lui reprocher d'accepter les constructions héritées du C,
comme T[].

Mais même
std::vector<T> est insuffisant. N'importe quel développement
nécessite l'écriture de bibliothèques pour gérer des choses
fondamentales (des choses qu'on trouve dans n'importe quel langage de
programmation véritablement de haut niveau). Voir boost,
stlab.adobe.com, etc.

Certes, on peut trouver dommage que Boost ne soit pas déjà
intégralement partie du langage.

Toutefois, ça ne change rien au problème : les constructions typiques
du C (gérer soit-même la mémoire à coups de malloc/realloc/free, ou
new[]/delete[]) sont très largement inutiles en C++.
Si je dois implémenter un tableau spécial, j'ai certes du boulot, qui
me serait peut-être évité en utilisant un autre langage, mais ça ne
change rien au fait que je laisserai probablement std::vector<> gérer
la mémoire pour moi.

Gabriel Dos Reis <gdr@cs.tamu.edu> writes:

pjb@informatimago.com (Pascal J. Bourguignon) writes:

[...]

| Le C est déjà un raccourci, le mieux serait de commencer par
| l'assembleur. ;-)

Le C est tout sauf un raccourci. Surtout, si le but est de progammmer
en C++.

| Bon, mais serrieusement, concernant le C++, le problème c'est que
| c'est un langage qui n'est pas fini.

Pardon ?

C'est clair pourtant. Il y a plein d'expressions en C++ qui sont
catastrophique pour le programme. Afin de pouvoir écrire un programme
qui tourne, il faut définir des constructions de plus haut niveau,
comme par exemple std::vector<T> au lieu de T* ou T[]. Mais même
std::vector<T> est insuffisant. N'importe quel développement
nécessite l'écriture de bibliothèques pour gérer des choses
fondamentales (des choses qu'on trouve dans n'importe quel langage de
programmation véritablement de haut niveau). Voir boost,
stlab.adobe.com, etc.

| Pour pouvoir l'utiliser en tant que C++ comme l'entendent ceux qui
| préconisent son apprentissage sans passer par C, il faut avoir
| implémenté une sacré bibliothèque de mécanismes de base (comme les
| soit-disant "Smart Pointer"), et d'objets, et il faut bien sur
| s'interdir d'utiliser tous les opérateurs du C problématiques.

C'est curieux, je n'ai jamais eu à faire ça.

Alors tu n'as jamais eu a programmer rien de conséquent en C++.

Les bibliothèques standard me suffisent largement pour les choses
d'ordre général -- et je soupçonne qu'elle suffisent largement pour
un débutant, comparé au C.

Pour des exercises d'école, oui, on peut se contenter de la stl.
Sinon pose toi la question de pourquoi on s'est embêté à faire boost,
ou adobe ses stlab, etc.

Pour une application dans un domaine spécifique, ben il faut de
toute façon implémenter les abstractions du domaine considére,
pertinentes pour l'application considérée.

Je ne parle pas des abstraction du domaine, mais des abstrations
techniques, comme des fonctions anonymes ou de la gestion de la
mémoire, ou encore des type abstraits de base comme des tables de
hashage.


--
__Pascal Bourguignon__ http://www.informatimago.com/

"Logiciels libres : nourris au code source sans farine animale."

pjb@informatimago.com (Pascal J. Bourguignon) writes:

| Gabriel Dos Reis <gdr@cs.tamu.edu> writes:
|
| > pjb@informatimago.com (Pascal J. Bourguignon) writes:
| >
| > [...]
| >
| > | Le C est déjà un raccourci, le mieux serait de commencer par
| > | l'assembleur. ;-)
| >
| > Le C est tout sauf un raccourci. Surtout, si le but est de progammmer
| > en C++.
| >
| > | Bon, mais serrieusement, concernant le C++, le problème c'est que
| > | c'est un langage qui n'est pas fini.
| >
| > Pardon ?
|
| C'est clair pourtant.

N'hésite surtout à pas expliquer.

| Il y a plein d'expressions en C++ qui sont catastrophique pour le
| programme.

Plus concrêtement ?

| Afin de pouvoir écrire un programme
| qui tourne, il faut définir des constructions de plus haut niveau,
| comme par exemple std::vector<T> au lieu de T* ou T[].

Non, c'est standard -- contrairement au C o`u il faut écrire soi mà ªme
son propre tableau dynamique.

| Mais même std::vector<T> est insuffisant.

N'hésite pas à être plus précis dans ton argumentation.

| N'importe quel développement
| nécessite l'écriture de bibliothèques pour gérer des choses
| fondamentales

Plus précisement ?

| (des choses qu'on trouve dans n'importe quel langage de
| programmation véritablement de haut niveau). Voir boost,
| stlab.adobe.com, etc.

Je connais tout ça, mais je n'y vois rien qui existe en standard en C.

| > | Pour pouvoir l'utiliser en tant que C++ comme l'entendent ceux qui
| > | préconisent son apprentissage sans passer par C, il faut avoir
| > | implémenté une sacré bibliothèque de mécanis mes de base (comme les
| > | soit-disant "Smart Pointer"), et d'objets, et il faut bien sur
| > | s'interdir d'utiliser tous les opérateurs du C problématiqu es.
| >
| > C'est curieux, je n'ai jamais eu à faire ça.
|
| Alors tu n'as jamais eu a programmer rien de conséquent en C++.

Je te l'accordre, c'est une conclusion théorique possible.
Encore faut-il la valider. Peux-tu m'expliquer ta validation ?

| > Les bibliothèques standard me suffisent largement pour les choses
| > d'ordre général -- et je soupçonne qu'elle suffisent lar gement pour
| > un débutant, comparé au C.
|
| Pour des exercises d'école, oui, on peut se contenter de la stl.

J'écris un « framework » pour l'analyse statique de programm e C++ en C++
et la STL m'a suffit très largement

http://parasol.tamu.edu/pivot
http://parasol.tamu.edu/pivot/presentations/the%20pivot%20overview.ppt
http://parasol.tamu.edu/pivot/presentations/stroustrup-b.pdf

| Sinon pose toi la question de pourquoi on s'est embêté à f aire boost,
| ou adobe ses stlab, etc.

J'aimwerais plutôt apprendre de ton expérience concrête -- e t non
juste une récitation d'arguments abstraits appris par coeur. Peux-tu
me montrer quelques un de tes prorammes/bibliothèques C++ où tu a s dû
devoir partir de zéro ? J'aimerais comprendre la base concrête de ton
argumentation.

| > Pour une application dans un domaine spécifique, ben il faut de
| > toute façon implémenter les abstractions du domaine considà ©re,
| > pertinentes pour l'application considérée.
|
| Je ne parle pas des abstraction du domaine, mais des abstrations
| techniques, comme des fonctions anonymes

Que tu as en C ?

Nous ne devons pas parler du même langage de programmation. Quelle
version utilises-tu ?

-- Gaby

Gabriel Dos Reis <gdr@cs.tamu.edu> writes:

| Il y a plein d'expressions en C++ qui sont catastrophique pour le
| programme.

Plus concrêtement ?

Par exemple:


void f(int a){
int* p=&a;
for(int i=(-16);i<16;i++){
p[i]=1;
}
}

int main(void){
try{
f(1);
}catch(...){
return(1);
}
return(0);
}

/*
-*- mode: compilation; default-directory: "/tmp/" -*-
Compilation started at Sat Aug 30 14:38:03

g++ -o a a.c++ -Werror && ./a ; echo status = $?
/bin/bash: line 1: 10416 Segmentation fault ./a
status = 139

Compilation finished at Sat Aug 30 14:38:03
*/

Ce programme compile sans erreur (même avec -Werror), et cependant
plante lamentablement. Je n'ai pas l'impression que la vérification
des types à la compilation aide en quoi que ce soit. Le compilateur
aurait surement mieux faire de moins vérifier ce que JE tape, et de
plus prendre soin de générer LUI-MÊME du code qui fonctionne.


Pour comparaison (et en tenant compte du fait que la notion C de
pointeur n'existe pas en lisp, et donc qu'on ne risque pas de
l'utiliser à mauvais escient comme en C++) :

S/CL-USER[22]> (cat "/tmp/a.lisp")
(defun f (a)
(loop for i from -16 below 16 do (setf (aref a i) 1)))

(defun main ()
(let ((a (make-array 3)))
(handler-case
(f a)
(error () (return-from main 1))))
0)

(print `(status = , (main)))



S/CL-USER[23]> (compile-file "/tmp/a.lisp")

; compiling file "/tmp/a.lisp" (written 30 AUG 2008 02:41:18 PM):
; compiling (DEFUN F ...)
; compiling (DEFUN MAIN ...)
; compiling (PRINT (SB-IMPL::BACKQ-LIST # ...))

; /tmp/a.fasl written
; compilation finished in 0:00:01
#P"/tmp/a.fasl"
NIL
NIL

S/CL-USER[24]> (load"/tmp/a.fasl")

(STATUS = 1)
T

S/CL-USER[25]>


Ici, même une erreur à l'exécution n'est pas catastrophique car le
programme peut l'attraper et la gérer.

| Sinon pose toi la question de pourquoi on s'est embêté à faire boost,
| ou adobe ses stlab, etc.

J'aimwerais plutôt apprendre de ton expérience concrête -- et non
juste une récitation d'arguments abstraits appris par coeur. Peux-tu
me montrer quelques un de tes prorammes/bibliothèques C++ où tu as dû
devoir partir de zéro ? J'aimerais comprendre la base concrête de ton
argumentation.

Malheureusement, le code C++ sur lequel je travaille ne m'appartient
pas. Quand je code librement, je le fais en Lisp, je ne suis pas
masochiste. C'est pour ça que je te réfère à adobe qui a ouvert les
sources des bibliothèques qu'ils ont du développer pour écrire leurs
applications en "C++".

| > Pour une application dans un domaine spécifique, ben il faut de
| > toute façon implémenter les abstractions du domaine considére,
| > pertinentes pour l'application considérée.
|
| Je ne parle pas des abstraction du domaine, mais des abstrations
| techniques, comme des fonctions anonymes

Que tu as en C ?

Nous ne devons pas parler du même langage de programmation. Quelle
version utilises-tu ?

http://clisp.cons.org
http://sbcl.sourceforge.net

--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we. -- Georges W. Bush

pjb@informatimago.com (Pascal J. Bourguignon) writes:

[...]

| > | > Pour une application dans un domaine spécifique, ben il faut de
| > | > toute façon implémenter les abstractions du domaine considére,
| > | > pertinentes pour l'application considérée.
| > |
| > | Je ne parle pas des abstraction du domaine, mais des abstrations
| > | techniques, comme des fonctions anonymes
| >
| > Que tu as en C ?
| >
| > Nous ne devons pas parler du même langage de programmation. Quelle
| > version utilises-tu ?
|
| http://clisp.cons.org
| http://sbcl.sourceforge.net

C'est une version de C effectivement assez bizarre. Mon compilateur
GCC ne le comprend pas.

-- Gaby

pjb@informatimago.com (Pascal J. Bourguignon) writes:

[...]

| > | Sinon pose toi la question de pourquoi on s'est embêté à faire boost,
| > | ou adobe ses stlab, etc.
| >
| > J'aimwerais plutôt apprendre de ton expérience concrête -- et non
| > juste une récitation d'arguments abstraits appris par coeur. Peux-tu
| > me montrer quelques un de tes prorammes/bibliothèques C++ où tu as dû
| > devoir partir de zéro ? J'aimerais comprendre la base concrête de ton
| > argumentation.
|
| Malheureusement, le code C++ sur lequel je travaille ne m'appartient
| pas.

Évidemment.

-- Gaby