Discussion :

[djm44]

Je pense c'est malhonnête de produire un code défaillant en langage C pour ensuite déplorer son prétendu
manque de sécurité. Pour ma part je pars du principe que c'est le programmeurs qui fait des erreurs pas le
langage. Le langage C est très bien mais il demande à être plus attentif . De plus c'est un langage simple comparé
à Rust qui à mon avis a une syntaxe beaucoup plus lourde. Pour moi l'intérêt de passer à Rust depuis le C s'apparente
à une mode. Mais en fin ce qui compte c'est la réalisation du programme peu importe le langage.

Il existe encore une autre mode c'est le passage de Objective-C à Swift sur Mac. Ce genre de nouveauté ne change rien
à la complexité de l'environnement Cocoa du Mac. Objective-C est très souple il intègre du C et du C++. Swift fait
maintenant de même. Comme quoi on se débarrasse pas si facilement que cela du langage C .

[Jamatronic]

Le C c'est beau. C++ et Rust de mon point de vue sont déjà des langages d'assistés. Je vois souvent les fans de C++ ou du Rust comme ils voient parfois les fans de Java

[Freem]

Je me rappelle de la sortie de C++11, avec lequel on nous montrait des exemples C++ moderne embarqué meilleurs que le C : exécutable, code source, …
Mais les versions sortent C++14, C++17, … mais il me semble que le C++ embarqué on n'en parle plus beaucoup

Soit on cause, soit on fait des réunions, soit on code, faut choisir.

J'ai déjà fait du baremetal en C++. Comme pour le C, tant qu'on fait du baremetal, on peut s'asseoir sur les fonctions standard qui reposent sur un OS, c'est à dire malloc et free (ou plutôt, en utiliser des versions spécialisées).
C++ a toujours permis a ma connaissance de désactiver les exceptions et la RTTI pour ce type de cadre, justement. Ca permets des binaires moins gros, évidemment utile en embarqué baremetal.
Evidemment, on ne peux plus utiliser les conteneurs standards, du coup, vu qu'ils imposent l'usage des exceptions (stupidement, selon moi, mais bon, c'était la mode dans les 90s et 00s, le tout-objet... étrangement on en reviens) mais il existe pas mal d'alternatives... Je ne serais pas surpris par exemple que EASTL soit plus adaptée au cas de l'embarqué baremetal que la STL, elle permet à priori (jamais utilisé moi-même) un contrôle plus facile de la mémoire, justement. Au pire, le conteneur le plus utile, std::vector, est trivial a réimplémenter sans exceptions, je fait ça moi-même ne serait-ce que pour pouvoir debug plus confortablement: débugguer un truc lié à la STL est pénible, a cause de tous les niveaux d'indirection et des optimisations des compilateurs qui ne sont pas désactivées par défaut même en debug... je me demande bien qui est le génie qui a eu cette idée, tiens...

Oh, et pour utiliser la RAII sans être contraint aux exceptions, c'est facile (bien qu'un peu verbeux, certes), il suffit de sortir des clous qu'on vous impose à l'école:

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
17
18
19
20
21
22
23
24
25
26
27
28
29
30
 
class foobar_t
{
 int* m_ptr = nullptr; //pour l'exemple
public:
  foobar_t( void ) = default;
 
  foobar_t( foobar_t const& ) noexcept = delete;
  foobar_t& operator=( foobar_t const& ) noexcept = delete;
 
  foobar_t( foobar_t && ) noexcept = default;
  foobar_t& operator=( foobar_t && ) noexcept = default;
 
  static init( int val )
  {
    foobar_t ret;
    ret.m_ptr = new (std::no_throw) int( val );
    return ret;
  }
 
  ~foobar_t( void )
  {
    delete m_ptr;
  }
 
  bool valid( void ) const
  {
    return m_ptr != nullptr;
  }
};

Ce bout de code simple et naïf permets d'instancier foobar_t sans jamais lancer d'exception, tout en garantissant que la destruction sera effectuée correctement (j'ai utilisé la mémoire ici parce que c'est emblématique, mais ça marche sur d'autres trucs, bien entendu).
Bon, j'ai pas testé, j'ai pondu ça en rache mode a 7H du mat en ayant mal dormi, c'est probablement pas parfait, mais l'idée est la: utiliser l'idiome des named constructors. J'avoue que j'aimerai pouvoir réduire le sucre syntaxique de tous ces constructeurs, mais bon, d'un autre côté, ça prend 30s a écrire et on est pépère après. Je sais qu'un dev doit être faignasse, mais on va pas non plus exagérer trop... sinon autant utiliser et python et s'étonner quand une merde tombe.