Opérations sur les matrices...

Citation:

---

Envoyé par DavG

Citation:

---

Envoyé par Mac LAK

Mes modules compilent indifféremment en C ou en C++,

---

La seule contrainte est que tu dois mettre tous les cast pour les type void en cpp .. mais bon, si tu utilises un outil comme flexlint il te dit de les mettre de toute façon et après tu compiles indifféremment dans l'un ou l'autre !

---

Des casts quelle horreur. Pourquoi pas des gotos ?

Citation:

---

Envoyé par Emmanuel Delahaye

Citation:

---

Envoyé par DavG

Citation:

---

Envoyé par Mac LAK

Mes modules compilent indifféremment en C ou en C++,

---

La seule contrainte est que tu dois mettre tous les cast pour les type void en cpp .. mais bon, si tu utilises un outil comme flexlint il te dit de les mettre de toute façon et après tu compiles indifféremment dans l'un ou l'autre !

---

Des casts quelle horreur. Pourquoi pas des gotos ?

---

J'ai dit que pour compiler du C dans un .cpp il va te falloir mettre les cast sinon ça ne compilera pas .. j'ai pas dit que c'était bien :D
Dans une application sur laquelle j'ai travaillé on avait des librairies C et des liens software des fichiers .c en .cpp pour une autre librairie cpp, donc les cast sont devenus une obligation !!

Citation:

---

Envoyé par Emmanuel Delahaye

Des casts quelle horreur. Pourquoi pas des gotos ?

---

Pas plus horrible que d'ignorer ce que fait l'instruction "continue", mais bon...
Quant aux "goto", ils sont plus qu'intéressants pour implémenter une gestion d'erreurs complexe restant lisible, compacte, efficace et efficiente.

Les casts sont impératifs en C++ (erreur de compilation en général, et pas un "simple" warning, y'a même pas besoin d'un Lint), et autorisés en C => où est donc le problème ?

Citation:

---

Envoyé par DavG

Je pense que c'est exactement ce qu'il dit : c'est du C et pas du C++, mais en renommant le .c en .cpp tu peux le compiler sans problème .. comme bien souvent les environnements sont des compilateurs C++ qui ouvrent des .cpp sans te le demander, rien ne t'empêche de faire du C compilé en mode C++ !

---

Ben moi dans mes codes, y'a ça partout dans les .c:

Code:

---

1 2 3 4

#ifdef __cplusplus #error This source file is not C++ but rather C. Please use a C-compiler #endif

---

Or mon bon vieux Borland C++ 3.1 enregistre les fichiers en majuscule (MS-DOS) ce qui fait que quand j'ai commencé à compiler avec Dev-C++, j'avais des erreurs étranges avec certains codes de test. Quand j'ai passé mon code de bibliothèque, j'ai vu apparaîtres les fameux messages d'erreur

Code:

---

This source file is not C++ but rather C. Please use a C-compiler

---

Après un sérieux grattage de tête, je me suis aperçu que l'extension .C invoquait g++. J'ai tout renommé comme il faut et ça marche.

Quand j'ai passé la bibliothèque sous Linux, elle a compilé du premier coup.

D'autre part, utiliser un compilateur C++ pour compiler du C, c'est appliquer au fichier source (qui n'est que du texte) des regles de syntaxes et de sémantiques différentes qui peuvent mener à des comportements différents (par exemple, un caractère est de type int en C et de type char en C++)? J'ai donné ce lien plusieurs fois :

http://david.tribble.com/text/cdiffs.htm

C et C++ sont véritablement deux langages différents. Prétendre le contraire, et donc échanger les compilateurs, est tout simplement erroné.

Citation:

---

Envoyé par Mac LAK

Les casts sont impératifs en C++ (erreur de compilation en général, et pas un "simple" warning, y'a même pas besoin d'un Lint), et autorisés en C => où est donc le problème ?

---

L'école des ultra-ansi-puristes a banni les cast en même temps que les commandes POSIX :wink:

Citation:

---

Envoyé par Emmanuel Delahaye

Ben moi dans mes codes, y'a ça partout dans les .c:
Code:

Code:

---

1 2 3

#ifdef __cplusplus #error This source file is not C++ but rather C. Please use a C-compiler #endif

---

---

Ce qui est très limitatif ...

Citation:

---

C et C++ sont véritablement deux langages différents. Prétendre le contraire, et donc échanger les compilateurs, est tout simplement erroné.

---

VB et C sont deux langages différents, c'est vrai, mais C et C++ sont deux langages de la même famille (C++ étant, à mon avis, une énorme surcouche au C:D ) et, même si la réciproque n'est pas vrai, 90% des programmes C peuvent être compilés en C++ simplement en renommant le .c en .cpp en autant que tu as respecté certaines règles de compatibilité (comme les cast !!).

Citation:

---

Envoyé par DavG

J'ai dit que pour compiler du C dans un .cpp il va te falloir mettre les cast sinon ça ne compilera pas ..

---

C'est bien la preuve que ce sont des langages différents, avec syntaxe et une sémantique différentes.

Citation:

---

j'ai pas dit que c'était bien :D
Dans une application sur laquelle j'ai travaillé on avait des librairies C et des liens software des fichiers .c en .cpp pour une autre librairie cpp, donc les cast sont devenus une obligation !!

---

Je ne vois pas à quoi ça sert. Il est parfaitement possible dans un même projet de mélanger des sources C et des sources C++, il suffit de bien respecter les extensions et les compilateurs. Chaque source respecte sa sémantique et c'est tout; Les interfaces C visibles du C++ doivent simplement être encadrées par

Code:

---

1 2 3 4 5 6 7 8 9

#ifdef __cplusplus extern "C" { #endif   #ifdef __cplusplus } #endif

---

comme c'est fait systématiquement (enfin presque) dans ma bibliothèque.

http://emmanuel-delahaye.developpez.com/clib.htm

La seule contrainte du C est d'éviter les mots cles du C++ dans les interfaces, c'est pourquoi j'ai remplacé this par self, par exemple (dans les .h publics)
.

Citation:

---

Envoyé par Emmanuel Delahaye

Citation:

---

Dans une application sur laquelle j'ai travaillé on avait des librairies C et des liens software des fichiers .c en .cpp pour une autre librairie cpp, donc les cast sont devenus une obligation !!

---

Je ne vois pas à quoi ça sert. Il est parfaitement possible dans un même projet de mélanger des sources C et des sources C++, il suffit de bien respecter les extensions et les compilateurs.

---

En fait c'était une préparation à un portage total d'application C compilée avec Watcom à une application C++ compilée gnu, donc une étape intermédiaire, .. sinon en effet tu as parfaitement raison et les #ifdef __cplusplus suffisent amplement :wink:

Citation:

---

Envoyé par Mac LAK

Quant aux "goto", ils sont plus qu'intéressants pour implémenter une gestion d'erreurs complexe restant lisible, compacte, efficace et efficiente.

---

Ok. Mais vers le bas, on est bien d'accord ?

Citation:

---

Les casts sont impératifs en C++ (erreur de compilation en général, et pas un "simple" warning, y'a même pas besoin d'un Lint), et autorisés en C => où est donc le problème ?

---

Il peuvent cacher une erreur en rendant le compilateur silencieux. Ils sont donc une source de problèmes. Moins je vois de cast, mieux je me porte. (En C++, pas de cast avec new)

Citation:

---

Envoyé par DavG

Citation:

---

Envoyé par Emmanuel Delahaye

Code:

---

1 2 3

#ifdef __cplusplus #error This source file is not C++ but rather C. Please use a C-compiler #endif

---

---

Ce qui est très limitatif ...

---

Meuh ? Pourquoi ? C'est sûr, c'est tout. Ca évite de faire n'importe quoi. C'est mal ?

Citation:

---

Citation:

---

C et C++ sont véritablement deux langages différents. Prétendre le contraire, et donc échanger les compilateurs, est tout simplement erroné.

---

mais C et C++ sont deux langages de la même famille <...>

---

La seule chose qui soit 100% compatible est le préprocesseur. Ils ont strictement la même définition en C et en C++. Le reste, c'est du domaine de la ressemblance et des faux amis. Je ne prend pas ce genre de risques.

Ce que je n'arrive pas à comprendre, c'est qu'en plus du fait que le comportement devient indéterminé (les regles sont différentes), à quoi ça sert de compiler du code C avec un compilateur C++. Quelle est la raison profonde de cette association contre nature ?

Citation:

---

Envoyé par Emmanuel Delahaye

Citation:

---

Envoyé par Mac LAK

Quant aux "goto", ils sont plus qu'intéressants pour implémenter une gestion d'erreurs complexe restant lisible, compacte, efficace et efficiente.

---

Ok. Mais vers le bas, on est bien d'accord ?

---

Ben je parle explicitement d'une gestion d'erreurs : grosso-modo, l'équivalent d'une section "try/finally" ou "try/catch", donc obligatoirement descendant.
Pour une fois, on est 100% d'accord : un goto ascendant en C, ça mérite le bûcher. J'accepte même de mélanger la poix avec du miel et de te laisser jouer avec tes fourmis avant de jeter la torche... :twisted:

Citation:

---

Envoyé par Emmanuel Delahaye

Il peuvent cacher une erreur en rendant le compilateur silencieux. Ils sont donc une source de problèmes. Moins je vois de cast, mieux je me porte. (En C++, pas de cast avec new)

---

Je n'utilises pas "new" en général, sauf pour les classes (mais dans ce cas, pas de portabilité C/C++, bien évidemment), à cause de l'API "légèrement" gourmande de BC++ sur cette instruction et que j'estime rédhibitoire en embarqué.
Quant au "silence" du compilateur, on en a déjà discuté une fois, tu connais mon point de vue et moi le tien : tu sais également que les deux sont aussi valides l'un que l'autre, "tes" cas d'erreurs étant couverts par "ma" méthode et réciproquement. Aucune des deux n'est franchement plus fiable que l'autre.

Par contre, sur le sujet des "#ifdef _cplusplus" et des "extern "C" {", là, je bloque : ça rend le source imbuvable, et ça pose parfois des problèmes d'édition de liens assez infernaux à gérer (situation vécue, hélas...).

A quoi ça sert de compiler du C en C++ et réciproquement ? Ben à avoir le même source sur une cible possédant un compilo C++ (=> donc, on peut utiliser des trucs comme les classes ou les exceptions si nécessaire), et sur une cible ne possédant qu'un compilateur C... Très utile pour les protocoles de communication, par exemple.

On peut rapprocher ça, parcequ'en fait c'est exactement le même problème, d'une unité Pascal DOS compilée sous Delphi et réciproquement... Mais là, j'entends personne râler, alors que les deux langages sont au moins aussi différents que C et C++ !!

C'est bon pour le calcul d'une transposée de matrice carrée. Mais ca ne marche pas encore pour une matrice autre.
J'ai inversé le nomre de ligne et le nombre de colonne, et normalement avec l'algo ca marche...mais pas sur le programme. :/

Voici le code, si quel'qu'un a une idée :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

//calcul de la matrice transposée   int **transpose(int nblign, int nbcol) {   int i, j,nb,tmp=0; int **tab; int **trans;   tmp=nblign; nblign=nbcol; nbcol=tmp;   trans=(int**)malloc(nblign*sizeof(int*)); for (i=0;i<nblign;i++) { *(trans+i)=(int*)malloc(nbcol*sizeof(int)); for (j=0;j<nbcol;j++) { *(*(trans+i)+j)=*(*(tab+j)+i); } }

---

Merci! ^^

si j'ai bien compris, dans ta fonction tab c'est la matrice d'origine et trans c'est la matrice transposee.
mais alors pourquoi tu declare tab dans cette fonction ?
quand tu utilise tab pour recopier ses valeurs dans trans, ce n'est meme pas alloué !

je pense que la signature de ta fonction devrai etre plutot :

int **transpose(int nbligne, int nbcolonne, int **tab)

en ayant pris soin d'allouer et de remplir tab avant d'appeller transpose

aokiseiichiro < Tester le retour de malloc, ca peut servir...