Glorious C++ Master Race Filthy Java Peasant

Faudra que je matte, mais rien que le nom me fait un peu peur (et la syntaxe aussi a première vue ).

Les macros c'est pas sensé être la même chose a vrai dire.
En C aussi t'as des macros, peut être pas aussi puissantes qu'en Haxe, mais ça reste des macros.

Enfin je materais a l'occasion histoire d'éclaircir le truc, mais ce serait cool que ce soit aussi puissant que les templates, car c'est le genre de features qui manquent pas mal ailleurs :p

Si tu veux je t'aiderais à regarder ça, c'est tellement peu documenté que c'est pas appelé la magie noire du Haxe pour rien. Mais de ce que j'en sais, ça fais peut être même plus de choses que les templates. De ce que j'en avais parlé avec Daminetreg en tout cas. ^^

Après, je dis ça comme ça, mais coté choix judicieux de nom de feature, Haxe n'est pas au top, vois les class abstraites, qui portent bien leur nom en Haxe, mais qui ne correspondent pas du tout au communément considéré de la programmation. Et puis, les tableaux de tailles fixé, c'est des Vector, et ceux à tailles non fixé, c'est des Array, rien que là, c'est fort en syntaxolat. x)

J'ai regardé vite fait, ça a l'air bien cool, mais comme je le pensais ça a pas l'air d'être vraiment fait pour la même chose, la c'est carrément de la génération de code sans forcement partir d'une structure de base, ça me fait un peu penser a la metaprog sous lisp.

Ça a l'air d'être pas mal le bordel par contre, et la syntaxe est toujours aussi belle... >.<


Enfin bon si t'as des bouts de code a partager je dirais pas non, par exemple une classe de tuples ça peut être pas mal pour voir ce que ça donne niveau gueule :p

J'ai pas pensé à faire une classe de tuples tiens, j'essayerais à l'occasion, faudrait que je recherche un peu sur les comportements attendus des tuples de manière général, question que ça soit complet. ^^

Là le mieux que j'ai à montrer c'est un générateur de class d'event OpenFL, c'est le plus simple. Et aussi, une fonction pour générer une boucle for normale, chose qui n'existe pas en Haxe...

Pour l'OpenFLEvent, sont builder est là. Il est appellé à l'extension d'une class par OpenFLEvent. Il va t'auto compléter ta class, en passant par le clone, le toString, et le constructeur. En bref, tu as quasi pu rien à taper, juste les variables que tu veux avoir dans ton événement. (une class exemple vaut mieux que toutes mes phrases je pense)

Pour la fonction for, c'est là. Et là, ça coule de source je pense.

Mais ouai, c'est atrocement atroce à coder, je m'en sors car j'en ai l'habitude, mais je me vois pas apprendre à quelqu'un à faire ça quoi.

Edit : Pour te donner une petite idée, là par exemple quand j'ai un peu de temps, je travail sur un système pour générer du code à partir d'un fichier json, chose qui est aussi possible avec les macro en Haxe.

Ouai le côté macro j'ai compris le délire, mais justement les templates c'est pas des macros, pour ça que je demande plutôt une classe conteneur qu'une macro d'exemple.

Sinon un tuple c'est assez simple a gérer (pas forcément a coder après vu que le nombre d'éléments est variable), c'est juste une structure ou t'appelle les éléments via un nombre constant.

genre
Tuple<int, float, string> t;
get<0>(t) = 123;
get<1>(t) = 3.14;
get<2>(t) = "hello";

Puis les méthodes j'en voit qu'une la: size.


A la limite avant le tuple juste une classe Vec2 qui contiens 2 éléments d'un type template pour voir la gueule que ça aurait ce serait sympa.
De ce que j'ai compris ce serait:

Code:

class Vec2<T> {
  public var x: T;
  public var y: T;
}

Par contre j'arrive a pas a l'utiliser ensuite:

Code:

class Vec2<T> {
  public var x: T;
  public var y: T;
}

class Test
{
    static function main() {
        var t:Vec2<Int>;
        t.x = 1;
        t.y = 2;
        trace(t.x);
    }
}

Edit:
Ah ok c'est comme java faut toujours instancier en dynamique...

Code:

class Vec2<T> {
  public var x: T;
  public var y: T;
    
  public function new() {
      
  }
}

class Test
{
    static function main() {
        var t = new Vec2<Int>();
        t.x = 1;
        t.y = 2;
        trace(t.x);
        
        var u = new Vec2<Vec2<Int>>();
        u.x = new Vec2<Int>();
        u.y = new Vec2<Int>();
        u.x.y = 123;
        trace(u.x.y);
    }
}

Bon bah ça y est j'aime encore moins haxe maintenant que j'y vois un syndrome java... pfff...
Ceci dit y a de bonnes idées dans le langage au moins.

Je ne vois pas en quoi c'est un mal de devoir instancier, je trouve ça logique, et ce, même en ayant fait du C ou du C++.

C'est pas vraiment propre au Java ça d'ailleurs, on retrouve ça partout, c'est quelque chose de logique quand on y pense, on défini l'espace de mémoire, et on assigne la valeur. On est pas dans une structure ici. Car si tu utilisais une structure, ça marcherait.

Code:

typedef Vec2<T> = {
  public var x: T;
  public var y: T;
}

class Test
{
    static function main() {
        var t:Vec2<Int> = {x:1,y:2};
        trace(t.x);
       
        var u:Vec2<Vec2<Int>> = {
            x:{x:0,y:123},
            y:{x:0,y:0}
        };
        trace(u.x.y);
    }
}

Là c'est ton second exemple, avec une structure.

Justement, instancier, ça passe pas forcement par un new.
new c'est de l’instanciation dynamique, donc sur la heap.

En C++ t'as deux types d'instanciations différentes, sur la heap, et sur la stack:

Vec2<int> x; // instancié sur la pile, accès mémoire plus rapides, est détruit a la fin du scope
auto* ptr = new Vec2<int>; // instancié en dynamique, demande une allocation mémoire (plus lent) et les accès pourront être bien moins rapides

Et surtout ce que j'aime pas quand je vois ça, c'est que ça cache derrière un garbage collector, donc que tu ne gères pas la mémoire.
Et perso, j'aime pas que quelque chose gère la mémoire a ma place, car déjà tu sais pas très bien ce qui se passe derrière, pis aussi tu peux perdre beaucoup en perfs pour des raisons inutiles (en quoi j'ai besoin d'allouer cet objet sur la heap par exemple...).

Enfin, je dis pas que c'est mal, juste que perso, je déteste. Et haxe a du le faire a contrecoeur mais sans avoir vraiment le choix, vu que (presque) tous les langages vers lesquels il compile utilisent un GC.

Enfin bon j'apprendrais haxe pour la culture (et qui sait, pouvoir mieux le clacher plus tard ), et parce que y a de bonnes idées dedans, mais j'en ferait probablement jamais pour le langage en lui même.
Sur ce, dodow time :b

Je poste juste un petit message qui sert à rien.

Le C, c'est juste la vie !
Pour l'embarqué.

Au hasard, prenons pour exemple la programmation sur un Atmega328 de la petite carte bien connue, Arduino (genre 2009 ou UNO).

Option 1) De base (donc, ce que les néophytes apprendrons à utiliser) :
C++ => Code super lourd en mémoire (alors qu'on à déjà pas des masses de place sur µContrôleur)
Bibliothèques Arduino => Truc mal pensé et lent à souhait.

Résultat :
Ton petit projet simple marche bien et à été développé vite, hourra !
Pi tu te dit que tu va passer sur Raspberry pie pour piloter un écran et un servo-moteur parce que quand même, ça rame un peu et que t'as pas assez de mémoire...


Option 2) Le barbu :
Assembleur => Code super léger et performant. Mais imbitable, surtout si tu connait pas la datasheet mieux que ta poche.

Résultat :
Ouais, je génère de la vidéo couleur et j'émule un synthé 4 voix en soft, et il me reste de la mémoire pourquoi ?
Hein ? Modifier le jeu ? Ha bha faut tout re-coder, j'ai déplié mes boucles pour gagner en perf, et je met du coup à jour mes variables pendant le rendu...
(non, j'invente rien : https://www.youtube.com/watch?v=nGIujZiEu_o)

Option 3) L'ingénieur qui doit carrer son code dans la puce, mais qui n'a les moyens ni temporels, ni financier d'apprendre par coeur la datasheet d'une puce parmis plusieur qu'il va utiliser :

C => Code plutôt léger et performant.
Bibliothèques maison => Prends du temps mais réutilisée plus tard.
Bibliothèque d'internet => Prends de la place mais libère du temps.

Résultat :
Oui, j'aurais pu échantillonner mon signal analogique deux fois plus vite et le filtrer en soft en plus. Mais je vais déjà plus vite que ce que l'on me demande, et le code est fini avec seulement un jour de retard !
Comment ça le cahier des charges !? Mais vous me l'aviez pas envoyé bougre d'âne ! J'ai du tout trouver par moi même !


Bref, on ne devrai ni apprendre l'option 1, ni l'option 2.
Mais pas non plus l'option 3.
On devrait toute les apprendres, et choisir celle qui convient à l'usage que l'on veut en faire.

On veut tester vite fait un capteur SPI qui sauves ses données dans fichiers d'une carte mémoire lisible sur le PC ?
=> Option 1

On à le proto fonctionnel de validé, et la première fournée de carte fonctionne, les clients en redemandent ? On va recoder pour utiliser une puce plus petite sur une carte en 10 millions d'exemplaire.
=> Option 2

On est dans une petite boite, et le client veut un truc pour la veille avec des options de ouf ? Ha oui, en plus du boulot habituel ? (mais sur une plate forme conune)
=> Option 3


Bref, vous pouvez être d'accord avec moi ou non, mais c'est ma façon de voir les choses...

Quand au java, j'aime pas.
Il est indéniable qu'en théorie, tu fourre le code sur PC, téléphone ou grille pain, et ça marche. Mais en pratique, outre le fait que la portabilité est pas aussi transparente, le jeu n'en vaut pas la chandelle pour moi.

Une interface graphique pour PC ? Bha pas de C dans ce cas (j'en fait hein, avec GTK, mais c'est pas adapté).


Vous savez ce qui est pire que Java ?
Proton Basic pour micro-contrôleurs...

En effet, Haxe a un GC, et à regret de ce que j'en sais, après, c'est aussi une question qui divise comme souvent. Et je comprend la problématique du garbage collector aussi. Mais de ce que j'en sais, c'est qu'ils font bien attention à son code, pour qu'il soit performant. Déjà eu 2 màj d'opti ce mois-ci par exemple.

Mais c'est regrettable donc, l'absence de cette feature, faudrait que je vois si ce n'est pas possible par des fonction du package cpp peut-être. Parfois on trouve des choses sympa du genre, comme la gestion de processus.

Je ne savais pas en tout cas pour cette distinction, bon à savoir, merci. (j'apprends le C++ quand j'ai un peu de temps en ce moment, donc je n'ai pas encore vu tant de chose que ça)

[TheDarkTiger]>
Ouai mais justement ça c'est un truc que j'ai pas compris, on dit que C++ est plus lourd que C, mais selon comment tu codes, y a pas de raisons particulières que ce soit le cas oO

Enfin c'est comme tout quoi, si tu sais ce que tu fais ce sera léger. Mais oui de suite utiliser toutes les conneries de streams bien lourds de la lib standard C++, pour de l'embarqué, c'est vraiment pas une bonne idée.
Après si t'utilises les constexpr et templates pour faire du compile time, ce ne sera que bénéfique vu que tu généreras un meilleur binaire.


Enfin bon je dis ça car étonnamment je vois cela crié fort un peu partout, même Linus en parlait, mais perso je vois pas de raison de dénigrer le C++ pour l'embarqué (surtout que tu peux définir toi même tes allocateurs, et que t'as quand même accès a de sacré outils supplémentaires au niveau du langage en lui même).

A moins qu'un code identique compilé avec gcc ou g++ donne un binaire différent et qu'y ai des ajouts (je vois vraiment pas ce qu'il pourrait y avoir) supplémentaires dans le binaire du programme c++?
Ça me surprendrait vraiment.

Chlorodatafile a écrit:

En effet, Haxe a un GC, et à regret de ce que j'en sais, après, c'est aussi une question qui divise comme souvent. Et je comprend la problématique du garbage collector aussi. Mais de ce que j'en sais, c'est qu'ils font bien attention à son code, pour qu'il soit performant. Déjà eu 2 màj d'opti ce mois-ci par exemple.

Mais c'est regrettable donc, l'absence de cette feature, faudrait que je vois si ce n'est pas possible par des fonction du package cpp peut-être. Parfois on trouve des choses sympa du genre, comme la gestion de processus.

Je ne savais pas en tout cas pour cette distinction, bon à savoir, merci. (j'apprends le C++ quand j'ai un peu de temps en ce moment, donc je n'ai pas encore vu tant de chose que ça)

Comme j'ai dit au dessus pour le GC ils avaient pas vraiment le choix, si Haxe doit export vers un langage qui fonctionne de cette façon, il peut pas vraiment se permettre de fonctionner différemment.

Du coup c'est dommage pour certaines personnes qui préfèrent gérer la mémoire eux même, mais j'imagine que dans le lot y en a quand même moins que ceux qui préfèrent avoir un GC ready to use.

_oni > En effet, les user du Haxe sont majoritairement des gens ciblant vers JS, Flash ou HTML5, ce qui est un des regrets de beaucoup d'ailleurs, car les autres langages en sont limites délaissé, même si ça commence à changer, le preuve étant les débugage massif de la compile cpp qu'on a pu avoir ses derniers temps.

onilink_ a écrit:

[TheDarkTiger]>
Ouai mais justement ça c'est un truc que j'ai pas compris, on dit que C++ est plus lourd que C, mais selon comment tu codes, y a pas de raisons particulières que ce soit le cas oO
[...]

Bha, comme tout bon débat :

1) Je ne maitrise pas les concepts aussi avancé du C++ (en gros, je m'arrête à la surcharge et aux objets)
2) Je n'ai as fait de tests quantitatifs sur de l'embarqué.

*Lance GCC*

Alors, sur PC :
En C :

Spoiler:

Exe : 48ko

En C++ :

Spoiler:

Exe : 67ko

Aucune optimisations.

*Lance les optis*

-Os :
C : 68ko (ce troll !)
C++ : 67ko

-O2 :
C : 68ko (O.ô)
C++ : 67ko

-Oo
C : 67ko (even more trolling XD)
C++ : 67ko

Bon, ok, un Hello word, ça n'est pas représentatif du tout.

Mais, ça prouve quand même que si différence il y a, au final, ça doit pas être tant que ça.

Et si du coup le C++ apporte des fonctionalités utilisables en embarqué, bha, pourquoi pas tester alors.

Mais pas comme c'est fait pour la bibliothèque Arduino en tout cas !

Bref, à tester tout ça, ça m'intrigue...

Non mais justement, iostream par ex est une biblio super lourde, je parlais d'utiliser surtout la lib C couplé a quelques concepts très interessants de C++11.

Genre les unique_ptr, qui permettent d'avoir des pointeurs "rigoureux" (ils se libèrent tout seuls a la fin du scopes sauf si tu les move ailleurs, et ils ne sont pas copiables, comme ça t'es sur que la ressource est a un seul endroit a la fois).
=> Totalement zero overhead a la compilation en O3

Les constexpr, qui permettent de dire au compilo de calculer les ce qui peut l'être a la compilation, bien utilisé ça peut permettre de virer beaucoup de calculs inutiles.
=> Allège le binaire et réduit les calculs

Les structures de base sans utiliser le polymorphisme, ça ajoute quand même la possibilité d'avoir un constructeur, un destructeur et des methodes, c'est quand même plus sympa.
=> Et surtout c'est pas plus lourd que se faire ***** a le faire soit même en C tant que tu fous pas de methodes virtuelles

Algorithm et les iterators, qui permettent d'utiliser des algos complexes facilement, sans être spécialement lourds.
=> Bon par contre ça faut savoir ce que tu fais car tout ce qui est template peut quand même alourdir le binaire (vu que ça peut dupliquer le code)

Les enum class, qui permettent de choisir le type des éléments d'une enum, et qui sont fortement typés.
=> Ça peut alléger une enum dans pas mal de cas, si tu choisis un char par exemple pour les éléments de la structure.

Puis bon en C++ t'as toute une nouvelle rigueur au niveau des pointeurs, et des casts, ou le compilo te dis quand même de faire gaffe et de spécifier ce que tu fais (cast statique, réinterprétation des données...).

Bref jsuis d'accord que foutre ça dans les mains d'un mec qui se soucie pas trop de ce qu'il utilise, c'est pas une bonne idée, mais C++ a quand même des concepts géniaux et quand t'y est habitué, c'est vraiment dommage de s'en priver surtout sous pretexte que ça pourrait être "plus lourd" (ce qui est totalement faux si tu n'utilises juste pas les concepts lourds).

En tout cas si un jour tu veux voir en live le binaire de ce que tu codes en C++ afin d'analyser les features lourdes:
https://gcc.godbolt.org/

Et si t'aimes pas l'asm, il y a bien mieux (mais pas en online a ce que je sache), c'est clang.
Tu compiles en IR LLVM, et ça te génère un asm (spécifique a LLVM) super haut niveau et super clair.
Et ça te permet de comprendre très facilement comment chaque feature est codé.
Et justement t'en a pas mal qui sont toutes connes, genre constructeur/destructeur c'est juste des fonction appelées automatiquement sur une structure :p (donc tout aussi léger que le faire manuellement en C).

Bin, je regarderais ça quand j'aurais un peu de temps.

Mais c'est vrai que je suis une feignasse, et que changer de langage (juste pour tester hein, je jette pas mon C), bin, j'ésuite...

Bah l’intérêt quand t'es un codeur C, c'est que tu peux continuer de faire du C sous un compilo C++, juste que ça vire certaines restrictions
(mais ça peut faire bizarre aussi car les casts sont moins souples niveau warnings)

Perso j'ai malheureusement trop longtemps codé façon C en "mode C++" x)

onilink_ a écrit:

Bah l’intérêt quand t'es un codeur C, c'est que tu peux continuer de faire du C sous un compilo C++, juste que ça vire certaines restrictions
(mais ça peut faire bizarre aussi car les casts sont moins souples niveau warnings)

Perso j'ai malheureusement trop longtemps codé façon C en "mode C++" x)

Genre mettre tous les headers en .h au lieu de .hpp, hmmm j'ai pris le pli du coup

Hein? x)

Ben il me semble que les sources en c++ c'est .cpp et les headers c'est .hpp, or moi je mets tous mes sources en .cpp et tous mes headers en .h

Mass a écrit:

Ben il me semble que les sources en c++ c'est .cpp et les headers c'est .hpp, or moi je mets tous mes sources en .cpp et tous mes headers en .h

Fallait pas apprendre à coder sur le Site du Zéro.

J'ai appris à la dure avec la onidev

Huhu, bah en récapitulatif vu que t'as déjà eu ta réponse sur l'irc, #include fonctionne comme le include du php, il prend juste le contenu du fichier spécifié et le colle la ou appelé. Du coup tu peux bien l’appeler jean.jaq ça marchera tout aussi bien que .h ou .hpp.

J'dis ça, j'dis rien, mais nous en Haxe, on a l'Unreal maintenant.

Unreal est écris en C++ ... et l'api native aussi du coup.
Et ils ont ouvert les sources d'ailleurs maintenant.
Du coup unreal tu peux l'avoir dans tous les langages imaginables (mais l'api sera jamais aussi complete/efficace que la native).

Oui, forcément, mais bon, des gens l'ont porté en Haxe, ce qui est plutôt cool. ^^

Tout ce qui finis 'open' finis porté partout, limite même sous calculatrice huhu x)

onilink_ a écrit:

Tout ce qui finis 'open' finis porté partout, limite même sous calculatrice huhu x)

Pas limite. DOOM existe sur ma calculette (mais que si j’installe un firmware custom, ce que j’ai la flemme de faire).

Ahah sont fous les mecs