de la TI au PC moi aussi - Page 2

ben par exemple dans n'importe quelle zone de texte,... tu as (sous nux en tt cas):
méthodes de saisie
insérer un caractère unicode...
correction orthographique

A mon tour de m'amuser dans ce debat sans fin:

c++: temps de compilation long, tres long (voir apocalyptique. Ex: compiler gcc ou giacs. Lequels est le plus rapide a se compiler ?).
c++: langage hybride permettant le haut-niveau et le bas-niveau. Code pervers aisement facile. On peut toujours manipuler la memoire et des objects en meme temps. Ils auraient mieux fait d'autoriser le linkage avec le code C bas-niveau et ne mettre rien de bas niveau dans la syntaxe C++.
c++: Pas de DLL ! (Sauf si on aime les bugs).
c++: Moins supporte par les compilateurs que le C K&R. (Vous vous en foutez ? Pas moi.).
c++: Les listes chainees: trivial sauf si tu es une grosse bouse. Et dans ce cas, c'est pas la peine de faire ton application. En plus, c'est souvent mal-utilise. Et le vrai probleme pointee est le caractere inline/template de la STL. Mais on peut facilement faire des templates (certes moins pousse mais suffisante pour la plupart des utilisation) en C.
c++: Programme plus gros du au tres fort taux d'inlining des fonctions / methodes (Forcement autrement, ca ramerait a en mourir) et l'utilisage des templates.
c/qsort: Les callbacks sont assez penalisantes sur le pentium 4.
c: La gestion de la memoire en C. Catastrophique pour les debutants.
c++: Plus lent meme pour appeller une fonction C (J'ai fait un programme de bench. L'un compiler en mode C++, l'autre en mode C - le MEME programme! - ou le bench consiste a appeller une fonction C d'une librarie. Le programme C++ donne des resultats plus lent que le C). Sans parler de la syntaxe "x=a+b" plus lente que set(x,a,b); (sauf si on definit tres bien sa classe...).
c++: Mauvaise utilisation par les programmeurs qui tendent a faire exploser la gestion de la heap par une vague incessente de constructions/destructions.
c++: Les chutes de performantes incomprehensibles parce que tu as oublie un const et/ou & et autre chose infame.
c: Manipulation execessive des pointeurs, ou typage insuffisant des pointeurs (bannir le void*).

Bref, le C++ c'est peut etre bien, mais j'ai encore rencontre personne le maitrissant

sBibi: C'est quoi que tu peux faire en C++ 100x plus simple qu'en C ?
Et tu aurais du faire une liste chainee de tableau fixe.

temps de compilation long, tres long (voir apocalyptique. Ex: compiler gcc ou giacs. Lequels est le plus rapide a se compiler ?).

Oui c'est vrai, et g++ 3 est particulierement lent. Visual C++ est nettement plus rapide (headers précompilés + link incrémental), mais il a d'autres défauts.

langage hybride permettant le haut-niveau et le bas-niveau. Code pervers aisement facile. On peut toujours manipuler la memoire et des objects en meme temps. Ils auraient mieux fait d'autoriser le linkage avec le code C bas-niveau et ne mettre rien de bas niveau dans la syntaxe C++.

Le but étant d'etre compatible avec du C, ça n'aurait pas pu etre autrement. Mais on est d'accord sur l'utilité d'un langage de haut niveau propre (et plus rapide que Java).

Pas de DLL ! (Sauf si on aime les bugs).

Sous Linux, KDE+Qt c'est plein de lib dynamiques de partout, avec du vrai C++, et ça marche très bien.
BeOS également utilisait une API 100% C++, et les libs dynamiques marchaient aussi.
En plus de nos jours il y a une ABI standard alors ça ne peut qu'aller mieux.

Moins supporte par les compilateurs que le C K&R. (Vous vous en foutez ? Pas moi.).

Je pense que n'importe quel langage est moins supporté que le C K&R.

Mais on peut facilement faire des templates (certes moins pousse mais suffisante pour la plupart des utilisation) en C.

Avec des macros ? Pas de typage bonjour les bugs.

Plus lent meme pour appeller une fonction C (J'ai fait un programme de bench. L'un compiler en mode C++, l'autre en mode C - le MEME programme! - ou le bench consiste a appeller une fonction C d'une librarie. Le programme C++ donne des resultats plus lent que le C). Sans parler de la syntaxe "x=a+b" plus lente que set(x,a,b); (sauf si on definit tres bien sa classe...).

Pas normal... tu as regardé la différence dans le code généré ?

Mauvaise utilisation par les programmeurs qui tendent a faire exploser la gestion de la heap par une vague incessente de constructions/destructions.

Les bons programmeurs de C++ sont rares.

Bref, le C++ c'est peut etre bien, mais j'ai encore rencontre personne le maitrissant

J'en cotoie quotidiennement c'est l'une des spécialités du labo de recherches dans lequel je travaille (mais certainement pas ma spécialité).

C'est quoi que tu peux faire en C++ 100x plus simple qu'en C ?

Faire une interface graphique avec des widgets c'est moulte fois plus simple en C++ (j'ai tenté les deux).
Et puis ya qu'à voir le code de Gtk comparé à Qt... aucun rapport

nitro :
Oui c'est vrai, et g++ 3 est particulierement lent. Visual C++ est nettement plus rapide (headers précompilés + link incrémental), mais il a d'autres défauts.

Entre autre des fichiers dechets qui prennent plein de place.

Mais on est d'accord sur l'utilité d'un langage de haut niveau propre (et plus rapide que Java).

Vive OCAML !

Sous Linux, KDE+Qt c'est plein de lib dynamiques de partout, avec du vrai C++, et ça marche très bien.
BeOS également utilisait une API 100% C++, et les libs dynamiques marchaient aussi.
En plus de nos jours il y a une ABI standard alors ça ne peut qu'aller mieux.

C'est pour ca qu'il y a le numero de version dans le linkage dynamique (entre autre).
Et question idiote:
Une DLL me cree et me retourne un object. Est-ce correct de faire un delete myobject ? Ou c'est a la DLL de le faire ?

Avec des macros ? Pas de typage bonjour les bugs.

Mais non. Plus simplement:
#define type int
#define function max_int
#include "max.c"
avec dans max.c:
type function(type a, type b)
{
return (a<b ? b : a);
}
#undef type
#undef function

Et tu peux meme faire un systeme pour automatiser la creation d'une mega-macro max qui detecte le type (Perso j'aime bien comme c'est).

Pas normal... tu as regardé la différence dans le code généré ?

Pour a = b+c ou pour le meme appel en fonction du mode de compilation ?

Les bons programmeurs de C++ sont rares.

J'en cotoie quotidiennement c'est l'une des spécialités du labo de recherches dans lequel je travaille (mais certainement pas ma spécialité).

Je dis bien maitriser, pas connaitre parfaitement.

Faire une interface graphique avec des widgets c'est moulte fois plus simple en C++ (j'ai tenté les deux).
Et puis ya qu'à voir le code de Gtk comparé à Qt... aucun rapport

Je trouve toutes les interfaces graphiques trop compliques.

sBibi: C'est quoi que tu peux faire en C++ 100x plus simple qu'en C ?

bon, je repete: j'ai jamais rien code en C++, la seule vague connaissance que j'en ai c'est tous les codes sources que j'ai pu lire (et c'est a 99% du C++). mais rien qu'en sachant qu'on peut overloader des operateurs et des fonctions (je sais pas si le terme overloader s'applique aux fonctions, ce que je veux dire, c'est plusieurs fonctions qui ont le meme nom mais des parametres differents, et en fonction de l'appel, le compilateur appelle telle ou telle fonction, je sais pas comment ca s'appelle), qu'on peut faire des classes qui ont des variables privees, des constructeurs et destructeurs, si j'avais ca en C, ca simplifierait enormement le code, point de vue lisibilite mais aussi point de vue temps passe a l'ecrire. et la lisibilite, quand tu bosse dans une equipe de 8 devs sur un gros proj qui s'etale sur un an et que tu sera ammenne a continuer et faire evoluer pendant encore plusieurs annees, dsl mais je trouve pas que c'est negligeable...

Et tu aurais du faire une liste chainee de tableau fixe.

certainement pas, non seulement ca complique inutilement le code, en plus ca le ralentirait a l'execution (je dois acceder aux elements de ce tableau tres souvent), alors que la tout ce que j'ai a faire pour recuperer un element (ils sont identifies par des index), c'est d'indexer directement le tableau, sans me poser de questions. (et les index sont forcement valides, ils sont checkes au loading...)

Kevin> tain mais comment ils ont pu pondre un realloc pareil?
enfin bon ma remarque de mon precedent post pour laquelle tu n'a pas reagi tient toujours...

>>Et tu aurais du faire une liste chainee de tableau fixe.
Seulement dans la premiere passe de lecture de fichiers. Puis apres tu remplis ton tableau par une seule copie (En plus tu auras une bonne coherence du cache).

overfloader les operateurs est une chose que je supporte pas du point de vue de la lisibilite (Sauf pour les classes isomorphable a des nombres).

>plusieurs fonctions qui ont le meme nom mais des parametres differents, et en fonction de l'appel, le compilateur appelle telle ou telle fonction
Tu peux faire des macros sous GCC, mais le code de la macro est intorchable.

Ton argument est pas terrible. Faut faire de la documentation.

"Seulement dans la premiere passe de lecture de fichiers. Puis apres tu remplis ton tableau par une seule copie (En plus tu auras une bonne coherence du cache)."

c'est pour ca que je reallouais par blocs de 128, avant de finalement faire deux passes

"overfloader les operateurs est une chose que je supporte pas du point de vue de la lisibilite (Sauf pour les classes isomorphable a des nombres)."

forcement ca depend ou, c'est pas le genre de truc a aller caser partout ou y a une possibilite de le mettre... c'est comme tout. utiliser les listes chainees partout c'est con.. utiliser des tableaux partout c'est con aussi, dans certains cas certains trucs sont mieux adaptes que d'autres, la c pareil...

"Tu peux faire des macros sous GCC, mais le code de la macro est intorchable."

c'est justement un des problemes que j'ai, beaucoup trop de macros "intorchables"

"Ton argument est pas terrible. Faut faire de la documentation."

bah il l'est suffisemment pour me faire regretter de pas avoir ces features du C++ en C, et si je connaissais mieux le C++ je trouverai certainement d'autres features que je ne connais pas en ce moment bien utiles...

aussi, j'essaye de modulariser mon code au maximum, et tout est decoupe en modules, chaque module ayant son repertoire, et chaque repertoire de modules etant regroupe dans d'autres repertoires correspondant aux differentes couches d'abstractions. chacun de ces modules a une interface bien definie, dans un .h "public", qui a, comme toute interface, pour but d'abstraire le fonctionnement interne du module, et un ou des .h "prives", dans un repertoire include au sein du module, qui lui contient tout ce qui est specifique a l'implementation et au fonctionnement interne du module. or en C, hormis mettre des variables ou des fonctions qui sont censees etre "privees" en static (ce qui implique d'avoir tout le code qui doit s'en servir dans le meme fichier), je connais pas d'autre solution. et le probleme est que tous ces .c sont linkes ensembles, et que pour une raison X (peut etre du au fait que c'est une DLL), si dans deux modules differents j'utilise le meme symbole pour deux variables ou fonctions differentes, ca linke quand meme, mais un seul des deux symboles est linkes, sans aucun avertissement (ca fais ca aussi bien sous GCC (3.3.3 y me semble, enfin la derniere) que sous VC++ (6)), du coup vu qu'on est plusieurs (8) a bosser sur le proj (enfin pour l'instant on est que deux a vraiment bosser dessus, mais les autres s'y mettront apres), il est pas improbable du tout (et c'est deja arrive) que qqun ecrive un module et utilise le meme nom pour une var ou une petite fonction interne au module que qqun d'autre dans un autre module (oui dsl c'est pas super limpide comme explication), du coup ca introduit pleins de bugs de merde. chose qu'on a resolu en se fixant une norme tres stricte pour les noms, mais qui produit des noms hyper longs, et c'est plus que chiant... bref.
si j'ai bien compris, en C++, tu fais que chaque module est une classe, tu peux specifier des vars privees et publiques, et aucun pbl... et pas besoin de se prendre la tete la dessus...

Tu peux faire ceci dans ton include prive:

#define func1 mafunc1privateaunomintorchable

Ca marche tres bien

lol, oue non mais voila... j'ai jamais dit que ce qui etait faisable en C++ etait pas faisable en C (je le fais), juste que c'est plus simple et plus rapide point de vue temps de dev de le faire en C++...
la t oblige d'utiliser des tas de defines, dont tu pourrais te passer...

et puis aussi pour rendre des macros intorchables moins intorchables, les simplifier avec plein de sous macros, etc...
et au final qd t'as bcp de .h de ce style tu te demande pkoi les .c mettent 3 ans a compiler

et c'est ca que j'appelle "emuler des features C++"... emuler, en moins bien...
le temps passe a emuler, pourrait etre passe a faire d'autres trucs plus interessants et utiles si c'etait code en C++ directement...

moi je préfère coder en C (même des interfaces graphiques)
parce que les codes C++ que je lis ou sur lesquels j'interviens sont souvent trop sales donc je me dis que je doi moi aussi (y'a pas de raison) être une bouse en C++

longue vie au troll

Entre autre des fichiers dechets qui prennent plein de place.

Ce genre de choses arrive dans g++ également.

Une DLL me cree et me retourne un object. Est-ce correct de faire un delete myobject ? Ou c'est a la DLL de le faire ?

C'est là toute la question de l'appartenance des objets. Il y a le meme genre de problematique dans Swig (un générateur de bindings pour les langages de scripts). En effet les langages comme Perl et Python gèrent eux-même les objets, avec leur propre garbage collector, et lors de l'interfaçage avec du C++, il faut expliciter l'apartenance des objets créés. Il n'y a pas de réponse unanime à ta question.

Et tu peux meme faire un systeme pour automatiser la creation d'une mega-macro max qui detecte le type (Perso j'aime bien comme c'est).

C'est vrai que c'est pas mal, je n'y avais pas pensé

Pour a = b+c ou pour le meme appel en fonction du mode de compilation ?

C'est pour l'appel de fonction que ça me choque le plus.

Je dis bien maitriser, pas connaitre parfaitement.

Oh ben ils se débrouillent plutot bien... un exemple de publication pour une conf en Californie : http://www.lrde.epita.fr/cgi-bin/twiki/view/Publications/200310-MPOOL

Je trouve toutes les interfaces graphiques trop compliques.

C'est à dire ?

nitro
: Le but étant d'etre compatible avec du C, ça n'aurait pas pu etre autrement. Mais on est d'accord sur l'utilité d'un langage de haut niveau propre (et plus rapide que Java).

Comme ça: http://gcc.gnu.org/java/?

Pas de DLL ! (Sauf si on aime les bugs).

Sous Linux, KDE+Qt c'est plein de lib dynamiques de partout, avec du vrai C++, et ça marche très bien.

1. Ce n'est pas du "vrai C++", c'est du -fno-exceptions.
2. Ça marche très mal. Il faut compiler avec la même version de GCC que la DLL, sinon tout foire. Et il y a plein d'autres problèmes (entre autres avec les exceptions, ce qui ne concerne pas Qt parce qu'elle ne les utilise pas).

En plus de nos jours il y a une ABI standard alors ça ne peut qu'aller mieux.

Non. L'ABI est tellement complexe que les développeurs de g++ n'arrêtent pas de corriger des bogues de non-conformance, et du coup la compatibilité binaire est toujours perdue à chaque version (ça sera très probablement le cas à nouveau avec GCC 3.4, par exemple).

PpHd
: Je trouve toutes les interfaces graphiques trop compliques.

Fais-en une plus simple.
Si tu arrives à en faire une qui me plaît, peut-être que l'IDE de TIGCC pour Linux l'utilisera. (Pour l'instant, j'ai le choix entre des toolkits tous en C++ et un toolkit en C dont j'ai horreur (GTK). Je penche vers Qt à cause de son RAD (Qt Designer).)

sBibi
: overloader des operateurs et des fonctions (je sais pas si le terme overloader s'applique aux fonctions, ce que je veux dire, c'est plusieurs fonctions qui ont le meme nom mais des parametres differents, et en fonction de l'appel, le compilateur appelle telle ou telle fonction, je sais pas comment ca s'appelle)

C'est bien "overloader" (ou "surcharger" en français).

si j'avais ca en C, ca simplifierait enormement le code

Le surchargement de fonctions simplifie le code??? Le seul effet que ça a est qu'on ne sait plus quelle fonction est appelée. Si tu donne des noms différents, on voit tout de suite quelle est la fonction appelée. Quant au surchargement d'opérateurs, je suis d'accord avec PpHd que c'est presque toujours abusif et illisible.

Kevin> tain mais comment ils ont pu pondre un realloc pareil? enfin bon ma remarque de mon precedent post pour laquelle tu n'a pas reagi tient toujours...

Tu veux dire celle-là: "non... si tu realloue de 1000 octets a la fois et que ta valeur strictement positive c'est 32, ta notion de "suffisemment de place" est completement inutile."?
Bon, alors on prend 10% ou 50%. Une heuristique qui devrait aussi marcher bien avec beaucoup de sources est de prendre un multiple de la dernière augmentation. Si tu augmentes de 1, on augmente automatiquement de 128, comme ça tu n'as pas à gérer ça dans ton code.
Bref, c'est vraiment le problème de la fonction realloc et pas le tien. Et puis je pense que même sans ce genre d'heuristique, avec une libc un minimum intelligente, il n'y a pas le genre de problème de performances que tu as eu. As-tu essayé ton code sous Linux/glibc?

sBibi
: aussi, j'essaye de modulariser mon code au maximum, et tout est decoupe en modules, chaque module ayant son repertoire

Et voilà ton erreur. La logique du C veut que 1 module == 1 fichier .c, pas un répertoire.

or en C, hormis mettre des variables ou des fonctions qui sont censees etre "privees" en static (ce qui implique d'avoir tout le code qui doit s'en servir dans le meme fichier)

... ce que tu es censé faire.

un toolkit en C dont j'ai horreur (GTK)

dont tu as horreur à cause de l'aspect ou à cause de l'utilisation de la lib ?
Avec lablgtk c'est le confort d'utilisation ultime

Kevin Kofler :
Comme ça: http://gcc.gnu.org/java/?

Non pas comme ça. Le Java n'a pas été conçu pour être rapide, et il n'a pas été conçu pour être optimisé statiquement. Donc on ne peut pas être rapide en Java.

1. Ce n'est pas du "vrai C++", c'est du -fno-exceptions.

Il n'y a rien dans le standard du C++ qui interdit les exceptions dans les libs dynamiques. D'ailleurs ça marchait la dernière fois que j'ai testé. De plus il y a des implémentations d'exceptions qui n'induisent pas de pénalités exagerées (compaq c++ par exemple).

2. Ça marche très mal. Il faut compiler avec la même version de GCC que la DLL, sinon tout foire. Et il y a plein d'autres problèmes (entre autres avec les exceptions, ce qui ne concerne pas Qt parce qu'elle ne les utilise pas).

Chez moi j'ai des apps KDE compilées avec g++ 3.3.3 alors que les libs KDE et Qt sont compilées avec g++ 3.3.2 et je n'ai pas le mondre problème. Si il y a des problèmes c'est à cause de bugs dans le compilateur, ça ne vient pas du standard.

Non. L'ABI est tellement complexe que les développeurs de g++ n'arrêtent pas de corriger des bogues de non-conformance, et du coup la compatibilité binaire est toujours perdue à chaque version (ça sera très probablement le cas à nouveau avec GCC 3.4, par exemple).

Là encore c'est la faute des développeurs de g++, et c'est normal que ça prenne du temps à se stabiliser... la compatibilité pour le C ne s'est pas faite en 1 jour non plus !

As-tu essayé ton code sous Linux/glibc?

En codant comme tu dis, le programme ne fonctionne de manière acceptable que sous Linux/glibc... c'est pas terrible pour du C qui est sensé être universellement portable.

"Et voilà ton erreur. La logique du C veut que 1 module == 1 fichier .c, pas un répertoire."

haha excellent tu te repond toi meme, c'est pas une erreur tres cher, c'est un choix. et cette "logique" du C fait entre autre (d'un point de vue strictement structurel) que le C est pas le langage le plus adapte pour les gros projets modulaires. desole j'aime pas trop avoir a parcourir des fichiers monstrueux avec une quantite enorme de fonctions dedans

"... ce que tu es censé faire."

cense? pourquoi cense? autant que je sache j'organise mon source tree comme je veux non? c'est pas un standard qui limite la lisibilite et la maintenance du code qui va m'obliger a rendre ce meme code encore plus illisible et plus difficilement maintenable...
et justement, si c'etait en C++ et pas en C, j'aurais deja ce probleme la en moins (soit dit en passant, c'est un probleme purement technique: static/pas static, qu'il n'y aurait pas avec une classe en C++, donc ne me sort pas qu'en C++ aussi, la philosophie veut que toutes les fonctions d'une classe soient dans le meme fichier)
et au moins la remarque de PpHd etait un peu plus intelligente que la tienne, qui comme d'habitude est completement bornee... "t'es cense faire ca, si tu fais differemment t'as tord..."

"Le surchargement de fonctions simplifie le code???"

eh oui

"Le seul effet que ça a est qu'on ne sait plus quelle fonction est appelée."

justement, c'est la tout l'interet, au cas ou tu l'aurais pas compris
c'est de ne plus avoir a se preocupper de quelle fonction est appellee...

"Si tu donne des noms différents, on voit tout de suite quelle est la fonction appelée."

oui, et tu dois te faire chier, quand t'as 20 fonctions de multiplication matricielle par exemple, a choisir la bonne en fonction des arguments, etc, etc...
si t'overloade une fonction par exemple mat_mult, t'as pas besoin de te soucier de quoi que ce soit, tu lui passe des matrices 3*3, 4*3, 3*4, 4*4, 4*5, n'importe quoi, et du moment que la bonne version est overloadee, ca passe tout seul. mais je vois pas pourquoi tu semble ignorer ou ne pas comprendre ca alors que ca a l'air d'etre une des bases

"Quant au surchargement d'opérateurs, je suis d'accord avec PpHd que c'est presque toujours abusif et illisible."

c'est peut etre illisible parceque c'est abusif, cf ce que j'ai dit au dessus.. l'utiliser a tout va est aussi mauvais que d'utiliser des listes chainees a tout va...
et desole mais je trouve ca:

c_vector_4 truc;
c_vector_4 machin;
...
truc += machin;

beaucoup plus lisible, simple et rapide a ecrire que ca:

t_vector_4 truc;
t_vector_4 machin;
...
truc.x += machin.x;
truc.y += machin.y;
truc.z += machin.z;
truc.t += machin.t;

et encore, un vecteur a 4 dimensions c'est un exemple simple compare a d'autres trucs...

"Bon, alors on prend 10% ou 50%. Une heuristique qui devrait aussi marcher bien avec beaucoup de sources est de prendre un multiple de la dernière augmentation. Si tu augmentes de 1, on augmente automatiquement de 128, comme ça tu n'as pas à gérer ça dans ton code."

la d'accord...

"Bref, c'est vraiment le problème de la fonction realloc et pas le tien."

malheureusement non, c'est aussi le mien, comme a dit nitro, si tu veux un code un minimum portable, c'est pas super de se baser sur telle ou telle implementation. surtout que la globc est visiblement la seule suffisemment "intelligente" a tes yeux...

Sally
:

un toolkit en C dont j'ai horreur (GTK)

dont tu as horreur à cause de l'aspect ou à cause de l'utilisation de la lib ?

C'est surtout l'aspect graphique qui est horrible. Mais bon, avec Bluecurve, ça ne se remarque presque plus. Heureusement qu'il y a RedHat... (J'ai tout mis en Bluecurve maintenant.)
Cela dit:
* la programmation orientée objet en C à la GTK, c'est bizarre.
* GTK ne rejoint pas le comfort de QT Designer. Il y a ça: http://vdkbuilder.sourceforge.net/, mais c'est pour un wrapper C++ de GTK, donc autant utiliser un toolkit C++ directement.

Avec lablgtk c'est le confort d'utilisation ultime

"LablGTK is is an Objective Caml interface to gtk+." Non merci. Je préfère encore le C++ que je connais un peu... Et puis je veux un RAD.

C'est surtout l'aspect graphique qui est horrible. Mais bon, avec Bluecurve, ça ne se remarque presque plus. Heureusement qu'il y a RedHat... (J'ai tout mis en Bluecurve maintenant.)

j'ai pas l'habitude de faire ce genre de répnses mais: " "
s'il y a bien un toolkit vraiment themable c'est gtk et surement pas Qt
--- c'est moi ou la plupart des sujet sont en fait pléthores de commentaires de chacun pour faire entendre raison à kk?

moi j'overloade souvent operator>> et operator<< genre mais les autres n'ont de réelle signification que pour les types ~numériques(en général)comme un vecteur pour citer sBibi
c'est pratique aussi dans le même esprit que la surdefinition de fonctions genre: matrice1x3*matrice3x2

arf bonne nuit

>sBibi: lol, oue non mais voila... j'ai jamais dit que ce qui etait faisable en C++ etait pas faisable en C (je le fais),
>la t oblige d'utiliser des tas de defines, dont tu pourrais te passer...
>et c'est ca que j'appelle "emuler des features C++"... emuler, en moins bien...
>le temps passe a emuler, pourrait etre passe a faire d'autres trucs plus interessants et utiles si c'etait code en C++ directement...
En quoi c'est long et difficile ? Qu'est-ce que tu pourrais faire en 5 minutes ? (Temps que je juge necessaire pour definir ceci:
#define ma_function1 mon_module_ma_function1
Et perso j'ai eu pas mal de problemes avec les namespace en C++ qui m'ont pris bien plus que 5 minutes (Entre autre corriger ces fucking de libs c++).

>et au final qd t'as bcp de .h de ce style tu te demande pkoi les .c mettent 3 ans a compiler
Ca restera toujours 10x plus rapide qu'en C++.
Bref tu perds du temps a l'ecriture du code, mais tu en gagnes pas mal en temps de compilation.
Et perso je sais quel temps j'ai choisi.

>Nitro: Il n'y a pas de réponse unanime à ta question.
C'est bien pkoi les DLL en C++, non merci.

>C'est pour l'appel de fonction que ça me choque le plus.
Oups je crois avoir compris pkoi c'etait plus lent. Je vais aller voir.

>C'est à dire ?
On devrait juste dire a l'interface ce qu'on veut obtenir comme information, et que l'interface en fonction de la politique du systeme genere automatiquement tous les trucs de gestion des fenetres. En plus, on aura pas besoin de mettre a jour l'appli en fonction du systeme.

>Kevin: Et voilà ton erreur. La logique du C veut que 1 module == 1 fichier .c, pas un répertoire.
Pas forcement.
On peut aussi generer une lib statique par module et un fichier par fonction. C'est aussi courant en C.

>Nitro: la compatibilité pour le C ne s'est pas faite en 1 jour non plus !
M'enfin le C++ ne part pas de rien comme ce fut le cas pour le C...

>le programme ne fonctionne de manière acceptable que sous Linux/glibc...
Heu. Non, sous PedroM aussi

>sBibi: le C est pas le langage le plus adapte pour les gros projets modulaires.
Tu peux faire pour chaque module une lib statique avec dedans tous les fichiers de la libs.
Puis le projet linke toutes les libs statiques. Tu peux meme en faire des libs dynamiques.

>j'aurais deja ce probleme la en moins
Un pb ? Mais c'est trivial a corriger. Tu devrais faire un peu de C++ pour te rendre compte des pbs du C++ .

>c'est de ne plus avoir a se preocupper de quelle fonction est appellee...
> quand t'as 20 fonctions de multiplication matricielle par exemple, a choisir la bonne en fonction des arguments, etc, etc...
Ben tvector_matmul_2x2_3x2(a,b,c)
C'est vrai que ca demande un peu plus d'effort.

Perso j'aurais ecrit en C:
t_vector_4 truc, machin;
...
t_vector_4_inc(truc, machin);

La logique du C est d'encapsuler le code dans des fonctions (que tu peux definir inline). M'enfin ce que j'ai dit reste vrai.

>si tu veux un code un minimum portable, c'est pas super de se baser sur telle ou telle implementation.
Nan, il ne sagissait pas de portabilite mais de performances sur differents systemes.

PpHd:

En quoi c'est long et difficile ? Qu'est-ce que tu pourrais faire en 5 minutes ? (Temps que je juge necessaire pour definir ceci: #define ma_function1 mon_module_ma_function1

euh oue non mais arrette... ca prend pas 5 min ca, ca prend 20 secondes a taper (le temps de reflechir au nom), c'est pas ca que je voulais dire... et j'ai pas dit que ct long et difficile, juste que c'etait inutile et que quand t'en a des tas a faire, ce temps pourrait etre passe a faire d'autres trucs (en plus d'alourdir les .h)

Et perso j'ai eu pas mal de problemes avec les namespace en C++ qui m'ont pris bien plus que 5 minutes (Entre autre corriger ces fucking de libs c++).

peut etre, sans doute, ca j'en sais rien, je le repete: j'ai jamais rien fait en C++, je dis juste que vu ce que j'en vois, ce que j'en entends (hormis certains ), l'utilisation qui en est faite dans l'industrie, et des tas d'autres trucs, le C++ me parait bcp plus adapte a certains trucs que le C (beaucoup meme...)

Bref tu perds du temps a l'ecriture du code, mais tu en gagnes pas mal en temps de compilation. Et perso je sais quel temps j'ai choisi.

et tu l'a peut etre mal choisi... du moins si je faisais ce meme choix (et je l'ai fait, pas le choix, j'av pas le temps d'apprendre le C++ ), ca aurait ete le mauvais...
vouloir gagner en temps d'execution en choisissant le langage, dans des trucs haut niveau comme (par exemple) un scenegraph relativement complexe, un systeme de vertex/pixel shaders base sur des dll de shaders pluggables qui gere un bouncing automatique et transparent des shaders en fonction du hardware, ou pour plein d'autres trucs, essayer d'optimiser a ce niveau la est une pure perte de temps, et franchement ca m'etonne de toi

pour ce genre de trucs, c'est beaucoup plus important d'avoir un haut niveau d'abstraction qu'un truc imbitable mais soit disant "optimise" qui te fera gagner au mieux 1 ou 2 fps sur 300... alors qu'en passant le temps que t'as perdu ici a approfondir d'autres parties beaucoup plus critiques tu pourrais en gagner 100...
c'est justement ca mon "ideal", comme mixer le C et l'asm sur Ti (que je n'ai jamais fait, je suis tjrs reste a l'asm mais bon ), mixer le C et le C++ sur pc. tout ce qui est tres bas niveau en C voire avec des morceaux d'assembleur (par exemple, ce que je vais faire pour un occlusion culler en software en utilisant les instructions SSE), et tout ce qui est haut niveau en C++.

quoique je pense pas que je prenne bcp de risques en disant que tout pourrait etre fait en C++ & asm, en se passant de C, mais bon, la encore, c'est un point de vue uniquement en fonction du peu que j'ai vu du C++, donc j'ai sans doute tord mais je donne mon avis quand meme

Pas forcement.
On peut aussi generer une lib statique par module et un fichier par fonction. C'est aussi courant en C.
[...]
Tu peux faire pour chaque module une lib statique avec dedans tous les fichiers de la libs. Puis le projet linke toutes les libs statiques. Tu peux meme en faire des libs dynamiques.

non merci, ca ferait a peu pres 60-70 libs statiques ou dynamiques pour l'instant, et au dessus de 150 a la fin
c'est le genre de trucs inutiles dont on peut se passer, et voila un exemple parfait de tout le bordel que t'es oblige de faire pour avoir un (a peu pres) equivalent de ce que tu pourrais faire simplement en C++...
et le proj se decoupe deja en 5 grosses libs dynamiques et un (ou plusieurs executables), plus des tas de libs dynamiques pour chaque groupe de shaders. ca fait deja suffisemment usine a gaz comme ca

EDIT: j'av pas vu le truc du un fichier par fonction, la on passe a l'autre extreme
ca devient presque aussi ennervant a lire d'avoir un fichier par fonction que un fichier par module... sans compter le nombre de fichiers, et en plus pour le temps de compilation, par exemple pour une app win, si chaque fichier doit inclure windows.h, meme en ayant defini les WIN32_LEAN_AND_MEAN, et autres EXTRA_LEAN, le header est toujours relativement enorme, et c'est le preprocesseur qui prend plus de temps que le compilateur... donc t'augmente significativement le temps de compilation...

Ben tvector_matmul_2x2_3x2(a,b,c) C'est vrai que ca demande un peu plus d'effort.

c'est pas une question d'effort bordel, c'est une question d'abstraction...

tvector_matmul_2x2_3x2_inverse_transpose(&a, b, c)
ou:
tvector_matmul_2x2_3x2_inverse_transpose_pointer_c(&a, b, &c) ?
ou encore:
tvector_matmul_2x2_3x2_inverse_transpose_pointer_b_pointer_c(&a, &b, &c) ?

je dois sans doute avoir du mal a m'exprimer

Perso j'aurais ecrit en C:
t_vector_4 truc, machin;
...
t_vector_4_inc(truc, machin);
La logique du C est d'encapsuler le code dans des fonctions (que tu peux definir inline). M'enfin ce que j'ai dit reste vrai.

c'etait un exemple _simple_

vazy encapsule ca dans des fonctions, et compare les deux codes apres voir lesquels sont les plus lisibles et maintenables...

t_vector_4 truc, machin;
truc *= machin + truc * (machin / truc - machin * 2.0f) + 1.0f;

... et encore y a bien pire (dans un code de moteur physique non trivial par exemple...)

>si tu veux un code un minimum portable, c'est pas super de se baser sur telle ou telle implementation. Nan, il ne sagissait pas de portabilite mais de performances sur differents systemes.

oui, et tu peux avoir une meilleure performance en changeant de facon de faire et en gardant une bonne portabilite... super non?

Ben tvector_matmul_2x2_3x2(a,b,c) C'est vrai que ca demande un peu plus d'effort.

surtout que pour la maintenabilite du code, heu excuse moi mais... t'as des fonctions qui utilisent des multiplications de matrices 4*3 a pleins d'endroits, maintenant 3 mois apres tu decide de changer et d'utiliser des 4*4... si tu utilise l'overloading des operateurs et des fonctions, y a de grandes chances pour que t'aie quasiment rien a changer, si tu fais ca en C, t'as quasiment tout a changer... super

sBibi :
euh oue non mais arrette... ca prend pas 5 min ca, ca prend 20 secondes a taper (le temps de reflechir au nom), c'est pas ca que je voulais dire... et j'ai pas dit que ct long et difficile, juste que c'etait inutile et que quand t'en a des tas a faire, ce temps pourrait etre passe a faire d'autres trucs (en plus d'alourdir les .h)

Ben alors ca prend 20 s. Que fais-tu en 20s ?
C'est pas inutile puisque ca evite les noms de collisions.
Et lorsque tu en as des tas a faire, le temps passe a le faire est negligeable devant les autres temps.

peut etre, sans doute, ca j'en sais rien, je le repete: j'ai jamais rien fait en C++, je dis juste que vu ce que j'en vois, ce que j'en entends (hormis certains ), l'utilisation qui en est faite dans l'industrie, et des tas d'autres trucs, le C++ me parait bcp plus adapte a certains trucs que le C (beaucoup meme...)

Exemple ?

et tu l'a peut etre mal choisi... du moins si je faisais ce meme choix (et je l'ai fait, pas le choix, j'av pas le temps d'apprendre le C++ ), ca aurait ete le mauvais...
vouloir gagner en temps d'execution en choisissant le langage, dans des trucs haut niveau comme (par exemple) un scenegraph relativement complexe, un systeme de vertex/pixel shaders base sur des dll de shaders pluggables qui gere un bouncing automatique et transparent des shaders en fonction du hardware, ou pour plein d'autres trucs, essayer d'optimiser a ce niveau la est une pure perte de temps, et franchement ca m'etonne de toi

Apprend a lire ce que j'ecris.

pour ce genre de trucs, c'est beaucoup plus important d'avoir un haut niveau d'abstraction qu'un truc imbitable mais soit disant "optimise" qui te fera gagner au mieux 1 ou 2 fps sur 300... alors qu'en passant le temps que t'as perdu ici a approfondir d'autres parties beaucoup plus critiques tu pourrais en gagner 100...

Une bonne architecture est assez independant du langage utilise. Donc...

c'est justement ca mon "ideal", comme mixer le C et l'asm sur Ti (que je n'ai jamais fait, je suis tjrs reste a l'asm mais bon ), mixer le C et le C++ sur pc. tout ce qui est tres bas niveau en C voire avec des morceaux d'assembleur (par exemple, ce que je vais faire pour un occlusion culler en software en utilisant les instructions SSE), et tout ce qui est haut niveau en C++.

Mixer l'assembleur et le C++ ? Ca sent les problemes a plein nez.

quoique je pense pas que je prenne bcp de risques en disant que tout pourrait etre fait en C++ & asm, en se passant de C, mais bon, la encore, c'est un point de vue uniquement en fonction du peu que j'ai vu du C++, donc j'ai sans doute tord mais je donne mon avis quand meme

Fait du C++. On en parlera apres.

non merci, ca ferait a peu pres 60-70 libs statiques ou dynamiques pour l'instant, et au dessus de 150 a la fin

Et alors ? make gere ca tres bien

c'est le genre de trucs inutiles dont on peut se passer, et voila un exemple parfait de tout le bordel que t'es oblige de faire pour avoir un (a peu pres) equivalent de ce que tu pourrais faire simplement en C++...
et le proj se decoupe deja en 5 grosses libs dynamiques et un (ou plusieurs executables), plus des tas de libs dynamiques pour chaque groupe de shaders. ca fait deja suffisemment usine a gaz comme ca

Oue. Je crois que vous devriez tout jeter et reprendre a zero.
Tu me rappelles ces gars qui ont fait un serveur php en C++ avec des classes pour tout.
Tres beau en theorie. Inbuvable en pratique.

EDIT: j'av pas vu le truc du un fichier par fonction, la on passe a l'autre extreme
ca devient presque aussi ennervant a lire d'avoir un fichier par fonction que un fichier par module... sans compter le nombre de fichiers, et en plus pour le temps de compilation, par exemple pour une app win, si chaque fichier doit inclure windows.h, meme en ayant defini les WIN32_LEAN_AND_MEAN, et autres EXTRA_LEAN, le header est toujours relativement enorme, et c'est le preprocesseur qui prend plus de temps que le compilateur... donc t'augmente significativement le temps de compilation...

Pas forcement. Enfin perso maintenant je fais un fichier par fonction en C. Avec make ca marche plutot bien. En plus c'est simple a lire. Et tu n'as pas forcment besoin d'inclure windows.h a chaque fichier, ou alors c'est que l'app win est mal architecturee.

c'est pas une question d'effort bordel, c'est une question d'abstraction...
tvector_matmul_2x2_3x2_inverse_transpose(&a, b, c)
ou:
tvector_matmul_2x2_3x2_inverse_transpose_pointer_c(&a, b, &c) ?
ou encore:
tvector_matmul_2x2_3x2_inverse_transpose_pointer_b_pointer_c(&a, &b, &c) ?
je dois sans doute avoir du mal a m'exprimer

Ben regarde:
void vector_matmul_2x2_3x2(vector_t *a, const vector_t *b, const vector_t *c)
{
...
}
#define vector_matmul_2x2_3x2(a,b,c_ vector_matmul_2x2_3x2(&a,&b,&c)
C'est aussi mal de mettre trop de couches d'abstractions. Ca complexifie le code inutiliement.
Mais la n'est pas le probleme.

c'etait un exemple _simple_

vazy encapsule ca dans des fonctions, et compare les deux codes apres voir lesquels sont les plus lisibles et maintenables...

t_vector_4 truc, machin;
truc *= machin + truc * (machin / truc - machin * 2.0f) + 1.0f;

Lol. L'usine a gaz. Y'a pas de definition naturelle pour la division de deux vecteurs.
Vive l'abstraction C++ . En plus c'est pas homogene... M'enfin ca se voit pas
C'est vraiment le genre de truc qu'il faudrait jeter du C++.

... et encore y a bien pire (dans un code de moteur physique non trivial par exemple...)

Encore plus usine a gaz ?

oui, et tu peux avoir une meilleure performance en changeant de facon de faire et en gardant une bonne portabilite... super non?

Tant mieux.

sBibi :
surtout que pour la maintenabilite du code, heu excuse moi mais... t'as des fonctions qui utilisent des multiplications de matrices 4*3 a pleins d'endroits, maintenant 3 mois apres tu decide de changer et d'utiliser des 4*4... si tu utilise l'overloading des operateurs et des fonctions, y a de grandes chances pour que t'aie quasiment rien a changer, si tu fais ca en C, t'as quasiment tout a changer... super

C'est que ton architecure etait mauvaise des le debut.
Fallait mettre une couche d'abstraction intemediaire.

Bon, allez, modeste contribution à un Troll énorme :
Déjà évite le Java (enfin, sauf si vraiment tu as des imperatifs de portabilité). C'est lourd, pour créer une fenêtre il te faut 10 lignes (et encore), tu t'emmerdes avec des classes qui sont deprecated parce que les développeurs des classes s'y sont pris comme des manches, tu penses que t'as un prog protable à 100% et manque de chance les classes que tu utilises ne sont pas portées sur toutes les flateformes...
Le C, c'est pas mal, mais pour les gros projets, c'est très vite limité (notamment pour le travail en équipe ou lorsque tu as eu une grosse analyse derrière... [UML powaaaa... enfin, bon, c'est pas le débat ]). Par contre, c'est bien si tu veux t'y retrouver par rapport au C de la TI.
C++, bah c'est bien, c'est propre (mmmhhh, une classe bien présentée ), c'est moins rapide que le C, c'est certain, mais alors quel régal. Par contre, si t'as jamais developpé en langage objet, ça va être dur, c'est une façon de penser sa programmation qui est bien plus proche de l'analyse que dans la programmation standard.
Ah, et sinon, tu peux toujours faire du Prolog. C'est génial, ça ne ressemble à rien d'autre, c'est sur au début, mais c'est vraiment puissant (notamment pour les IA, parce que pour développer une appli de gestion en Prolog, bah euuuh... déjà, je ne sais pas si on peut l'interfacer avec une base de données ).
Enfin, voilà, pour résumer : si tu n'as pas le courage/le temps de te mettre à quelque chose de différent (la programmation objet), direction le C. Sinon, le C++.

sBibi :
surtout que pour la maintenabilite du code, heu excuse moi mais... t'as des fonctions qui utilisent des multiplications de matrices 4*3 a pleins d'endroits, maintenant 3 mois apres tu decide de changer et d'utiliser des 4*4... si tu utilise l'overloading des operateurs et des fonctions, y a de grandes chances pour que t'aie quasiment rien a changer, si tu fais ca en C, t'as quasiment tout a changer... super

En plus, Kevin te dirait qu'un bon IDE resoud ce genre de probleme rapidement.

PpHd :
Ben alors ca prend 20 s. Que fais-tu en 20s ?
C'est pas inutile puisque ca evite les noms de collisions.
Et lorsque tu en as des tas a faire, le temps passe a le faire est negligeable devant les autres temps.

c'est inutile pke en C++ il n'y aurait pas ce probleme....
et le temps passe a faire _ca_ est peut etre negligeable, mais le temps passe a faire en C _tous_ les petits trucs que tu n'aurais pas a faire en C++ ne l'est pas...

Exemple ?

exemple? t'en aura des _tas_ si tu vas voir les forums de prog de gamedev, ah mais j'oubliais, tu n'y va pas pke ils sont trop orientes C++? forcement si t'essaye pas de cotoyer des programmeurs C++ c'est pas etonnant que t'en connaisse aucun de bon

Apprend a lire ce que j'ecris.

ah oui, j'avais lu tu en gagne pas mal en temps d'execution
bah pour temps de compilation, je prefere que ca mette un petit peu plus de temps a compiler mais que ca soit plus maintenable par une equipe de devs, et plus simple a reprendre plusieurs mois apres...

Une bonne architecture est assez independant du langage utilise. Donc...

donc quoi? tu peux avoir la meme architecture en C que tu l'aurais en C++, mais avoir une implementation beaucoup plus obscure et/ou difficilement evolutive pour un des deux...

Mixer l'assembleur et le C++ ? Ca sent les problemes a plein nez.

ah? pourquoi? j'ai vu ca etre fait assez souvent... c'est quoi les "problemes"?

Fait du C++. On en parlera apres.

lol c'est facile ca comme reponse
je me tue a preciser a quasiment chacun de mes posts que quand je parle de C++ je ne peux parler que de ce que j'en ai vu, pas du langage dans sa totalite... et je me base aussi sur l'avis commun de la tripotee de devs de gamedev...

Et alors ? make gere ca tres bien

oue mais non... utiliser les libs statiques juste comme un "hack" pour contourner un pbl du C que le C++ n'a pas, non merci...
surtout que je sais pas si tu t'en rends compte mais quasiment tous les arguments que tu donnent rejoignent ce que j'ai dit tout au debut: le C oblige a utiliser pleins de ruses dans ce genre la pour faire ce que tu peux faire en C++, cf "emuler" des features C++ en C...

Oue. Je crois que vous devriez tout jeter et reprendre a zero.
Tu me rappelles ces gars qui ont fait un serveur php en C++ avec des classes pour tout.
Tres beau en theorie. Inbuvable en pratique.

huhu
tu sais ce que c'est au moins pour te permettre de me dire de tout reprendre a 0?
et meme si on voulait, on pourrait pas, on a une deadline en juillet...
et je ne vois pas en quoi je peux te rappeller qui ou quoi que ce soit, tu ne sait pas de quel projet je parle (en tout cas je vois pas comment tu pourrais le savoir...)

Pas forcement. Enfin perso maintenant je fais un fichier par fonction en C. Avec make ca marche plutot bien. En plus c'est simple a lire. Et tu n'as pas forcment besoin d'inclure windows.h a chaque fichier, ou alors c'est que l'app win est mal architecturee.

soit..
pour win.h: pas a chaque fichier non, sauf dans un module de gestion de fenetres ou t'as par exemple une structure privee qui est utilisee dans tout le module et qui contient des vars du style HWND ou autres
oh bien sur tu peux te demmerder pour ne pas l'inclure a chaque fichier... mais a quel prix? et quel interet alors que tu pourrais eviter ca tres simplement?

Ben regarde:
void vector_matmul_2x2_3x2(vector_t *a, const vector_t *b, const vector_t *c)
{
...
}
#define vector_matmul_2x2_3x2(a,b,c_ vector_matmul_2x2_3x2(&a,&b,&c)
C'est aussi mal de mettre trop de couches d'abstractions. Ca complexifie le code inutiliement.
Mais la n'est pas le probleme.

soit j'ai pas compris ton exemple, soit t'as pas compris le mien...

Lol. L'usine a gaz. Y'a pas de definition naturelle pour la division de deux vecteurs.
Vive l'abstraction C++ . En plus c'est pas homogene... M'enfin ca se voit pas
C'est vraiment le genre de truc qu'il faudrait jeter du C++.

ptain mais c'est un exemple, c'est pas cense faire quoi que ce soit, c'est uniquement point de vue ecriture...

bon pas de divisions de vecteurs... okkk, remplace ca par des matrice et la div par une multiplication par l'inverse.. vala

Encore plus usine a gaz ?

enfin ca depend de ce que t'appelle usine a gaz... moi j'appelle usine a gaz l'implementation en C, alors que l'implementation C++ est bcp plus claire, limpide, et met en valeur de facon bcp plus evidente les algos et formules utilisees...

C'est que ton architecure etait mauvaise des le debut. Fallait mettre une couche d'abstraction intemediaire.

C'est aussi mal de mettre trop de couches d'abstractions. Ca complexifie le code inutiliement. Mais la n'est pas le probleme

ca revient tjrs au meme point, l'architecture est mauvaise ^^
tu sais, c'est bien beau de tout faire et prevoir sur papier, et puis de tout coder d'un seul coup sans bugs ou sans rien avoir a modifier qu'on n'avait pas prevu
malheureusement c'est completement utopique pour des gros projets

En plus, Kevin te dirait qu'un bon IDE resoud ce genre de probleme rapidement.

heu.. comment ca? O_o

sBibi :
c'est inutile pke en C++ il n'y aurait pas ce probleme....

et le temps passe a faire _ca_ est peut etre negligeable, mais le temps passe a faire en C _tous_ les petits trucs que tu n'aurais pas a faire en C++ ne l'est pas...

A oue ? Perso pour les projets que j'ai fait:
20% : design de l'architecture.
30% : ecriture du code et du jeu de tests automatiques.
50% : debuggage et affinage des tests.
Mettons que tu prennes 10% de temps en + en C qu'en C++ pour ecrire (c'est vraiment enorme), ben ca fera que 3% sur le projet. Enfin, je peux me tromper.

exemple? t'en aura des _tas_ si tu vas voir les forums de prog de gamedev, ah mais j'oubliais, tu n'y va pas pke ils sont trop orientes C++? forcement si t'essaye pas de cotoyer des programmeurs C++ c'est pas etonnant que t'en connaisse aucun de bon

Ben j'y vais pas, car je fais pas de jeux pour PC.
Si tu veux je peux y aller.

ah oui, j'avais lu tu en gagne pas mal en temps d'execution
bah pour temps de compilation, je prefere que ca mette un petit peu plus de temps a compiler mais que ca soit plus maintenable par une equipe de devs, et plus simple a reprendre plusieurs mois apres...

Le caractere maintenable n'a rien a voir avec le langage.

donc quoi? tu peux avoir la meme architecture en C que tu l'aurais en C++, mais avoir une implementation beaucoup plus obscure et/ou difficilement evolutive pour un des deux...

En quoi est-elle plus obscure ?
Ton probleme est de vouloir faire du C++ en C.
C'est pas la meme chose.

ah? pourquoi? j'ai vu ca etre fait assez souvent... c'est quoi les "problemes"?

ABI non standardise. Sauf si tu fais des macros inlines.

lol c'est facile ca comme reponse
je me tue a preciser a quasiment chacun de mes posts que quand je parle de C++ je ne peux parler que de ce que j'en ai vu, pas du langage dans sa totalite... et je me base aussi sur l'avis commun de la tripotee de devs de gamedev...

Ce qui ne fais pas ton avis. Donc j'attends ton avis a toi.

oue mais non... utiliser les libs statiques juste comme un "hack" pour contourner un pbl du C que le C++ n'a pas, non merci...

Ca n'a rien d'un hack, et tu n'es pas obblige de le faire.

surtout que je sais pas si tu t'en rends compte mais quasiment tous les arguments que tu donnent rejoignent ce que j'ai dit tout au debut: le C oblige a utiliser pleins de ruses dans ce genre la pour faire ce que tu peux faire en C++, cf "emuler" des features C++ en C...

Tous les arguments pour le C++ sont vraiment des broutilles.
(Sauf la STL qui est quand meme assez riche en fonctionnalite).

tu sais ce que c'est au moins pour te permettre de me dire de tout reprendre a 0?
et meme si on voulait, on pourrait pas, on a une deadline en juillet...

J'ai une vague idee. Mais je sens que votre projet est mal parti.

et je ne vois pas en quoi je peux te rappeller qui ou quoi que ce soit, tu ne sait pas de quel projet je parle (en tout cas je vois pas comment tu pourrais le savoir...)

Ben c'est tes commentaires sur ton projet qui me l'ont fait penser. c'est tout.

pour win.h: pas a chaque fichier non, sauf dans un module de gestion de fenetres ou t'as par exemple une structure privee qui est utilisee dans tout le module et qui contient des vars du style HWND ou autres oh bien sur tu peux te demmerder pour ne pas l'inclure a chaque fichier... mais a quel prix? et quel interet alors que tu pourrais eviter ca tres simplement?

Si tu passez des vars HWND, c'est que ton programme est trop proche de windows et que tu devrais mettre une couche d'abstraction supplementaire

soit j'ai pas compris ton exemple, soit t'as pas compris le mien...

Faut simplifier la vie .

ptain mais c'est un exemple, c'est pas cense faire quoi que ce soit, c'est uniquement point de vue ecriture...
bon pas de divisions de vecteurs... okkk, remplace ca par des matrice et la div par une multiplication par l'inverse.. vala

Et alors ? C'est vraiment plus dur de faire appel aux fonctions ?
Oui, un peu.

enfin ca depend de ce que t'appelle usine a gaz... moi j'appelle usine a gaz l'implementation en C, alors que l'implementation C++ est bcp plus claire, limpide, et met en valeur de facon bcp plus evidente les algos et formules utilisees...

Moi j'appelle usine a gaz les programmes c++ que je trouve sur le net

ca revient tjrs au meme point, l'architecture est mauvaise ^^
tu sais, c'est bien beau de tout faire et prevoir sur papier, et puis de tout coder d'un seul coup sans bugs ou sans rien avoir a modifier qu'on n'avait pas prevu
malheureusement c'est completement utopique pour des gros projets

Oui je sais.
mais si l'architecture change trop, il faut mieux tout reprendre.
Beaucoup plus sain et au final plus rapide.

heu.. comment ca? O_o

Ben Replace all.

Moi quand j'aurai un peu de temps j'ai envie d'apprendre l'objective C, ça a l'air sympa

Pour resumer, ce que je te reproche c'est de croire que le C++ est un langage magique qui resoud (presque) tout, alors que ce n'est qu'un langage avec une approche differente. La difficulte de la programmation d'un gros projet ne depend pas vraiment du langage, mais plutot de la maitrise des outils utilises et surtout de celui responsable de l'architecture du projet.

PS: Et ne me parlez pas de l'industrie. Ils programment comme des porcs dans l'industrie (en general).

A oue ? Perso pour les projets que j'ai fait:
20% : design de l'architecture.
30% : ecriture du code et du jeu de tests automatiques.
50% : debuggage et affinage des tests.
Mettons que tu prennes 10% de temps en + en C qu'en C++ pour ecrire (c'est vraiment enorme), ben ca fera que 3% sur le projet. Enfin, je peux me tromper.

sauf que ca a aussi un gros impact dans la partie debuggage, meme plus (bcp) que sur la partie code (je trouve)

Ben j'y vais pas, car je fais pas de jeux pour PC. Si tu veux je peux y aller.

tu sais que t'as une rubrique general programming qui traite de tout, que ce soit jeux ou pas, que t'as aussi une section multiplayer & networking qui traite certes de l'aspect reseau dans les jeux mais aussi de n'importe quoi qui a rapport avec de la prog reseau, idem pour le forum "maths and physics", pour "Artificial Intelligence", pour "Software Engineering" (qui malheureusement est legerement en deperissement )
bref, a la base, c'est evidemment plutot en rapport avec les jeux PC, mais il y a des _tas_ de topics generaux qui peuvent s'appliquer a pleins de trucs, par exemple l'autre jour dans general programming y a un gars qui a poste un topic pke il faisait un os (dans un but educatif).. aucun rapport avec les jeux pc

Le caractere maintenable n'a rien a voir avec le langage.

il a a voir, entre autres, avec la lisibilite, surtout quand c'est un code que t'as pas ecrit toi, et la lisibilite, dans le cas de C/C++, je trouve que si, ca a un rapport avec le langage...

et me dis pas que t'as trouve des codes C++ immondes sur le net, ca a aussi a voir avec la norme utilisee pour la presentation... du C++ code avec une norme immonde peut etre bien pire que du C code avec une norme immonde, mais du C++ code avec une norme lisible et claire peut aussi etre mieux que du C code avec une norme lisible et claire... mais bon ca les normes c encore un autre sujet a trolls

moi j'aime pas les accolades a la fin des if sur la mm ligne

En quoi est-elle plus obscure ?
Ton probleme est de vouloir faire du C++ en C. C'est pas la meme chose.

pas du tout, c'est different, mon pbl, c'est que j'ai tout fait en C, mais que pour arriver au niveau d'abstraction dont j'avais besoin, et pour faire certaines choses, j'ai du structurer le proj et mon code d'une certaines facon, employer des ruses diverses (qui ont ete enumerees par toi meme dans ce topic en me repondant ), et au final, je me suis rendu compte que ca n'etait rien d'autre qu'une "emulation" de certaines features du C++.
c'est pas que je veux faire du C++ en C, pas du tout, c'est que je fais du C, mais que pour faire ce que je veux faire, je trouve le C++ est beaucoup plus adapte...

ABI non standardise. Sauf si tu fais des macros inlines

a bon.. heu.. "ABI" ?

Ce qui ne fais pas ton avis. Donc j'attends ton avis a toi.

je viens de te dire que n'ayant pas code en C++, mon avis sur la question je me le fais a partir de l'avis de pleins d'autres personnes sinon j'aurais pas d'avis... c'est aussi simple que ca

Ca n'a rien d'un hack, et tu n'es pas obblige de le faire.

ah oui ca c'est sur, je suis pas oblige de le faire, c'est pour ca que je le fais pas d'ailleurs ^^

Tous les arguments pour le C++ sont vraiment des broutilles.

bah c'est sans doute des broutilles, mais je trouve que c'est des broutilles utiles

J'ai une vague idee. Mais je sens que votre projet est mal parti.

si tu le sens.. alors c'est surement vrai
ceci dit, si il est mal parti, c'est pas du tout a cause de ca (mal fini plutot)

Ben c'est tes commentaires sur ton projet qui me l'ont fait penser. c'est tout.

en tt cas je vois pas le rapport...

Si tu passez des vars HWND, c'est que ton programme est trop proche de windows et que tu devrais mettre une couche d'abstraction supplementaire

j'ai bien dit que cette structure etait _privee_, ce genre de trucs n'apparait absolument pas dans l'interface du module, c'est uniquement une gestion interne
et justement, elle est peut etre _volontairement_ tres proche de windows, c'est peut etre la couche d'abstraction la plus basse, qui sert d'interface au reste

Faut simplifier la vie

on est d'accord... et le C me la complique
enfin non, plutot, le C++ me la simplifierait, mais je RE-dis ce que g deja dit une fois au dessus, peut etre (surement) certaines des particularites du C++ que je ne connais pas me la compliquerait, en tout cas tout ce que j'ai pu voir ca me l'aurait simplifiee
(et t'as pas compris mon exemple, pas grave...)

Et alors ? C'est vraiment plus dur de faire appel aux fonctions ? Oui, un peu.

tu dois le faire expres c pas possible
c'est pas une question de DUR........... c'est une question que c'est ILLISIBLE
et que tu dois faire des efforts non pas pour l'ecrire, mais surtout pour comprendre ce que ca fait apres, alors que dans l'autre cas, t'as carrement la formule utilisee devant le nez...
rhalala tu devrais coder quelques shaders en CG tu verrais quel bonheur c'est ^^
en C ca serait l'enfer
bah la c'est pareil...

Moi j'appelle usine a gaz les programmes c++ que je trouve sur le net

je defends pas l'utilisation qui est faite du C++, je trouve aussi pleins de progs que je trouve immondes. je dis juste que le C++ permet (re-re-re-re-repete: juste avec ce que j'en ai vu) de faire des progs plus propres, plus courts, plus simples a debug et faire evoluer...

Oui je sais.
mais si l'architecture change trop, il faut mieux tout reprendre. Beaucoup plus sain et au final plus rapide.

bien sur, et je suis le premier a le faire... quand j'ai le temps de le faire (en prenant en compte le temps que ca ferait gagner par la suite de le refaire, mais meme en prenant ca en compte, c'est pas avantageux dans mon cas actuel...)
pour les petits projets, oui c'est sur c'est bcp mieux, t'as une meilleure vision du truc, tu sais plus ou tu vas, tu refais pas certaines erreurs, c'est plus propre, etc, etc...

Ben Replace all.

pff.. dans certains cas c'est pas aussi simple hein
et pas besoin d'avoir une IDE pour ca, emacs le fait tres bien...