Discussion :

[jblecanard]

Pour moi, le débat n'a pas lieu d'être. Etant donné le flou de la frontière entre un langage de script et pas de script (ce qui dépend du contexte comme l'explique très bien ptah35), qu'est ce que ça peut bien faire ? S'il considère C++ comme un langage de script, grand bien lui fasse. Faire cette constatation ne va pas changer grand chose à l'écosystème du langage. Quant à déclarer que les nouvelles fonctionnalités ouvrent de nouveaux usages, c'est un bel enfoncement de porte ouverte !

Au passage avant de répondre, tout langage est compilé. La compilation permet de passer d'un langage source à un langage destination. Il ne faut pas confondre compilation avec compiltation en binaire.

Si beaucoup de langages dit interprétés sont effectivement compilés, tous ne le sont pas. Exemple: un script Bash. Il sera exécuté directement, sans transformation préalable dans une autre représentation.

Moi je trouve que la distinction interprété/compilé n'est pas si mauvaise. Dans un langage dit "interprété", on n'a besoin que du code source, le logiciel qui exécute et celui qui compile ne faisant qu'un. Dans un langage "compilé", on peut exécuter le résultat de la compilation sans avoir besoin du code source, ni du compilateur. C'est une différence de taille je trouve.

[Invité]

on reste très loin ce que permettent les languages de script moderne. En python :

Code :

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

1
2
3
4
5
import sys
 
ifile, ofile = sys.argv[1:3]
lines = sorted(ofile.readlines())
ifile.write(''.join(lines))

Et vu que getline a des performances catastrophiques (googlez "c++ getline slow"), je ne serais pas étonné qu'en plus la version python ait des performances au moins égales à celle du c++.

[grunk]

Code php :

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

file_put_contents($fichier1,file_get_contents($fichier2));

Vous m'excuserez mais pour le moment je reste sur les "vrais" langages de script

Un titre un peu racoleur pour finalement dire que le C++11 c'est bien parce que c'est plus clair qu'avant ...

[Aurelien.Regat-Barrel]

Et vu que getline a des performances catastrophiques (googlez "c++ getline slow"), je ne serais pas étonné qu'en plus la version python ait des performances au moins égales à celle du c++.

Sans compter qu'il utilise std::endl qui flush donc le fichier sur disque autant de fois qu'il y a de lignes dedans.

Code php :

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

file_put_contents($fichier1,file_get_contents($fichier2));

Vous m'excuserez mais pour le moment je reste sur les "vrais" langages de script

Tu as oublié de trier tes lignes

Mais on est d'accord : C++ c'est pas ce qu'il y a de mieux pour faire des scripts.

[RaphAstronome]

Tu as oublié de trier tes lignes

Pour appuyer ses propos, Pakkanen présente un bout de code permettant de lire toutes les lignes d’un fichier pour les enregistrer dans un fichier différent (cas concret où se démarquent les langages de script).

Dans le descriptif il n'est nullement question de tri, mais dans le code si : son cahier des charges est mal formulé

[acx01b]

bonjour,

j'ai envie de rajouter qu'avec les histoires de cloud, de web, etc. ce qui manque aussi à C++ pour se comparer à javascript/python/java/.net c'est un mode "safe" où le compilateur arrive à prouver que le programme n'est pas dangereux pour celui qui l'exécutera :

--> il manque à C++ un mode où le compilateur arrive à prouver que le programme ne présente aucun risque du point de vue d'un anti-virus

notez que C++/CLI lui possède un mode safe : c'est celui où on n'écrit aucune ligne de C++, uniquement du code avec des types .NET

[pgoetz]

compilation avec optimisation –O3 proche des performances de Python VM

Etrange comparaison, n'est-t-il pas?

Comparer C++ (-O3) avec Python en terme de performance alors que tous auraient pensé que C++ eût battu Python sans coup férir.
Donc, C++ se complexifie (cf parametric template) et devient aussi "peu" performant qu'un language de script tel que Python.

[jblecanard]

Donc, C++ se complexifie (cf parametric template) et devient aussi "peu" performant qu'un language de script tel que Python.

Ca ne peut pas se juger sur un seul exemple, du reste, la fonctionnalité lente citée existe depuis longtemps et n'a aucun rapport avec les nouvelles choses introduites.

[ctxnop]

Etrange comparaison, n'est-t-il pas?

Comparer C++ (-O3) avec Python en terme de performance alors que tous auraient pensé que C++ eût battu Python sans coup férir.
Donc, C++ se complexifie (cf parametric template) et devient aussi "peu" performant qu'un language de script tel que Python.

C'est une traduction foireuse. Dans la source c'est

compile time with -O3 is roughly the same as Python VM startup and has to be done only once

Autrement dit, il compare le temps de compilation avec le temps de démarrage de la machine virtuelle utilisée par l'interpréteur Python.
Ce qui, soit dit en passant, est complètement irrelevant comme comparaison

[white_tentacle]

Autrement dit, il compare le temps de compilation avec le temps de démarrage de la machine virtuelle utilisée par l'interpréteur Python.
Ce qui, soit dit en passant, est complètement irrelevant comme comparaison

En fait, si, dans son idée, le temps d’ « exécution » du « script » c++ est égal à la somme de :
- temps de compilation (la première fois)
- temps d’exécution

Tandis que le temps d’ « exécution » du script python est égal à la somme de :
- temps de lancement de la vm python (tout le temps)
- temps d’exécution du programme.

Dans cette optique là, comparer les deux fait (un peu) sens pour dire qu’en terme de « worst case performance », c++ fait au moins aussi bien que python.

Mais ça reste quand même bof bof comme comparaison…

[jblecanard]

Oui, c'est d'autant moins malin que Python met en cache le bytecode dans un fichier .pyc pour justement éviter de recompiler à chaque fois...

[NVCfrm]

Bonsoir,

Pour moi la différence entre les langages de programmation haut niveau, c'est que certains délèguent la robustesse du code au programmeur. Pour les besoins que l'on sait, on trouvera ce type de langage plus adapté qu'un autre. D'autres dispensent le programmeur de tracasseries d'allocation mémoire, fuites..., en mettant suffisamment de fonctionnalités pour ça. Ce type de langage est également préférable dans les situations qu'on sait.
La distinction de la catégorie c/c++ de certains langages (scripts) reste cette traduction en binaire une seule fois pour toutes, avec cette manipulation bas niveau de la mémoire en direct.

Ces changements n’ont pas pour objectif de faire disparaître les langages de script, ironise Jussi Pakkanen, avant de conclure que « C++ peut désormais être utilisé dans les scénarios pour lesquels le langage n’était pas prévu à la base ».

Cet extrait ne contient-il pas substantiellement le but de l'article?
bien que connaissant peu ou rien du c++ et modestement du c je crois avoir compris ceci:
Il veut démontrer que la simplification du codage se rapproche, en terme de production pour le programmeur des langages interprétés, donc plus de robustesse garanti au programmeur.
La simplicité et clarté du code démonstratif m'incite d'ores et déjà à m’intéresser au c++, me disant qu'il est en fin de compte moins pénalisant en avantages que procure les langages interprétés.

[skypers]

Cet article m’a bien fait rire, surtout l’exemple. Le C++ n’est pas du tout adapté au scripting…

Voici le même programme, écrit en Haskell : http://lpaste.net/94404.

Il ne faut pas trop s’emporter avec C++11

[white_tentacle]

Voici le même programme, écrit en Haskell : http://lpaste.net/94404.

Certes, mais ce n’est pas avec un exemple comme ça que tu vas convaincre qu’haskell est un langage lisible.

<troll>cela dit, si c’est pour remplacer perl </troll>

[skypers]

Certes, mais ce n’est pas avec un exemple comme ça que tu vas convaincre qu’haskell est un langage lisible.

<troll>cela dit, si c’est pour remplacer perl </troll>

Dat troll.

[Freem]

Mis à part le fait qu'il n'utilise que la nouvelle syntaxe de for du standard 2011, je me pose des questions au sujet de la performance de son truc...

Utiliser un vector, donc, un tableau dynamique tout ce qu'il y a de plus bête, puis le trier ensuite avec sort, ça ne serait pas plus efficace avec un conteneur fait pour, genre... je sais pas, on veut un conteneur trié, alors, std::set, qui trie à l'insertion?

Enfin, de toute façon, même si je suis d'accord que C++11 est bien utile pour diverses raisons, il n'empêche qu'il reste des trucs chiants en C++, par exemple le fait de devoir utiliser des pointeurs dans les collections polymorphiques, au lieu de pouvoir utiliser des références.

Et s'il voulait mettre en avant le traitement du texte en C++11, il aurait peut-être dû trouver le moyen de parler des conversions int/float/double <-> string.

Attention, codes pompés de divers sites, j'ai la flemme de penser...

Pour rappel, avant, on devait faire des trucs comme ça pas sûr de tout, je n'ai jamais aimé cette façon de faire):

Code C++ :

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

1
2
3
4
5
6
7
8
 
#include <sstream>
 
int i = 5;
 std::string s;
 std::stringstream out;
 out << i;
 s = out.str();

Ou comme ça, en squattant la libc ( ce que je faisais, j'ai horreur des flux ):

Code C++ :

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
17
 
/* strtol example */
#include <stdio.h>      /* printf */
#include <stdlib.h>     /* strtol */
 
int main ()
{
  char szNumbers[] = "2001 60c0c0 -1101110100110100100000 0x6fffff";
  char * pEnd;
  long int li1, li2, li3, li4;
  li1 = strtol (szNumbers,&pEnd,10);
  li2 = strtol (pEnd,&pEnd,16);
  li3 = strtol (pEnd,&pEnd,2);
  li4 = strtol (pEnd,NULL,0);
  printf ("The decimal equivalents are: %ld, %ld, %ld and %ld.\n", li1, li2, li3, li4);
  return 0;
}

Maintenant, on à ça:

Code C++ :

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
17
18
19
20
21
22
23
24
25
26
 
// stol example
#include <iostream>   // std::cout
#include <string>     // std::string, std::stol
 
int main ()
{
  std::string str_dec = "1987520";
  std::string str_hex = "2f04e009";
  std::string str_bin = "-11101001100100111010";
  std::string str_auto = "0x7fffff";
 
  std::string::size_type sz;   // alias of size_t
 
  long li_dec = std::stol (str_dec,&sz);
  long li_hex = std::stol (str_hex,nullptr,16);
  long li_bin = std::stol (str_bin,nullptr,2);
  long li_auto = std::stol (str_auto,nullptr,0);
 
  std::cout << str_dec << ": " << li_dec << '\n';
  std::cout << str_hex << ": " << li_hex << '\n';
  std::cout << str_bin << ": " << li_bin << '\n';
  std::cout << str_auto << ": " << li_auto << '\n';
 
  return 0;
}

C'est quand même vachement mieux, pour concurrencer Java ou les langages de script, non? Même si, je me doute bien, ce n'est pas la panacée...

PS: je continue à utiliser scanf, printf et leurs petits copains, car tant qu'il me faudra passer par des stream pour lire un fichier en "pur c++" je ne serai pas satisfait.

PPS: j'ai de plus en plus l'impression que DVP fait de plus en plus dans le people version geek. Java ne mourra pas demain, même si un gland le dit. Les tablettes tactiles ne remplaceront jamais le desktop, même si c'est plus adapté pour un PDG. C++ n'est pas utilisé comme langage de script, et ça fait des années qu'on pourrait le faire, si on le voulait, et si la syntaxe était moins complexe.

[Klaim]

Encore une news bien naze.

Un truc par rapport a ce point et l'exemple:

des puissantes fonctions de manipulation de chaines ;

La manipulation de chaine...j'espere qu'il ne parle pas de textes encodes via unicode

Notez que son exemple ne marche pas correctement sous windows si les entrees ne sont pas des chaines ascii (ou Ansi je sais plus).

Peut etre que quand C++ aura de quoi traiter du texte unicode correctement, je serais d'accord pour l'utiliser a la place de quelques scripts python.

Utiliser un vector, donc, un tableau dynamique tout ce qu'il y a de plus bête, puis le trier ensuite avec sort, ça ne serait pas plus efficace avec un conteneur fait pour, genre... je sais pas, on veut un conteneur trié, alors, std::set, qui trie à l'insertion?

Cela dis le set n'a pas une memoire contigue. J'aurais aime que flat_set et flat_map (dans boost) fassent partie du standard: ce sont des vector qui agissent comme des set et map. Plus lents a l'insertion, invalident les valeurs quand elles bougent, mais carrement plus rapide a la recherche et a l'iteration.

[Mat.M]

Pour se situer dans le contexte, Pakkanen estime qu’un langage de script diffère d’un langage compilé comme C par les critères suivants :

*pas de gestion manuelle de la mémoire ;
*la syntaxe et les fonctionnalités complexes expressives peuvent être mises en œuvre en seulement quelques lignes de code ;
*des puissantes fonctions de manipulation de chaines ;
*une grande bibliothèque standard.

ce dont parle Pakkanen c'est en fait une série de lapalissades ou tautologies ;
ce sont des affirmations dont le sens est évident
Et ça n'apporte rien du tout comme mes prédécesseurs l'ont montré

[ymoreau]

Pour se situer dans le contexte, Pakkanen estime qu’un langage de script diffère d’un langage compilé comme C par les critères suivants :

• pas de gestion manuelle de la mémoire ;
• la syntaxe et les fonctionnalités complexes expressives peuvent être mises en œuvre en seulement quelques lignes de code ;
• des puissantes fonctions de manipulation de chaines ;
• une grande bibliothèque standard.

C'est quoi ces critères absurdes ?
Le 1er est aberrant : Java ne demande pas de gérer manuellement la mémoire, ça n'en fait pas un langage de script pour autant. "Sont pas malins, ils ont inventé JavaScript alors que Java c'est déjà du script"
Les 3 autres sont juste totalement subjectifs et ne caractérisent rien du tout. "Ah j'ai mis + de 5 lignes à faire ma fonctionnalité en Ruby ça n'est donc plus un langage de script"

[therwald]

Comme certains autres, je ne pense pas que la frontière soit parfaitement étanche. Le point majeur est probablement la possibilité d'exécuter directement les sources sans passer par une phase de compilation séparée (et ce indépendamment de l'existence éventuelle d'un traitement de type compilation au sein de l'interpréteur), mais à mes yeux un script est surtout caractérisé par le type d'application: une procédure.
La notion de script renvoie plutôt au déroulement d'un scénario unique, plutôt "moins complexe", plutôt "court" une fois et de bout en bout (aux arrêts sur erreur près), mais la frontière est sans doute assez subjective.
Reste que les langages fortement typés ont tendance à manquer de la souplesse généralement associée avec le développement et la maintenance des scripts.
(mais cette rigidité à mes yeux se transforme en avantage quand on développe une application plus conséquente (volume, complexité) dans la mesure où elle se transforme alors en garde-fou qui limite le risque d'erreur)