Le topic de la programmation: Et envoyez des sioux!

**TwinBis** · 04/04/2020, 18h49

Même pour les grosses boîtes (en tous cas les quelques unes que je connais), les certifs ne servent pas à grand chose.

Quand je lis un CV (et j'en lis des paquets), j'ignore complètement les certifs.

**Teocali** · 04/04/2020, 21h47

Aprs je parlais de la certif spring côté parce que la formation officielle associée est vraiment bonne (et Zenika sont les seules à la faire en français), mais c’est vrai que la certif de base ne me sert pas. a mon avis, ça ne commence à te servir qu’à partir du moment où tu en alignes suffisamment pour sorti du lot.

**William Vaurien** · 06/04/2020, 12h32

J'ai eu droit à la formation (5j) pour la certif officielle Oracle Java EE en 2016. C'était horrible.
C'était du pur bourrage de crâne, la formatrice suivait un plan millimétré duquel elle n'a pas dévié d'une seule seconde, il n'y a aucune place pour de la réflexion ou de la discussion. Le pire c'était que le support de cours était daté et pas du tout à jour par rapport aux versions plus récente de l'époque.
Un peu les boules de passer une demi-journée à apprendre un truc plus ou moins obsolète...

**deathdigger** · 06/04/2020, 13h39

C'est comme ça pour toutes les certif US.

**deathdigger** · 06/04/2020, 13h54

En ce moment, je suis en train de bosser sur la modification de fichiers Excel via OpenDocument.
J'arrive à faire ce que je veux, sauf que j'ai un décalage dans mes colonnes. J'essaie dans tous les sens en changeant les données et autres, mais ça ne veut toujours pas, il commence à me remplir le fichier à partir de la troisième colonne.
Au bout de deux heures de prise de tête, je me suis rendu compte que les deux premières colonnes du fichier étaient réduites à une largeur de 0

**Teocali** · 06/04/2020, 13h59

Envoyé par deathdigger

C'est comme ça pour toutes les certif US.

Euuuh, non.

Comme dit plus haut, formation certifiante spring core officielle, a jour des derniers version avec un formateur au top, qui adapte la formation aux envies et besoin des gens présents (tout en restant dans le cadre d’icelle oeuf corse).

Donc je pense que ça dépend

**Deizama** · 07/04/2020, 01h19

Bonjour les canards !

Je ne sais pas si je poste au bon endroit mais je tente quand même... Par contre je suis pas très doué, merci de pas trop vous moquer.

Donc, il y a quelque jour pour aider un ami et par simple envie, j'ai eu l'idée de créer un bot discord (développé en javascript donc), assez simple mais allant chercher dans une base MYSQL hébergé en ligne. Je vous épargne les détails mais j'ai eu beaucoup de mal déjà à comprendre le fonctionnement de NODE.js. J'arrive à le faire fonctionner sans soucis désormais malgré des péripéties extraordinaires.

Mais c'est qu'ensuite qu'encore plus de problèmes arrivent. Ce bot, il faut bien l'héberger et j'ai cherché des moyens, des solutions... Et ça devient très vite galère. Une solution serait de laisser toujours mon PC allumé ou bien d'avoir un serveur VPS à ce que j'ai compris, je suis très novice dans le domaine. J'ai essayé la seconde option sur un site dont je vais censurer le nom. Il contient une adresse IPV6 et je peux changer le nom d'hôte. Par contre, j'ai beau tenté de 10000 manières via FTP d'envoyer des fichiers via cette adresse IPV6, je n'y arrive pas. Le support n'a que comme réponse : "votre FAI ne supporte pas l'IPV6, vous pouvez passer par un VPN ou bien upgrader votre option pour passer en IPV4."

Bref, je n'ai pas de solutions, qu'importe ce que je tente, je me frotte à un mur et maintenant que j'ai commencé à payer l'abonnement je m'obstine.

Le serveur VPS a comme OS debian et j'ai l'impression de ne pas avoir d'internet sortant (je ne peux pas faire de apt-get) alors que c'est censé être un serveur et donc détaché de mon adresse IP. Il y a des choses que je ne comprends pas et j'ai l'impression de me faire rouler.

Est-ce que l'adresse IPV6 a bien quelque chose à voir dans l'histoire ? Est-ce commun d'héberger une solution javascript en ligne et quels sont les meilleurs options pour faire ça ?

J'aimerais bien qu'un canard m'aide, ne serait-ce qu'en me montrant de la documentation sur ce genre de problème ou si possible qu'il ait la patience de voir avec moi le problème et potentiellement une solution.

Je vous remercie en tout cas de la patience pour avoir lu tout ça, pour la réponse et pour supporter mon inexpérience.

**deathdigger** · 07/04/2020, 10h36

Tu dois avoir une adresse IPv4 sur ton serveur en plus de l'IPv6, non ?
Sinon, tu dois avoir moyen d'avoir une IPv6 avec ton FAI. De ce que je sais, c'est possible avec Free et avec SFR par exemple.

**Getz** · 07/04/2020, 10h57

Pour ton problème particulier je ne sais pas trop ce qu'il en est, je ne m'y connais pas trop en réseau.

Mais pour héberger une app node.js simple (parce que si j'ai bien compris ta base mysql est déjà hébergée quelque part?), je serais plutôt parti vers une solution comme now de zeit plutôt que de taper l'installation d'un vps.
Après, si tu dois héberger la base, ça ne fera pas l'affaire, ou il faudra l'héberger ailleurs.

**Deizama** · 07/04/2020, 11h44

Merci de vos deux réponses.

Alors, Red SFR n'a pas d'IPV6 et l'offre "bas prix" du VPS n'a qu'un IPV6, on peut dire que sur le coup je me suis fait avoir...

Pour Zeit je ne connais pas du tout, je vais me renseigner. J'ai l'avantage d'avoir la base de donnée sur une autre plateforme que le VPS, donc c'est une solution envisageable. Ca ne va pas mettre en ligne l'application de manière régulière non ? Un bot Discord a besoin d'être en permanence en ligne, je ne sais pas si ça pourrait correspondre, mais je me renseigne.

En tout cas encore merci.

**deathdigger** · 07/04/2020, 12h13

Apparemment si, tu peux activer l'IPv6 sur ta box de ce que j'en lis sur internet.
Sur ma box SFR, c'est dans Réseau v6>WAN

**William Vaurien** · 07/04/2020, 12h14

Bon alors il y a deux ans nous avions décidé un collégue et moi, de revoir l'architecture de communication entre nos applis (vieux truc en C, batch en Java, service web en SOAP/java, client web en Java). Nous avons jeté les bases d'un socle de service REST et avons faits moults réunions et autres points d'avancement, et recruté 2 personnes... J'ai réussi à coller un client http et une lib json dans le C, toute la pile technique fonctionne nickel. C'est l'euphorie.

Au final mes collègues ont décidés que c'était plus simple de faire des échanges avec la base de données partagée par toutes ces applis...
Donc un "appel REST" est en fait un déclencheur qui va entrainer de la lecture ou de l'écriture dans un table. Le paramètre des requêtes est généralement un simple id permettant d'aller lire ou écrire des trucs en base, soit dans une table foure-tout à base de blob, soit dans des tables connues par l'appelant et le serveur.

Comment dire ?

**TwinBis** · 07/04/2020, 12h40

*pat pat*

**deathdigger** · 07/04/2020, 13h40

Toute façon, les mecs font de la résistance depuis le début, tu n'en tireras rien. S'ils ne sont pas capables de s'adapter, faudra soit que tu les vires, soit que tu te barres.

**William Vaurien** · 07/04/2020, 14h22

Alors je ne suis pas le chef, donc je ne vais pas les virer. L'autre collègue est mon chef par contre. Ils sont capable de s'adapter, mais c'est plutôt le "pragmatisme" qui l'emporte. Mais ça fait chier d'y être presque arrivé. Il reste quelques vrai bout de REST dans des services, mais la direction prise n'est pas vraiment la bonne, en tout cas pour moi. Et le gain à court terme (pas la peine de se faire suer avec des DTO et du mapping, il suffit d'envoyer un id) est très certainement un boulet (de plus) pour plus tard.

**Nilsou** · 08/04/2020, 13h05

Dites, question pragmatique, désolé d'arriver au milieu d'une discussion

Est-ce que c'est une bonne pratique, en C++, d'utiliser du std:vector à toute les sauces.

Genre, un truc comme ça :

Code:

const std::vector<const char*> validationLayers = 
{
"BLABLA"
 };

me parait, personnellement, WTF, déclarer un vector pour une simple chaine de caractère constante, c'est pas un peu user d'une machine de guerre pour de petites choses ? Et en plus on doit forcement, enfin j'imagine, y perdre quelques part...
Ce n'est pas la première fois que je vois ce genre d'appel en C++, et là je suis dans une doc tout ce qu'il y a de plus officielle en plus ...

Je fais du C habituellement, désolé si la question peut paraitre triviale.

**FB74** · 08/04/2020, 13h43

Je ne fais pas de C++, mais peut-être que ça prend une réservation mémoire importante ?

**TarteAuxFleurs** · 08/04/2020, 13h54

Envoyé par Nilsou

Dites, question pragmatique, désolé d'arriver au milieu d'une discussion

Est-ce que c'est une bonne pratique, en C++, d'utiliser du std:vector à toute les sauces.

Genre, un truc comme ça :

Code:

const std::vector<const char*> validationLayers = 
{
"BLABLA"
 };

me parait, personnellement, WTF, déclarer un vector pour une simple chaine de caractère constante, c'est pas un peu user d'une machine de guerre pour de petites choses ? Et en plus on doit forcement, enfin j'imagine, y perdre quelques part...
Ce n'est pas la première fois que je vois ce genre d'appel en C++, et là je suis dans une doc tout ce qu'il y a de plus officielle en plus ...

Je fais du C habituellement, désolé si la question peut paraitre triviale.

C'est pas une chaîne de caractères constantes mais un vecteur de chaînes de caractères, qui est lui même constant, non (je ne suis pas hyper au point sur la sémantique du const en C++, ça date un peu) ?

Pour moi c'est pas choquant tant qu'il n'y a pas de problème de perf. Et un vecteur c'est comme un tableau, c'est du O(1) pour la lecture. En terme de coût mémoire tu as à peine plus aussi (un entier pour la taille allouée, un entier pour la taille utilisée).

**Cwningen** · 08/04/2020, 15h30

std::vector, c'est bien, c'est simple, c'est performant, c'est vraiment le conteneur à utiliser par défaut si tu ne cherches pas d’optimisation particulière (et même après réflexion ça reste souvent la bonne solution).

Si tu veux te passer de l'allocation dynamique utilise std::array.

**Nilsou** · 08/04/2020, 23h21

Hum, perso je viens du C et j'ai encore du mal à me passer du simple const char* . Je trouve qu'on en fait des tonnes en C++ pour parfois pas grand chose.

Ici le mec utilise du std::vector tout le temps et pour tout, perso je trouve ça illisible à force dans le code...

. Surtout que mine de rien ça fait recourir à de l'alloc dynamique là ou ce n'est pas utile dans bien des cas. J'ai l'impression que ça pousse à prendre de mauvaises habitudes à la longue ...

Je peut me tromper après.

**Cwningen** · 09/04/2020, 00h48

Tout est "bloated" quand tu compares au C. Mais std::vector n'est pas un remplaçant de const char *, c'est plutôt std::string_view qui fait ça. Et là on peut débattre : faut-il mieux mémoriser la taille de chaîne ou rechercher un caractère spécial à la fin à chaque fois ?

**Anonyme20240202** · 09/04/2020, 15h04

C++ est très rarement bloated si utilisé correctement, la plupart du temps y'a une abstraction 0 cost.

Comme d'hab le point le plus important c'est: qu'est ce que tu veux faire?

C'est une construction qu'on voit souvent pour stocker du binaire le truc que t'as posté. Le mieux c'est d'utiliser std string selon l'usage je dirais.

Sinon strictement parlant dans le cas que tu présentes le plus optimisé c'est ça:

Code:

#include <array>

int main() {
    constexpr std::array<const char*, 5> data {
        "valeur 1",
        "2",
        "Nilsou",
        "est",
        "un weeb"
    };
}

Si tu compiles ça, c'est littéralement 0 cost:

Assembleur:

Code:

main:
        xor     eax, eax
        ret

Mais du coup tu ne peux plus modifier la structure derrière.

Autre exemple commun pour gérer du binaire

Code:

std::string download_buffer;
download_buffer.append(raw_data); // t'ajoute des chunks à ton buffer quand tu veux

// T'écris le bordel dans un fichier
auto output_file = std::ofstream(mon_fichier, std::ios::out | std::ios::binary);
output_file.write(download_buffer.data(), download_buffer.size());

Et un dernier qu'on retrouve souvent:

Code:

std::vector<unsigned char> bytes;
socket.send(bytes.data())

Aussi parfois utilisé directement avec un smart pointer pour contenir un buffer brut (rarement utile je dirais?)

C++14 et au delà seulement:

Code:

auto testData = std::make_unique<unsigned char[]>(5000);

- - - Updated - - -

Là strictement parlant:

Code:

const std::vector<const char*> validationLayers = 
{
"BLABLA"
 };

Ca veut dire: j'ai une structure de donnée dynamique, donc amené à être modifié.

Donc check à faire: est elle vraiment modifiée? Si non c'est peut-être une "erreur", dans ce cas il vaudrait mieux utiliser l'array de l'exempe au dessus.

(Sachant qu'en C++20 on aura les vector constexpr donc là on pourra faire ça sans allocation dynamique.)

Ensuite const char* c'est correct, pourquoi pas mais vu que y'a une list d'initialisation ça laisserait entendre que l'ensemble est une structure statique donc là faudrait aussi aller vers l'array constexpr.

**Nilsou** · 12/04/2020, 19h39

Envoyé par Cwningen

Tout est "bloated" quand tu compares au C. Mais std::vector n'est pas un remplaçant de const char *, c'est plutôt std::string_view qui fait ça. Et là on peut débattre : faut-il mieux mémoriser la taille de chaîne ou rechercher un caractère spécial à la fin à chaque fois ?

Pour des chaines constantes il n'y a pas trop de débat si ?

- - - Mise à jour - - -

Envoyé par Kamikaze

Ensuite const char* c'est correct, pourquoi pas mais vu que y'a une list d'initialisation ça laisserait entendre que l'ensemble est une structure statique donc là faudrait aussi aller vers l'array constexpr.

Oui c'est vrai que constexpr c'est plus sympa, je n'ai pas l'habitude de l'utiliser. std::array j'avoue que quand je n'ai pas besoin d'autres chose que son « data » ça me parait peu intéressant d'employer les expressions dispos. Néanmoins pourquoi pas.

**Cwningen** · 13/04/2020, 02h44

Envoyé par Nilsou

Pour des chaines constantes il n'y a pas trop de débat si ?

Justement std::string_view ne référence que des chaînes constantes. La différence c'est que const char * ne donne que le début de la chaine, pour trouver la fin il faut chercher un caractère nul. std::string_view mémorise la taille, ça prend un peu plus de mémoire mais pas besoin de calculer la taille à chaque fois. Mais les algos sur les chaines C ont été tellement optimisé que je ne suis pas sûr que ce soit si grave.

Envoyé par Nilsou

Oui c'est vrai que constexpr c'est plus sympa, je n'ai pas l'habitude de l'utiliser. std::array j'avoue que quand je n'ai pas besoin d'autres chose que son « data » ça me parait peu intéressant d'employer les expressions dispos. Néanmoins pourquoi pas.

Il n'y a aucun surcoût entre les tableaux façon C et std::array, c'est exactement la même chose une fois compilé. std::array est un type plus strict (conversion explicite en pointeur avec data(), alors que c'est automatique pour les tableaux). C'est aussi un peu plus pratique d'obtenir la taille (appel à size() au lieu de sizeof(a)/sizeof(a[0]), mais tu as sûrement déjà une macro qui le fait).

**FB74** · 13/04/2020, 20h10

Humble Book Bundle: Artificial Intelligence & Machine Learning

3 paliers.

**Nilsou** · 13/04/2020, 23h15

Envoyé par Cwningen

Justement std::string_view ne référence que des chaînes constantes. La différence c'est que const char * ne donne que le début de la chaine, pour trouver la fin il faut chercher un caractère nul. std::string_view mémorise la taille, ça prend un peu plus de mémoire mais pas besoin de calculer la taille à chaque fois. Mais les algos sur les chaines C ont été tellement optimisé que je ne suis pas sûr que ce soit si grave.

Hum, dans mon labo on faisait plutôt le compteur incrémenté à chaque fois, ça parait plus cohérent que de mettre des tests supplémentaire dans les boucles for ... même si je ne suis pas certains que ça change grand chose...

Envoyé par Cwningen

Il n'y a aucun surcoût entre les tableaux façon C et std::array, c'est exactement la même chose une fois compilé. std::array est un type plus strict (conversion explicite en pointeur avec data(), alors que c'est automatique pour les tableaux). C'est aussi un peu plus pratique d'obtenir la taille (appel à size() au lieu de sizeof(a)/sizeof(a[0]), mais tu as sûrement déjà une macro qui le fait).

Aucun surcout (en mémoire du moins) en effet d'après : https://www.modernescpp.com/index.ph...mory-no-thanks (contrairement à vector)

Je suis assez surpris, je me serais attendu a au moins un petit surcout pour la taille de array ou pour stoquer end et begin ... c'est implémenté comment ?

**Cwningen** · 14/04/2020, 00h45

La taille de std::array est stocké dans le type (c'est un paramètre du template). begin et end sont tout simplement &a[0] et &a[N] comme pour le tableau à l'ancienne.

**Nilsou** · 14/04/2020, 00h59

Ha ok, ça veut dire que les appelle à size, sur les arrays, sont en réalité remplacés par le pre-compilo ?
Si c'est le cas c'est effectivement élégant.

**vectra** · 14/04/2020, 01h05

On est d'accord que le code dont tu parles est dans un bottleneck de ton programme?

Sinon la meilleure manière est encore de regarder la tronche du code assembleur. D'ailleurs, il faut que j'installe un serveur godbolt en local pour faire ça sous Clion: des idées, quelqu'un?

**Nilsou** · 14/04/2020, 01h21

Envoyé par vectra

On est d'accord que le code dont tu parles est dans un bottleneck de ton programme?

Pas pour le moment, mais je me remet au C++ alors j'aimerais éviter les mauvaise pratique quand c'est possible, d’où ma question.

------------------------------------------------

Bon sinon j'avais demandé des conseils openGL vs Vulkan sur ce topic (vu que je connaissais déjà OpenGL 3 & 4 mais que Vulkan c'est le futur) et j'ai commencé l'apprentissage de Vulkan au final.
Pour le moment je pense le résumer par :

Spoiler Alert!

C'est incroyablement verbeux. Ça fait plusieurs JOURS que je suis sur l'initialisation (qui se fait en quelques lignes même sous OpenGl 4).

Par contre je suis obligé d'admettre que l'objectif de clarté est accompli, comme tout est littéral on comprends ce qu'on fait parfaitement. N’empêche que je n'aurais pas pensé un jour CODER des trucs comme le double buffering

C'est cool de voir les entrailles exposées des trucs qu'on ne trifouille pas habituellement, mais ils sont vraiment allé loinnnnnnnnnn dans la démarche.

Discussion: Le topic de la programmation: Et envoyez des sioux!

Outils de la discussion

Règles de messages