Révision – Solutions

Ce qui suit liste des solutions pour les problèmes proposés dans la série d'exercices Révision.

Q00

#include <iostream>
int main() {
   using std::cout;
   if(3)
      cout << "Vrai";
   else
      cout << "Faux";
}

#include <iostream>
int main() {
   using std::cout;
   int val = 0;
   if(val = 3)
      cout << "Vrai";
   else
      cout << "Faux";
}

Q01

Q01.0

3

int

"allo"

const char*

1.0f

float

-8

int

"A"

const char*

'A'

char

4.0

double

7L

long

L"allo"

const wchar_t*

L'A'

wchar_t

3U

unsigned int

3UL

unsigned long

0x0a

int

12.0L

long double

Q01.1

3

3

0x0a

10

0x000a

10

0xff

255 ou -1

03

3

8

8

2.7f

2 

08

Q02

Q02.0

bool full_cool(const bool*, const bool*);

Q02.1

bool full_cool(const bool *b0, const bool *b1) {
   return *b0 == *b1;
}

Q02.2

#include <iostream>
int main() {
   using namespace std;
   bool b0 = true, b1 = false; // arbitraire
   if (full_cool(&b0, &b1))
      cout << "Sont pareils... full cool!" << endl;
   else
      cout << "Sont pas pareils... full poche!" << endl;
}

Q03

Le littéral "Coucou" occupera un espace d'au moins sept bytes, soit 'C', 'o', 'u', 'c', 'o', 'u' et enfin le caractère '\0' (valeur 0 encodée sur un byte) qui délimite la fin de la chaîne. Le compilateur est responsable de cette mémoire; nous ne savons pas s'il en réservera plus pour des raisons qui lui appartiennent.

Q04

Non, car aucune allocation dynamique de mémoire n'y est faite. Le compilateur « brûle » à même le segment de données du programme les valeurs en mémoire pour les littéraux "Coucou" et "Yo", alors que le programme fait simplement pointer texte vers l'un ou l'autre de ces littéraux. Notre programme n'est pas responsable de la gestion de cette mémoire.

Q05

Oui, car il est probable que seul le premier int de tableau soit libéré – ou encore, que le tout plante royalement, dû à un comportement indéfini dans le standard. En C++, la contrepartie de l'opérateur new[] est l'opérateur delete[]. L'instruction correcte dans ce programme serait delete[] tableau;.

Cela dit, en C++, utiliser directement new et new[] est typiquement une mauvaise idée. Nous y reviendrons.

Q06

Non. Dans ce programme, t est un pointeur de caractères, pas un objet. Ainsi, l'opérateur += appliqué à ce pointeur change l'adresse vers laquelle il pointe. Ce programme pointe un peu partout en mémoire de manière absolument illégale (sauf dans de rares cas [mal]chanceux et aléatoires).

Notons aussi que même si t était une std::string plutôt qu'un const char*, la répétitive demeurerait mal écrite, ne testant pas convenablement le succès de la lecture sur le flux std::cin. Une meilleure écriture serait :

#include <iostream>
#include <string>
int main() {
   using namespace std;
   string t = "Wow";
   for (char c; cin >> c; && c != '.'; )
      t += c;
}

Cette structure teste convenablement le succès de la lecture et la condition d'arrêt; de plus, elle restreint la portée de la variable c locale à la répétitive qui s'en sert.

Q07

Ce programme est légal car t0 est un conteneur dont les éléments sont modifiables et car il n'y a pas de dépassement de capacité. Notez que t0 et t1 sont de la même taille, tous eux ayant une capacité de quatre éléments. Exprimé en termes de bytes, sizeof(t0)==sizeof(t1), et le nombre d'éléments de t0 peut être calculé à la compilation par l'expression suivante :

enum { N = sizeof(t0) / sizeof(t0[0]) };

Q08

L'expression suivante semble faire le travail demandé :

string s2 = s;

Cependant, elle ne copie pas le contenu de s dans s2; elle fait simplement pointer s2 au même endroit que s. Avec C#, comme avec Java, nous manipulons tous les objets à travers des indirections (des références, au sens de C# ou de Java). Nous n'avons pas directement accès à ces objets. Ceci pose parfois problème, car on tend alors à partager des objets entre des fonctions ou des threads; heureusement, une classe telle que string (ou String en Java) est immuable (ses instances ne peuvent être modifiées une fois construites), et par conséquent, partager ces objets est sans risque.

Q09

Non, car on ne parle que d'un déplacement de la référence d'un référé vers un autre. Dans une Personne, la propriété Nom tient à l'interne une référence qui lui est propre, est distincte de la variable s dans Main(), même si une fois p construite les deux références pointent au même endroit.

Q10

Q10.0

#include <string>
#include <iostream>
int main() {
   using namespace std;
   string texte;
   for (string s; cin >> s && s != ".";)
      texte += s;
   cout << texte << endl;
}

import java.io.*;
public class q10_0 {
   public static void main(String [] args) {
      String s = "", texte = "";
      try {
         BufferedReader br =
            new BufferedReader(
               new InputStreamReader(System.in)
            );
         s = br.readLine();
         while (!".".equals(s)) {
            texte = texte + s;
            s = br.readLine();
         }
      } catch (IOException ex) {
      }
      System.out.println(texte);
   }
}

Initialisation des variables :

• Remarquez que le code Java demande une initialisation explicite des deux String. L'écriture String s = ""; équivaut en Java à String s = new String(""); car s est alors une référence sur une String et non pas une String : en Java, on ne manipule jamais les objets directement; toutes les opérations sur des objets se font à travers des indirections
• La norme Java dit qu'une référence qui n'est pas explicitement initialisée est automatiquement initialisée à null, mais si vous souhaitez des algorithmes portables, soyez clairs dans votre écriture et ne supposez pas trop d'opérations d'initialisation implicites, qui peuvent varier d'un langage à l'autre. De toute manière, ici, la répétitive dans le bloc try utilise texte à gauche et à droite de l'affectation, alors ne pas l'initialiser serait une erreur de logique
• Les String de Java sont allouées dynamiquement, et ce même si on ne voit pas de new dans le code en exemple. Le type String a droit, en Java, à un support spécial du compilateur (opérateurs, syntaxe allégée, ce genre de truc). Comme (presque) tous les objets Java, les String sont collectées si le moteur de collecte d'ordures de la JVM le juge opportun (ici, la mémoire référencée par s et par texte ne sera probablement jamais réclamée durant l'exécution du programme, les besoins en mémoire étant trop petits)
• Dans le code C++, s et texte sont des objets, pas des indirections vers des objets. Leur constructeur est implicitement invoqué lors de leur définition, et leur destructeur est invoqué à la fin de la portée dans laquelle ils sont déclarés. Une std::string par défaut est une std::string vide

Consommation de données sur un flux :

• C++ utilise les opérateurs >> et << pour les opérations standards (en mode texte) sur les flux, et permet de spécialiser ces opérateurs sur divers types de données
• Typiquement, en C++, le type des opérandes lors des entrées/ sorties est connu à la compilation, et cette connaissance guide le choix des bonnes versions de l'opérateur << et de l'opérateur >>
• Les types servant d'abstraction standard en C++ pour les flux d'entrée et de sortie sont, respectivement, std::istream et std::ostream. Les autres flux (par exemple, ceux sur des fichiers) dérivent de ceux-ci. C'est donc en vertu d'eux que les divers types spécialisent habituellement les opérateurs d'entrée/ sortie
• De son côté, Java utilise des méthodes pour lire certaines données primitives ou du texte, de même que pour consommer des objets sérialisés : en Java, toutes les classes dérivent de Object et cette classe est le lieu où se trouve le support de base à la sérialisation. La lecture d'un objet sur un flux implique la lecture d'un Object pour consommer la forme sérialisée, lecture devant être suivie d'un transtypage (un typecast) pour obtenir une référence sur le type souhaité. Ce transtypage étant un downcast (conversion parent vers enfant), il y a un risque de levée d'exception
• L'abstraction que propose Java pour lire d'un flux suggère de construire des objets offrant des capacités de consommation sur un flux donné, et de tirer profit de cette succession de fonctionnalités ajoutées. Ici, le flux d'entrée standard (System.in) sera consommé par un objet capable de lire d'un flux d'entrée (instance de la classe InputStreamReader), qui sera ensuite utilisé par un objet capable d'entrées/ sorties tamponnées (instance de la classe BufferedReader). Ce dernier offrira un service de consommation de chaînes de caractères, une ligne à la fois (méthode readLine())
• Par défaut, les entrées/ sorties en C++ ne lèvent pas d'exceptions. Une lecture problématique sur un flux met ce flux en état d'erreur, et le flux peut être testé comme un booléen
• En Java, les erreurs de lecture sur un flux mènent à une levée d'exception. On trouve donc systématiquement des blocs try dans du code de ce genre

Gestion des chaînes de caractères :

• La principale différence entre les deux langages est que les chaînes de C++ sont modifiables alors que les chaînes (le type String, du moins) de Java sont immuables
• Cela signifie que C++ permet de modifier le texte lu avec un opérateur d'ajout à la fin (opération texte += s;) alors que Java impose de créer chaque fois une nouvelle chaîne (expression texte = texte + s; qui équivant à texte = new String(texte + s); en quelque sorte). Étant donné le modèle objet de Java, qui ne permet pas d'objets constants et qui impose une manipulation indirecte en tout temps, procéder autrement serait dangereux
• Les chaînes de caractères en Java sont souvent un goulot d'étranglement pour la performance des programmes. Si vous souhaitez de meilleurs performances en Java lors de la manipulation de chaînes de caractères, utilisez StringBuffer plutôt que String, mais cela compliquera le code alors allez-y seulement lorsque vous le juges nécessaire (métriques à l'appui)
• Remarquez l'écriture C++ s != "." en comparaison avec l'écriture Java ".".equals(s). En C++, la variable s est un objet, et operator==(const char*) const est l'opérateur invoqué ici. La comparaison est directe, non polymorphique, puisque les types sont connus pour les deux opérandes de l'opérateur et puisque cet opérateur n'est pas virtuel. En retour, en Java, l'opérateur == comparerait les références, par les objets auxquels elles réfèrent, et il faut plutôt invoquer la méthode equals()
• On écrira ".".equals(s) plutôt que s.equals(".") pour éviter le risque que s soit null. En effet, en Java, "." est la même chose (conceptuellement; il peut y avoir des optimisations sous la couverture) que new String(".") et est donc implicitement non-nul, alors que, de manière générale, c'est moins clair pour une référence quelconque comme la variable s
• De même, equals() est une méthode polymorphique de Object que les descendants de cette classe peuvent spécialiser. Le modèle de Java impose que la signature soit celle définie à même Object, donc que le paramètre soit aussi un Object. Conséquemment, à l'interne, cette méthode vérifiera que son paramètre soit bel et bien non-nul (car o.equals(null) doit être faux pour tout objet o), puis fera un transypage du paramètre en String (à partir du type d'origine qu'est Object), puis dans la mesure où tout va bien, comparera les deux opérandes un caractère à la fois, comme en C++

Q10.1

#include <string>
#include <iostream>
int main() {
   using namespace std;
   wstring s, texte;
   while (wcin >> s && s != L".")
      texte += s;
   wcout << texte << endl;
}

En C++, le type std::string est en fait un cas particulier du type générique nommé std::basic_string, instancié pour le type char. Ceci tient de raisons historiques (le langage C utilise des chaînes de caractère reposant sur des char, et sizeof(char)==1 au sens où le type char est encodé sur un byte, peu importe l'ordinateur, donc "allo" est un const char *). C et C++ supportent aussi les chaînes de caractères étendus à travers le type wchar_t. Ainsi, le littéral L'A' (préfixe L devant le littéral) est un wchar_t (caractère étendu, capacble de représenter – avec C++ 11 – ces caractères sur 16 et sur 32 bits; la représentation des caractères étendus est une question très complexe) alors que 'A' est encodé sur un seul byte. Le littéral "allo" est un const char * alors que le littéral L"allo" est un const wchar_t *. Enfin, là où le type std::string est un basic_string<char>, le type std::wstring est un basic_string<wchar_t>.

Les objets std::wcerr, std::wcin, std::wclog et std::wcout équivalent respectivement aux objets std::cerr, std::cin, std::clog et std::cout, mais pour des séquences de caractères étendus. De manière générale, tous les flux standards sont génériques sur la base du type de caractère utilisé : par exemple, il existe un std::istream et un std::wistream, les deux étant des spécialisations de std::basic_istream pour un char et pour un wchar_t, respectivement).

Q10.2

#include <iostream>
#include <algorithm>
int main() {
   using namespace std;
   if (int n; cin >> n && n > 0) {
      int *p = new int[n];
      for (int i = 0; i < n; ++i)
         cin >> p[i];
      sort(p, p + n);
      for (int i = 0; i < n; ++i)
         cout << p[i] << ' ';
      cout << endl;
      delete[] p;
   }
}

import java.io.*;
import java.util.Arrays;
public class q10_2 {
   public static void main(String [] args) {
      try {
         BufferedReader br =
            new BufferedReader(
               new InputStreamReader(
                  System.in
               )
            );
         int n = Integer.parseInt(br.readLine());
         if (n > 0) {
            int [] p = new int[n];
            for (int i = 0; i < p.length; ++i) {
               p[i] = Integer.parseInt(br.readLine());
            }
            Arrays.sort(p);
            for (int i = 0; i < p.length; ++i) {
               System.out.print(p[i] + " ");
            }
            System.out.println();
         }
      } catch (IOException ioex) {
      } catch (NumberFormatException nfex) {
      }
   }
}

Remarquez d'abord la syntaxe : en C++, un tableau (en particulier s'il est alloué dynamiquement) est un pointeur, alors qu'en Java il s'agit d'une entité spéciale (remarquez la position des crochets [] entre le type des éléments et le nom de la variable).

En Java, le tableaux sont des objets et connaissent leur taille (attribut final – sorte de constante d'instance – nommé length). Le tableau est immuable une fois instancié, comme le sont les String, mais son contenu ne l'est pas (autrement dit, on peut remplacer ses éléments, on peut faire pointer la référence ailleurs – un tableau Java est un objet, donc est manipulé indirectement; ce n'est pas tant un objet qu'une référence sur un objet – mais on ne peut pas changer sa structure, par exemple sa capacité).

Comme tous les objets du langage Java, un tableau sera réclamé par le moteur de collecte d'ordures si le moteur de la JVM juge nécessaire et pertinent de le faire. En C++, un tableau est une séquence contiguë en mémoire d'éléments du même type, sans plus, et doit être détruit explicitement (opérateur delete[]) au moment jugé opportun. Prudence, d'ailleurs : l'opérateur delete détruit un scalaire alors que l'opérateur delete[] détruit un tableau. La distinction est nécessaire du fait qu'aux yeux du compilateur, un pointeur sur le 1^er élément d'une séquence d'un type donné (ici, le pointeur p qui pointe sur une séquence de int) est du même type qu'un pointeur sur un seul élément de ce type, mais les stratégies d'allocation de mémoire peuvent différer pour l'allocation de scalaires et de tableaux.

La consommation d'entiers sur un flux se fait, dans le code Java, avec une méthode parseInt() appliquée au texte lu. Cette méthode lèvera une exception si la traduction de texte à entier pose problème. Remarquez que le code client doit expliciter le type à même le nom de la méthode de lecture; en C++, le type des opérandes de l'opérateur permet au compilateur de faire un choix éclairé, et le code source est le même peu importe le type des données consommées du flux.

Remarquez enfin la stratégie de tri de part et d'autre : en C++, l'algorithme std::sort() opère sur des itérateurs, de manière générique, alors qu'en Java, il opère strictement sur un tableau; l'algorithme y est implémenté dans une méthode statique de la classe Array.

Q10.3

#include <iostream>
#include <algorithm>
int main() {
   using namespace std;
   const int N = 5;
   int p[N];
   for (int i = 0; i < N; ++i)
      cin >> p[i];
   sort(p + 0, p + N);
   for (int i = 0; i < N; ++i)
      cout << p[i] << ' ';
   cout << endl;
}

import java.io.*;
import java.util.Arrays;
public class q10_3 {
   public static void main(String [] args) {
      final int N = 5;
      try {
         BufferedReader br =
            new BufferedReader(
               new InputStreamReader(
                  System.in
               )
            );
         int [] p = new int[N];
         for (int i = 0; i < p.length; ++i) {
            p[i] = Integer.parseInt(br.readLine());
         }
         Arrays.sort(p);
         for (int i = 0; i < p.length; ++i) {
            System.out.print(p[i] + " ");
         }
         System.out.println();
      } catch (IOException ioex) {
      } catch (NumberFormatException nfex) {
      }
   }
}

Petite note : en Java, un tableau est un objet et doit être instancié avec new (parfois en cachette, par un peu de sucre syntaxique) peu importe que sa capacité soit connue à la compilation ou non. En C++, quand la capacité du tableau est connue à la compilation, il est possible d'allouer l'espace pour ce tableau sur la pile (pour les variables locales) ou en mémoire globale. Ce n'est pas toujours une bonne idée, mais ça peut être pratique.

Q10.4

using System;
namespace q10_4
{
   public class Swapper
   {
      public static void Swap<T>(ref T a, ref T b)
      {
         T temp = a;
         a = b;
         b = temp;
      }
   }
   class Program
   {
      static void Main(string[] args)
      {
         int a = 2, b = 3;
         Console.WriteLine($"a: {a}, b: {b}");
         Swapper.Swap(ref a, ref b);
         Console.WriteLine($"a: {a}, b: {b}");
      }
   }
}

À titre de rappel, la fonction std::swap(a,b) en C++ est une fonction globale générique sur la base du type de a et b. Les deux paramètres doivent être du même type. L'algorithme std::swap() avant C++ 11 utilise des références, mais depuis l'avènement de ce standard, il utilise des rvalue references (une optimisation importante).

Le langage C# permet le passage de paramètre par référence, mais l'appelant (ici, la méthode q08_4.Program.Main()) doit expliciter cette particularité (indiquer ref a et ref b à l'appel). La méthode Swapper.Swap() peut être appliquée à des objets comme à des primitifs, mais ce qui sera échangé dans le cas des objets sera les références, pas le contenu des référés.

Notez que les classes et les espaces nommés sont obligatoires en C#. Les fonctions globales n'y sont pas supportées. Cela explique le recours à la méthode de classe Swapper.Swap() plutôt qu'à une simple fonction globale.

Q10.5

Java ne supporte pas le passage de paramètres par référence. Seul le passage par valeur y est supporté. On peut simuler un swap en Java en utilisant des classes dont les instances ne sont pas immuables, mais le langage ne permet pas d'exprimer une solution générale à ce problème.