Votre IDE préféré ?

Laurent BERNE wrote:

la communauté étant plus que divisé au sujet de mono, si borland mise
là-dessus pour linux, il risque de perdre encore plus qu'avec kylix

Je suis pas sur que Borland vise la communauté Linux. Je crois surtout
qu'ils visent les développeurs Windows qui veulent aussi développer sous
Linux.
Aujourd'hui, Delphi est passé à l'heure Dot Net (Delphi 8 ne fait pas de
compilation Win32). Beaucoup veulent continuer a récupérer leur code
Delphi et le réutiliser sous Linux, comme ils faisaient sous Kylix.
Borland s'est aussi investi dans un environnement C# (C# Builder). D'où
les rumeurs concernant Mono. Mais bien sûr, ce ne sont que des rumeurs,
ils n'y a aucune position officielle pour l'instant.

Pour ceux qui veulent pas de Mono, il reste C++Builder X, l'IDE C++ de
Borland, qui est devenu multi plateforme (basé sur l'IDE de JBuilder).
Il fonctionne avec la plupart des compilos C++ (y compris gcc).

comme tu dis, borland vise plus des programmeurs windows, sous linux si
désire faire du c++, beaucoup utilise emac... perso j'utilise plus
eclipse ou kdevelop

au prix que coûte c++ builder X et pour ce qu'il donne comparativement à
ces deux derniers...

--
La boîte à prog http://www.laboiteaprog.com

Miod Vallat <miod@online.fr> writes:

Si c'est propre et structuré, c'est forcément utile..(la beauté c'est
subjectif....)

Pour moi, ces deux notions sont orthogonales.

C'est pas utile que ça soit beau ?

MB
--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)

Si c'est propre et structuré, c'est forcément utile..(la beauté c'est
subjectif....)

Pour moi, ces deux notions sont orthogonales.

C'est pas utile que ça soit beau ?

Intrinsèquement, non.

En pratique, ça aide beaucoup à obtenir le caractère fonctionnel et
robuste dont découle l'utilité...

On 30 Aug 2004 19:25:36 +0200, Michel Billaud wrote:

Pour moi, ces deux notions sont orthogonales.

C'est pas utile que ça soit beau ?

Malheureusement, tout ce qui est utile est laid ; car c'est
l'expression de quelque besoin ; et ceux de l'homme sont ignobles et
dégoûtants, comme sa pauvre et infirme nature. L'endroit le plus utile
d'une maison, ce sont les latrines.

--
Sam.

Cela revient à ne pouvoir instancier que des objets dont
la durée de vie est contrôlée par la notion de portée dans
les sources.

ouaip. Code beau, propre et structuré.

Acte de foi. Le mien, c'est :

ouaip. Architecture pré-historique qui ne peut produire que des monstres
monolithiques. La durée de vie d'un objet ne peut pas toujours être encadrée
par les accolades d'un source, pour peu qu'on utilise un minimum de
programmation événementielle/asynchrone/multitâches.

Sans parler du problème du nombre d'objets (il
faut un pointeur différent déclaré par objet, non ?).

dans ces cas là, on utilise les conteneurs plutôt (list, vector,
deque..)
Ils se redimensionnent à l'infini(enfin dans la possibilité de la
machine), se demerdent comme des grands pour la gestion de la mémoire.
On créer l'objet, on le jette dans le conteneur(mais dans ce cas
précis, on l'instancie pas par l'opérateur new..)

Quand et comment les ressources associées à l'objet "jeté" dans le
conteneur sont-elles libérées ?

--
Gno way, Kant happen.
--Anonymous Coward

Il se trouve que Manuel Leclerc a formulé :

Cela revient à ne pouvoir instancier que des objets dont
la durée de vie est contrôlée par la notion de portée dans
les sources.

ouaip. Code beau, propre et structuré.

Acte de foi. Le mien, c'est :

ouaip. Architecture pré-historique qui ne peut produire que des monstres
monolithiques. La durée de vie d'un objet ne peut pas toujours être encadrée
par les accolades d'un source, pour peu qu'on utilise un minimum de
programmation événementielle/asynchrone/multitâches.

bin si. C'est ce que j'utilise tous les jours (événementielle et multi
tâches surtout).

C'est justement le fait de pas structurer le code que je trouve
archaique.. question de gout quoi ...

Sans parler du problème du nombre d'objets (il
faut un pointeur différent déclaré par objet, non ?).

dans ces cas là, on utilise les conteneurs plutôt (list, vector,
deque..)
Ils se redimensionnent à l'infini(enfin dans la possibilité de la
machine), se demerdent comme des grands pour la gestion de la mémoire.
On créer l'objet, on le jette dans le conteneur(mais dans ce cas
précis, on l'instancie pas par l'opérateur new..)

Quand et comment les ressources associées à l'objet "jeté" dans le
conteneur sont-elles libérées ?
quand le conteneur est détruit(à moins qu'on lui demande spécifiquement

de virer un élément par la méthode erase ou clear du container)

--
Ce n'est pas parce que tu touches le fond que tu dois t'arrêter de
creuser

Du code C++ pur n'a pas besoin de pointeur.
J'ai fait un moteur d'optimisation de découpe entièrement en C++,
quelques milliers de lignes (je sais pas combien, je m'amuse pas à les
compter). Pas un seul pointeur dedans.

je ne suis pas un pro du c++
mais sans les pointeurs comment tu fais de l'heritage indirect

maClass0
{
f0()
f1()

}
maClass1
{
f0()
f1()

}
maclassSomme
{
a=new maClass0()
b=new maClass1()

f0()
{
a.f0()
}
f00()
{
b.f0();
}
}


dans maclassSomme a et b sont bien des pointeurs
non ?
remy

je ne suis pas un pro du c++
mais sans les pointeurs comment tu fais de l'heritage indirect

petit prob dans ton exemple..

maClass0
{
f0()
f1()

}
maClass1
{
f0()
f1()

}
maclassSomme
{
a=new maClass0() // ici
b=new maClass1() // et ici

je suppose que tu veux déclarer a et b en tant que pointeur
dans ce cas il faut écrire
maClass0 *a =new maClass0() ; // important de dire que c'est un
pointeur, le compilo peut pas savoir tout seul
maClass1 *b =new maClass1() ;

f0()
{
a->f0();// tu n'avais pas mis le bon opérateur si a est un
pointeur
}
f00()
{
b->f0();// idem a
}




et ne pas oublier de libérer dans le destructeur de maclassSomme (sinon
fuite..)
delete a;
delete b;

par contre, rien ne t'empêche d'écrire
maclassSomme
{
maClass0 a = maClass0(); // ici c'est pas un pointeur, donc pas
d'opérateur new
maClass1 b= maClass1();
et dans ce cas là
f0()
{
a.f0();
}
f00()
{
b.f0();
}


pas besoin de libérer quoi que ce soit à la destruction de maclassSomme

avis perso : dans le cas "avec des pointeurs, je préfère séparer la
déclaration
maClass0 *a;
maClass1 *b ;

et mettre dans le constructeur
a = maClass0() ;
b = maClass1() ;


pour moi, ca accentue bien le côté "initialisation", encore plus quand
il s'agit de pointeur (code clair, facile à reprendre par un autre..)

--
Ce n'est pas parce que tu touches le fond que tu dois t'arrêter de
creuser

et mettre dans le constructeur
a = maClass0() ;
b = maClass1() ;

oups, j'ai oublié les "new"....
a = new maClass0() ;
b = new maClass1() ;

--
Ce n'est pas parce que tu touches le fond que tu dois t'arrêter de
creuser

Il se trouve que Manuel Leclerc a formulé :

Cela revient à ne pouvoir instancier que des objets dont la
durée de vie est contrôlée par la notion de portée dans les
sources.

ouaip. Code beau, propre et structuré.

Acte de foi. Le mien, c'est :

ouaip. Architecture pré-historique qui ne peut produire que des
monstres monolithiques. La durée de vie d'un objet ne peut pas
toujours être encadrée par les accolades d'un source, pour peu
qu'on utilise un minimum de programmation événementielle/
asynchrone/multitâches.

bin si. C'est ce que j'utilise tous les jours (événementielle

En programmation événementielle, beacoup de fonctions traitent des
événements (surprise !).

Chaque fois qu'un événement doit donner lieu à l'allocation d'une
ressource qui sera libérée on ne sait quand (lors d'un autre
événement, par exemple ?), la notion d'accolade dans les sources
est complètement hors sujet.

et multi tâches surtout).

Même combat. Si un thread commence à travailler en utilisant des
ressources allouées dans un autre thread, rien ne permet au
thread allocateur de gentiment attendre que le second thread
ait terminé pour pouvoir sortir de son bloc courant (si ce
n'est en se bloquant en attente et alors il va falloir
m'expliquer l'intérêt d'avoir deux threads !)

C'est justement le fait de pas structurer le code que je trouve
archaique.. question de gout quoi ...

Un peu de logique terrienne :

1) "code utilisant des pointeurs" N'est PAS équivalent à "code
pas structuré"

2) "structurer" N'est PAS équivalent à "structurer comme l'entend
Laurent BERNE"

A mon humble avis à moi que j'ai, "structurer" signifie :
"définir un ensemble de règles cohérentes entre elles et
permettant de décomposer un ensemble complexe en parties
individuellement plus simples."

Sans parler du problème du nombre d'objets (il faut un
pointeur différent déclaré par objet, non ?).

dans ces cas là, on utilise les conteneurs plutôt (list, vector,
deque..)
Ils se redimensionnent à l'infini (enfin dans la possibilité de
la machine), se demerdent comme des grands pour la gestion de
la mémoire.
On créer l'objet, on le jette dans le conteneur (mais dans ce
cas précis, on l'instancie pas par l'opérateur new..)

Tiens, au fait, pourquoi donc n'utilise-t-on pas l'opérateur new
dans ce cas ?

Quand et comment les ressources associées à l'objet "jeté" dans
le conteneur sont-elles libérées ?

quand le conteneur est détruit

C'est une méthode innaplicable quand la durée de vie utile des
ressources allouées est variable.

(à moins qu'on lui demande spécifiquement de virer un élément par
la méthode erase ou clear du container)

Voila. Merci de ton soutien.

Tu dis qu'on peut remplacer les pointeurs par des objets dont
la destruction est pris en charge par le langage, ce qui évite
soit disant les fuites mémoires, mais quand on te demande comment
traiter le cas des objets qui survivent à la portée de leur
allocation, tu réponds qu'il faut libérer explicitement !

Donc désolé, ce n'est pas une question de "pointeur", et il est
manifestement possible de coder SANS pointeurs et AVEC fuites
mémoires.

Par ailleurs, tu as snippé donc je répète : "Et puis, il faut du
coup faire remonter les détails d'implémentations dans les
fonctions appelantes, jusqu'à 'main' tant qu'on y est."
Car dans ton approche de la structuration par portée des sources,
la survie d'un objet en dehors de la fonction qui l'instancie
va te conduire à rendre explicite la présence de cette objet dans
la couche supérieure. Cela favorise le monolithisme par diffusion
du modèle de données, en opposition à la modularité par séparation
des fonctions. Je me comprends, c'est déjà ça.

--
Software engineering cost is what matters to me ( I turned 40, so I think
different now....;-) )
--Hans Reiser