Discussion :

[Klaim]

Si on ne manipule les éléments de cette list (ou n'importe quel container d'Objects) qu'à travers l'interface Object (voir les posts plus haut) alors je ne vois pas où est le problème...

Il a été dit avant que Object n'apport (par nature) quasiment pas de service utile. A cela j'ajouterai "hors informations de debug".

[metagoto]

Il a été dit avant que Object n'apport (par nature) quasiment pas de service utile. A cela j'ajouterai "hors informations de debug".

L'interface est présentée là:
http://www.developpez.net/forums/d78...d/#post4838794

Dans le cas de D, avoir un container d'Objects n'est probablement pas une hérésie.

[Klaim]

Tout comme en Java et en C#. (il n'y a quasiment pas de différence a ce que je vois, niveau fonctionalité rapport a Object)

Mais ce que dis koala01 c'est que c'est dommage de permettre "facilement" de manipuler directement des Object. Cela peut pas mal détourner des développeur dans des pratiques "abstraites" qui mèneront a du code difficile à comprenre/modifier.

Normalement dans ce type de language, un développeur experimenter n'utilisera quasimment jamais Object directement. Object "simpliefie" une pensée de manière trop radicale, qui dit que "tout" à une origine commune et qui au départ peut sembler comme un soulagement dans les contraintes a maintenir en codant (je pense notemment aux débutants qui ont apris du C ou du C++ et qui viennent a ces languages).
Un developpeur experiementé en Java et C# utilisera toujours des types de bases dans ses conteneurs qui indiquent la vrai nature commune de ses elements contenus, qui ne "devrait" jamais être Object, parceque Object est l'équivalent de "n'importe quoi", ce qui est pour le moins obfuscateur. Un wrapper autour de void* (Boost::Any?) a tout autant de sens : on en a besoin que dans des cas bien spécifiques et assez "extremes" conceptuellement.

Je ne suis personellement pas non plus fan d'une base commune Object (que j'ai aussi tendance a manipuler comme du void* dans les languages qui l'imposent) mais je me contente juste d'ignorer son existance jusqu'a ce que j'en ai besoin (ce qui est très rare, mais arrive, notemment en AS3...)

[metagoto]

Un wrapper autour de void* (Boost::Any?) a tout autant de sens : on en a besoin que dans des cas bien spécifiques et assez "extremes" conceptuellement.

Je suis de ton avis.
Mais dans ces cas bien spécifiques, il est intéressant d'être en mesure de manipuler une collection "d'Objets".
Les langages sus-cités ne sont pas c++, il faut bien qu'ils se démarquent un peu (déjà qu'ils partent perdant à la base )

[epsilon68]

ca serait bete de repartir dans un language comme D lorsqu'on est avancé dans le C++... moi je ne suis pas prêt d'abandonner tous mes outils et libs que j'ai fait ... il y a toujours un passé qu'il faut assumer, et plus un language est utilisé plus il devient difficile de le changer.

[Invité]

Faux débat. Les fonctions imbriquées ne sont utiles que si on a pas la possibilité d'écrire des fonctions anonymes (ce qui vient dans le futur standard). Dans le standard courant, il est tout à fait possible de créer une classe dans une fonction, et donc de créer autant de fonction imbriquées qu'on le souhaite - je reconnait toutefois que c'est tiré par les cheveux.

Intéressant, je ne connaissais pas ce truc.

Toutefois, la fonction imbriquée peut-elle accéder aux variables locales de la fonction englobante ?
En d'autre termes, y'a t'il un lien statique ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
int fonction_englobante()
{
    int a;
 
    struct 
    {
        void fonction_imbriquee()
        {
            // utilise a
        }
    } s;
 
    s.fonction_imbriquee();
}

Si ce code ne marche pas, cela signifie qu'il n'y a pas de lien statique et je dois passer ce que je veux à la fonction en paramètre, ce qui est aussi long que d'écrire une fonction "normale".

J'aborde juste ce point parce qu'il me fait gagner du temps en D. Je suis d'accord que le problème disparaitra avec C++1x.

les template sont plus destinés aux créateurs de librairies qu'aux développeurs d'applications.

Sans être créateur de libraries C++, je me suis retrouvé à devoir faire un ostream custom, et j'ai vite abandonné tellement c'était cryptique. Mais les programmeurs du forum me diront combien c'est facile

C'est vrai dès que tu as du code en liberté. Le C++ n'est ni plus ni moins touché que les autres langages.

Justement le C++ est particulièrement touché parce qu'il est le langage peut-être le plus long à maitriser. Ce n'est que mon avis, je n'ai pas de preuve

Qui n'ont de toute façon strictement aucune raison d'être dans le cadre d'une architecture orientée objet, donc ça n'est pas catastrophique.

Non bien sur ça n'est pas indispensable.

Mais j'ai du mal à voir pourquoi ca n'aurait aucune raison d'être. Gagner du temps, ca me suffit comme raison ; c'est juste une autre syntaxe pour écrire/appeler les getters/setters.

(Pour moi Delphi est le langage qui a su le mieux exploiter les propriétés : celles-ci peuvent être mappées directement sur un champ, ce qui ne crée aucun overhead même sans inlining)

La classe std::basic_string est standardisée - c'est donc la seule à utilisée, à moins d'une contre-indication liée à un framework quelconque (les coupables : Qt, MFC, ... principalement pour des raisons historiques, ces framework datant souvent d'une époque ou les compilateurs ne respectait pas le standard de 98). Les classes du TR1 (héritée de boost) présentent les smart pointer qu'il faut. Elles ont été intégrée au futur standard C++ - donc elles sont normalisées aussi.

Ok, le problème sera réglé dans le futur.

Certains des points que tu soulèves ont leur importance, par contre, d'autre sont quand même des faux problèmes.

Je ne trouve pas, c'est pour ca que j'ai choisi un autre ensemble de problèmes : D

[_skip]

Je ne suis personellement pas non plus fan d'une base commune Object (que j'ai aussi tendance a manipuler comme du void* dans les languages qui l'imposent) mais je me contente juste d'ignorer son existance jusqu'a ce que j'en ai besoin (ce qui est très rare, mais arrive, notemment en AS3...)

Ce qu'il faut considérer cependant, c'est que Object, même si ce n'est pas là une classe donc tu crées des instances tous les jours (ou alors c'est qu'il y a un sérieux problème) sert aussi d'interface pour tout le framework.

Tu as par exemples des méthodes comme toString(), hashCode() que l'on t'invite éventuellement à redéfinir et ces méthodes sont utilisées par les collections, par les interfaces graphiques et tout un tas de trucs.

Bref, je pense qu'il faut vraiment le voir comme une interface, un contrat minimum pour une classe et non comme une façon de permettre des trucs pas nets comme mélanger des objets de nature hétérogènes dans une collection ou *éviter* le recours aux génériques.

Justement le C++ est particulièrement touché parce qu'il est le langage peut-être le plus long à maitriser. Ce n'est que mon avis, je n'ai pas de preuve

Si je reprend un peu ton point, même si c'est pas exactement ce que tu disais, un code C# trouvé sur le net a certains avantages : Au niveau code il obéit à des régles de nommage très standards qui sont à 98% respectées.
De plus, il suffit pour l'examiner de cliquer sur le fichier de projet pour l'ouvrir dans l'IDE et le compiler en 2 clics.

Ce que je récupère du net en C++, comme un exemple d'utilisation d'une librairie ou quelque chose comme ça, d'ici que j'ait cela ouvert dans mon IDE et dans un état compilable, il me faudra sans doute plus de temps.

Ca s'explique surement par la foule de compilateurs existants et de librairies (hors STL) qui peuvent avoir été employées.

Pour ma part, j'ai l'impression que ce qui fait le succès d'un toolkit tel que Qt en C++, c'est justement cette homogénéité qu'il est capable d'offrir à travers ses librairies qui justement se rapproche des frameworks de base de technos tels que java et C#.

[deadalnix]

A ce que je sache, c'est plutot que ça ne paraissait pas evident jusqu'à ce que les templates soient dispo en C++ et qu'on se rende compte que des if statiques (entre autre seraient terriblement utiles...

Bien sur ! C++ est un vieux langage et il y a des erreurs de jeunesse dedans. Il est pour moi totalement clair que D n'aurait pas pu voir le jour sans le recul qu'a permis les erreurs de jeunesse de C++.

[deadalnix]

Par contre, à moins qu'il n'y ait un mécanisme qui soit en mesure d'empêcher la création de collection... d'Objects, rien n'empêchera l'utilisateur d'écrire un code proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
List!(Object) truc = new List!(Object);
truc.add(new Voiture);
truc.add(new Pomme);
 //voire
truc.add(new list!(Camion) );

Et ca, c'est un comportement qui ne permettra de s'en sortir qu'à coup de downcasting

Mais, encore une fois, je fais ce reproche de manière tout à fait générale, et je l'adresse aussi (principalement ) à des langages comme java ou C#

Java, C#, . . . ou C++ avec le void*

[Alp]

ou C++ avec le void*

Tu dois confondre avec C, ou encore le légendaire "C/C++"

Oui oui, j'ai un médicament pour lutter contre la mauvaise foi... Mais dans le fond je ne pense pas avoir tort. On a rarement recommandé l'utilisation de void* en C++

[Nogane]

Il y as quelque temps j'ai du remplacer des listes de void* par des conteneur STL dans du code professionnelle, et il y en avais beaucoup de ces ******!!
Alors j'aurais tendance a penser que void* ou Object*, quand on est c**, on est c**.
A la limite, les Object* permettront de détecter les erreurs de cast au runtime.

[Alp]

Oui, on n'aura jamais fini de blâmer ceux qui ont répandu le "C/C++"

[deadalnix]

Tu dois confondre avec C, ou encore le légendaire "C/C++"

Oui oui, j'ai un médicament pour lutter contre la mauvaise foi... Mais dans le fond je ne pense pas avoir tort. On a rarement recommandé l'utilisation de void* en C++

Tout comme faire des conteneur de Objects n'est pas conseillé en D

Voila le point que je voulais montrer : on peut faire le même genre de truc horrible que dans l'exemple en C++. Sauf que, dans un cas comme dans l'autre, il est vivement conseillé de ne pas le faire.

[Niark13]

Il y as quelque temps j'ai du remplacer des listes de void* par des conteneur STL dans du code professionnelle, et il y en avais beaucoup de ces ******!!
Alors j'aurais tendance a penser que void* ou Object*, quand on est c**, on est c**.
A la limite, les Object* permettront de détecter les erreurs de cast au runtime.

Je suis d'accord avec toi. Par contre, pour info, en D (comme en Java et en C#), les variables de classes sont des references. Donc quand tu écris Object*, tu as en fait un pointeur vers une référence vers un objet. Object suffit dans ton cas.

Le principal avantage que je trouve à D par rapport à C++, c'est que sa grammaire est simple et non ambigüe, ce qui permettrait (si le langage décolle), la création d'un écosystème d'outils d'analyse de code et d'IDE aussi puissants que ce que proposent Java et C# (qui sont plus faciles à parser que C++).

Par exemple, comme ce plugin Eclipse qui permet de débugger les templates à l'écriture : [ame="http://www.youtube.com/watch?v=rtYCFVPfx4M"]YouTube- Eclipse Descent Compile-Time Debug[/ame]

[Nee]

Personne n'a parlé de l'Objective-C ?

Sans être un spécialiste, il me semble qu'il réponds a la plupart des attentes d'un langage "moderne", tout en dérivant lui aussi naturellement du C, ce qui lui permet d'hériter d'un masse considérable de lib.

Bien sur, même s'il peut être compilé sur n'importe quelle plateforme (avec GCC), il est surtout utilisé sur Mac, qui fournit un framework complet de qualité.

Je suis curieux de savoir ce que vous pensez de ce langage, et pourquoi il est resté si marginal (il n'a même pas sa place dans le menu de developpez.com ), malgré son age.

[Invité]

Objective-C, remplaçant de C++ ?
Comment on écrit des templates en Objective-C ?

[Emmanuel Deloget]

Personne n'a parlé de l'Objective-C ?

Sans être un spécialiste, il me semble qu'il réponds a la plupart des attentes d'un langage "moderne", tout en dérivant lui aussi naturellement du C, ce qui lui permet d'hériter d'un masse considérable de lib.

Bien sur, même s'il peut être compilé sur n'importe quelle plateforme (avec GCC), il est surtout utilisé sur Mac, qui fournit un framework complet de qualité.

Je suis curieux de savoir ce que vous pensez de ce langage, et pourquoi il est resté si marginal (il n'a même pas sa place dans le menu de developpez.com ), malgré son age.

Sa syntaxe ne dérive pas naturellement du C - c'est même un langage très différent, qui n'est pas plus proche du C que ne l'est Java ou C#. J'en veux pour preuve un exemple de Hello World trouvé :

HelloWorld.h

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
#import <Foundation/Foundation.h>
 
@interface HelloWorld : NSObject {
  // no instance variables
}
 
// methods
- (void)sayHello;
 
@end

HelloWorld.m

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
#import "HelloWorld.h"
 
@implementation HelloWorld
 
- (void)sayHello
{
  NSLog(@"Hello, world, at %@", [NSCalendarDate calendarDate]);
}
 
@end

main.m

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
#import <Foundation/Foundation.h>
#import "HelloWorld.h"
 
int main (int argc, const char * argv) {
  NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
 
  // my stuff
  HelloWorld *hw = [[HelloWorld alloc] init];
  [hw autorelease];
 
  [hw sayHello];
 
  [pool release];
  return 0;
}

(Je ne fait pas référence ici à la complexité intrinsèque de l'exemple; on peut faire bien plus complexe en C ou en C++, mais bien à cette syntaxe très particulière, à base de @ et de [], qui est tout sauf intuitive).

La compatibilité entre Objective-C et C n'est pas suffisante pour avoir permis que le langage s'impose face à C++, puis Objective-C s'est retrouvé en concurrence avec des langages au moins aussi évolué (Java, puis C#) mais ayant des objectifs de portabilité nettement plus élevé. De plus, Objective-C n'est pas, à ma connaissance, standardisé - ce qui est un frein pour son utilisation.

[Niark13]

Personne n'a parlé de l'Objective-C ?

Sans être un spécialiste, il me semble qu'il réponds a la plupart des attentes d'un langage "moderne", tout en dérivant lui aussi naturellement du C, ce qui lui permet d'hériter d'un masse considérable de lib.

Bien sur, même s'il peut être compilé sur n'importe quelle plateforme (avec GCC), il est surtout utilisé sur Mac, qui fournit un framework complet de qualité.

Je suis curieux de savoir ce que vous pensez de ce langage, et pourquoi il est resté si marginal (il n'a même pas sa place dans le menu de developpez.com ), malgré son age.

Objective -C est, contrairement à C++, un sur-ensemble du C, alors que C++ est un langage à par entière. N'importe quel programme C est donc compilable par un compilateur Objective-C.
Objective-C ne rajoute que l'orienté objet à C, alors que C++ apporte beaucoup plus (surcharge de fonctions et d'opérateurs, templates, un typage plus fort...). En gros, un compilateur Objective-C peut s'implémenter avec un simple préprocesseur et un compilateur C.

La particularité d'Objective-C est qu'il a hérité son modèle objet de Smalltalk, alors que celui de C++ vient plutôt de Simula. En gros, plutôt qu'un simple vtable, Objective-C utilise un runtime qui charge les classes et dispatche les messages aux objets.
Presque tout est retardé au runtime en Objective-C, alors qu'en C++ on en fait le plus possible au moment de la compilation.

Objective-C est un langage dynamique : on peut charger des classes en mémoire et rajouter des méthodes à des classes existantes alors qu'un programme s'exécute. Par contre, un simple appel de méthode (pardon, un envoi de message ) est beaucoup plus coûteux qu'en C++. J'imagine que lorsqu'il a vu le jour au début des années 1980, ça a été un problème par rapport à la puissance des machines de l'époque.

Qui plus est, Objective-C n'est pas standardisé. C'est Apple qui, étant son principal utilisateur, fait un peu ce qu'il veut avec le langage. Il en résulte des incompatibilités entre les runtimes GNU et Apple.

[koala01]

Objective -C est, contrairement à C++, un sur-ensemble du C, alors que C++ est un langage à par entière. N'importe quel programme C est donc compilable par un compilateur Objective-C.
Objective-C ne rajoute que l'orienté objet à C, alors que C++ apporte beaucoup plus (surcharge de fonctions et d'opérateurs, templates, un typage plus fort...). En gros, un compilateur Objective-C peut s'implémenter avec un simple préprocesseur et un compilateur C.

Je vais peut être te surprendre, mais c'est le cas de la plupart des langages... à l'exception peut être de Ada...

Regarde le code de Gcc, et tu remarquera que l'ensemble de la collection est écrit en C (que ce soit pour les compilateurs fortran, C++, java ou objective-c).

D'ailleurs, c'est cela qui est bien, avec les langages dits de troisième génération: il est, virtuellement, possible d'écrire un compilateur pour un langage donné dans n'importe quel autre langage, le plus difficile (mais qui est passé depuis belle lurettes ) ayant été de passer des instructions en langage machine à l'assembleur puis de l'assembleur au premier compilateur existant

[Niark13]

Je vais peut être te surprendre, mais c'est le cas de la plupart des langages... à l'exception peut être de Ada...

Regarde le code de Gcc, et tu remarquera que l'ensemble de la collection est écrit en C (que ce soit pour les compilateurs fortran, C++, java ou objective-c).

D'ailleurs, c'est cela qui est bien, avec les langages dits de troisième génération: il est, virtuellement, possible d'écrire un compilateur pour un langage donné dans n'importe quel autre langage, le plus difficile (mais qui est passé depuis belle lurettes ) ayant été de passer des instructions en langage machine à l'assembleur puis de l'assembleur au premier compilateur existant

À la différence qu'en Java ou en Fortran, le code cible (du C) n'est pas mélangé au code code source. Si je copie/colle du code C au milieu du code Java, le compilateur va gueuler !

Tu as parfaitement raison et je me suis mal fait comprendre. Ce que j'ai voulu dire, c'est que le module Objective-C de GCC va transformer le code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
#include <stdlib.h>
long une_fonction(Classe * objet)
{
    [ objet message: parametre1 : parametre2];
    return 42 + rand();
}

en

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
#include <stdlib.h>
long une_fonction(Classe * objet)
{
    objc_msgSend(objet, "message", parametre1, parametre2);
    return 42 + rand();
}

juste une substitution avec un appel au runtime, que j'aurais pu très bien écrire moi même directement et qui aurait compilé.

De même, le code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
_Bool b = [objet toto]; // toto étant une méthode renvoyant un _Bool

Ne compilera pas si j'ai oublié de passer l'argument "-std=c99" à gcc (mon compilateur C/Objective-C), parce que le type _Bool et les commentaires à la C++ ne sont apparus qu'en C99.

La validité du code Objective-C est directement dépendante de la version de C utilisée derrière. C'est pour ça que je faisais la différence entre un compilateur complet et un préprocesseur/module de GCC.

Mais on s'éloigne du sujet, qui est le langage D, là.