Le topic de la programmation: Et envoyez des sioux!

**FB74** · 29/09/2019, 12h50

Bon... je ne peux plus suivre ce topic.
Avast me signale 2 virus à chaque fois que je viens ici.

Je pense que c'est la signature d'un posteur.

Après, virus réel ou faux positif...

**gros_bidule** · 29/09/2019, 13h27

Tu peux choisir de masquer les signatures ;-)

**vectra** · 30/09/2019, 15h38

Envoyé par war-p

Ah ouais, je vois qui c'est... Le mec fait du go

Sinon, j'irai certainement au meetup sur rust le 4 octobre, il y aura Steeve klabnik.

Inscrit!
J'étais pas sûr de pouvoir viendre, mais en fait si.

**vectra** · 30/09/2019, 18h02

J'ai une petite question. J'ai encore l'impression d'inventer la std::roue en C++17...

Je veux pouvoir faire ce truc tout con:

auto [x, y, z] = mymeta::splitArray3(m_volume -> GetDimensions());

pour déclarer x, y, z en variables int qui vont récupérer la taille du volume, qui nous est tout le temps retournée comme un tableau de 3 ints.
On a également des tailles de pixels en double*, etc: vive VTK.

J'ai donc fait çà, tout bêtement:

template <typename T>
std::tuple<T, T, T>
splitArray3(T* array)
{
MSG_ASSERT(array != nullptr , "null array to split");
return std::make_tuple(array[0], array[1], array[2]);
}

Avant de partir sur une éventuelle version variadique qui s'annoncerait prise de tête (genre pour gérer (x,y) sur une image voire (r,g,b,a), etc), je me demande si j'ai pas simplement raté un mécanisme déjà prévu pour quelque chose qui semble bateau à mort

**Cwningen** · 30/09/2019, 18h55

Depuis un pointeur, je suis pas très inspiré. J'ai pensé à std::span (c++20 donc pas une bonne réponse de toute façon), mais en fait on ne peut pas en construire de taille fixe à partir d'un pointeur.

La question que je me pose maintenant c'est : en pratique, qu'est ce qui peut arriver de mal avec un reinterpret_cast<T(&)[N]>(array) ?

GCC n'est pas fan :

Code:

warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
    9 |     auto [x, y, z] = reinterpret_cast<int(&)[3]>(array_ptr);
      |                                                  ^~~~~~~~~

Edit: apparemment, c'est parce que le cast correct est reinterpret_cast<T(&)[N]>(*array), ou "ce qui pointé par array est un tableau de N Ts", ce qui est plus logique en fait, alors que j'essayais de faire un array-to-pointer à l'envers.

**war-p** · 02/10/2019, 10h40

Envoyé par vectra

Inscrit!
J'étais pas sûr de pouvoir viendre, mais en fait si.

Si je me suis pas viandé dans l'inscription, j'y serai en principe.

**vectra** · 03/10/2019, 22h12

Cool

Si tu vois un vieux au milieu des jeunes qui dit que Lisp c'était mieux, cherche pas qui c'est...

**war-p** · 04/10/2019, 18h14

Je viens en moto ( donc blouson cuir) avec un sweat rouge si jamais

**vectra** · 04/10/2019, 19h25

Chemise blanche en ce qui me concerne...
On est presque à côté en fait

**Teocali** · 07/10/2019, 10h17

Oï les gens

Bon, j'ai mon client qui a besoin d'un renfort ASAP, pour une durée de 2 a 3 mois. Il est donc près a mettre le pognon pour prendre un freelance supplémentaire pour cette période. Alors ouais, je sais c'est court, mais bon, ça reste une petite start up, avec le gros avantage que le dev se fera en télétravail.

C'est une application REST écrite en Java/Kotlin. L'objectif étant a terme de faire disparaitre le Java, le dev se fera en Kotlin. Elle est basé sur une stack classique Spring Boot/Hibernate/Postgresql, avec Gradle en système de build. La boite est située sur Marseille, mais on cherche un freelance sur Lyon, Grenoble ou Valence. En effet, le dev se fera en télétravail, mais l'objectif est de pouvoir se voir en face a face au moins une (idéalement deux) fois par semaine, et ce sont les trois villes qui sont le plus accessible pour ma pomme

Au niveau des connaissance avec expérience indispensables :
- Java
- Spring (MVC et Rest)
- Hibernate
- Git
- REST

- Connaissance gros plus (pas forcément besoin d'XP dessus, mais au moins avoir lu la doc et fait un ou deux exos/tutorial):
- Kotlin
- Spring Boot
- Spring Data
- Flyway
- Gradle

Docn voila, si vous pensez être intéressé, ou que vous connaissez quelqu'un qui pourrait l'être, ma boite a PM est ouverte.

EDIT : J'ai oublié de le préciser, mais on cherche quelqu'un d'un minimum experimenté. 5 ans mini, je dirais, mais ça reste ouvert a discussion. Ce qui est clair, c'est qu'on ne peut pas prendre quelqu'un dont ça serait la première expérience professionnelle

**FB74** · 07/10/2019, 20h24

Quelques ouvrages en Bundle:
https://www.humblebundle.com/books/c...learning-books

**vectra** · 07/10/2019, 21h16

Merci

**vectra** · 25/10/2019, 17h41

Je crois qu'on en avait déjà parlé, mais ça ne me dit plus rien.

Je cherche un moyen propre de factoriser deux membres d'une classe qui ont cette forme:

Code:

void
class::memberForward()
{
 // long header
 <specific Forward part>
 // long footer
}

void
class::memberBackward()
{
 // long header
 <specific Backward part>
 // long footer
}

**Cwningen** · 25/10/2019, 22h55

Une fonction d'ordre supérieur ?

Code:

template <typename Function>
void doSomething(Function f) {
    // long header
    f();
    // long footer
}

Ou du RAII (un objet qui fait "long header" dans son constructeur et "long footer" dans son destructeur) ?

**Anonyme20240202** · 26/10/2019, 11h26

Y'a plein de moyens de faire ça mais pas sûr d'avoir compris la factorisation que tu recherches. C++ ?

Deux versions (la deuxième c'est ce que Cwningen propose, la première c'est juste header et footer factorisés dans leur propre fonction):

Code:

#include <functional>
#include <iostream>

static void longHeader() {
    std::cout << "long header" << std::endl;
}
static void longFooter() {
    std::cout << "long header" << std::endl;
}

class MyClass {
  public:
    static void memberForward();
    static void memberBackward();
};

void MyClass::memberForward() {
    longHeader();
    std::cout << "<specific Forward part>" << std::endl;
    longFooter();
}

void MyClass::memberBackward() {
    longHeader();
    std::cout << "<specific Backward part>" << std::endl;
    longFooter();
}

class WrappedCall {
  public:
    static void wrapMyCall(const std::function<void()>& injected) {
        longHeader();
        injected();
        longFooter();
    }
};

int main() {
    MyClass::memberForward();
    std::cout << std::endl;

    MyClass::memberBackward();
    std::cout << std::endl;

    WrappedCall::wrapMyCall([]{
        std::cout << "Hey" << std::endl;
    });
}

Sinon (3ème version) tu peux injecter une interface:

Code:

#include <functional>
#include <iostream>
#include <memory>

static void longHeader() {
    std::cout << "long header" << std::endl;
}
static void longFooter() {
    std::cout << "long header" << std::endl;
}

class Interface {
  public:
    virtual void Do() = 0;
};

class Forward : public Interface {
  public:
    void Do() override {
        std::cout << "Forward" << std::endl;
    }
};

class Backward : public Interface {
  public:
    void Do() override {
        std::cout << "Backward" << std::endl;
    }
};

class WrappedCall {
  public:
    static void wrapMyCall(const std::shared_ptr<Interface>& interface) {
        longHeader();
        interface->Do();
        longFooter();
    }
};

int main() {
    auto forward = std::make_shared<Forward>();
    auto backward = std::make_shared<Backward>();

    WrappedCall::wrapMyCall(forward);
    std::cout << std::endl;

    WrappedCall::wrapMyCall(backward);
}

**Cwningen** · 26/10/2019, 11h52

C'est moche les interfaces pour un rien façon Java. En C++, on fait mieux avec des pointeurs de fonctions, functors or lambdas.

Aussi le pointeur partagé est inutile, et WrappedCall::wrapMyCall devrait prendre un (const?) Interface &. On ne passe une référence vers le pointeur partagé que si on veut le copier.

**Anonyme20240202** · 26/10/2019, 12h04

static void wrapMyCall(const std::shared_ptr<Interface>& interface)

Je prends bien un const non?

Si j'ai mis un shared ptr c'est simplement pour être très générique pour l'exemple, j'aurais pu utiliser un raw pointer ou n'importe quoi d'autre, référence, static polymorphism avec template, std::variant, etc. etc. Je peux pas savoir ce qu'il veut, la sémantique et l'idée reste la même quelque soit la mécanique d'injection utilisée

- - - Mise à jour - - -

Code:

#include <functional>
#include <iostream>
#include <memory>

static void longHeader() {
    std::cout << "long header" << std::endl;
}
static void longFooter() {
    std::cout << "long header" << std::endl;
}

class Interface {
  public:
    virtual void Do() const = 0;
};

class Forward : public Interface {
  public:
    void Do() const override {
        std::cout << "Forward" << std::endl;
    }
};

class Backward : public Interface {
  public:
    void Do() const override {
        std::cout << "Backward" << std::endl;
    }
};

class WrappedCall {
  public:
    static void wrapMyCall(const Interface& interface) {
        longHeader();
        interface.Do();
        longFooter();
    }
};

int main() {
    Forward forward;
    Backward backward;

    WrappedCall::wrapMyCall(forward);
    std::cout << std::endl;

    WrappedCall::wrapMyCall(backward);
}

**Cwningen** · 26/10/2019, 16h36

Envoyé par Kamikaze

Si j'ai mis un shared ptr c'est simplement pour être très générique pour l'exemple, j'aurais pu utiliser un raw pointer ou n'importe quoi d'autre, référence, static polymorphism avec template, std::variant, etc. etc. Je peux pas savoir ce qu'il veut, la sémantique et l'idée reste la même quelque soit la mécanique d'injection utilisée

Justement, la référence marche avec tout. Alors que si tu mets un shared_ptr dans l'interface (alors que tu ne t'en sers pas), tu forces l'utilisateur à en créer un.

Le const, ce n'était pas contre toi, le point d'interrogation est là car dans certains cas où on pourrait vouloir des objets fonctions mutables (mais ce n'est pas très pratique si ce n'est pas un template).

**Anonyme20240202** · 26/10/2019, 17h03

Hmmm, le problème de la réference c'est que si l'objet référencé sort du scope, tu manipules désormais une référence vide. Chaque implémentation a son avantage. Je pense pas que y'ait d'équivalence stricte dans celles que j'ai mentionnées. En tout cas en C++

Code:

#include <functional>
#include <iostream>
#include <memory>
#include <thread>

static void longHeader() {
    std::cout << "long header" << std::endl;
}
static void longFooter() {
    std::cout << "long header" << std::endl;
}

class Interface {
  public:
    virtual void Do() const = 0;
};

class Forward : public Interface {
  public:
    void Do() const override {
        std::cout << data << std::endl;
    }
    ~Forward() {
        data = "Destroyed";
    }
  private:
    std::string data = "Forward";
};

class Backward : public Interface {
  public:
    void Do() const override {
        std::cout << "Backward" << std::endl;
    }
};

class WrappedCall {
  public:
    static void wrapMyCall(const Interface& interface) {
        longHeader();
        interface.Do();
        longFooter();
    }
};

int main() {
    using namespace std::chrono_literals;

    Backward backward;

    std::thread delayedCallforward;
    {
        Forward forward;
        delayedCallforward = std::thread([&] {
            std::this_thread::sleep_for(1s);
            WrappedCall::wrapMyCall(forward); // BIG TROUBLES AHEAD
            std::cout << std::endl;
        });
    }

    WrappedCall::wrapMyCall(backward);
    delayedCallforward.join();
}

- - - Mise à jour - - -

Output

Code:

long header
Backward
long header
long header
Destroyed
long header

Un shared_ptr a "l'intelligence" de ne pas appeler le destructeur tant que l'objet est consommé par quelqu'un dans ce cas. S'pour ça que je le trouve "plus générique" en tant que réponse universelle a cette question assez vague/généraliste.

Bien sûr un shared_ptr est plus couteux, sous-entend a priori/en général qu'on manipule des objets (données + méthodes, constructeur, destructeur), etc. etc.

**Cwningen** · 26/10/2019, 17h07

Dans ce cas tu passes le shared_ptr par valeur. La référence vers le shared_ptr peut tout autant devenir invalide.

**Anonyme20240202** · 26/10/2019, 17h40

Ouais c'était un mauvais exemple de ma part pour ce point, mais bon on part un peu loin là. Je voulais surtout répondre que y'a pas vraiment d'équivalence stricte entre les 2. Mais sinon je suis d'accord, rien ne sert d'utiliser la sémantique de pointeurs si ce n'est pas nécessaire.

Smart pointer hors du scope

Code:

#include <functional>
#include <iostream>
#include <memory>
#include <thread>
#include <utility>

static void longHeader() {
    std::cout << "long header" << std::endl;
}
static void longFooter() {
    std::cout << "long footer" << std::endl;
}

class Interface {
  public:
    virtual void Do() const = 0;
};

class Forward : public Interface {
  public:
    void Do() const override {
        std::cout << data << std::endl;
    }
    ~Forward() {
        data = "Destroyed";
    }
  private:
    std::string data = "Forward";
};

class Backward : public Interface {
  public:
    void Do() const override {
        std::cout << "Backward" << std::endl;
    }
};

class WrappedCall {
  public:
    explicit WrappedCall(std::shared_ptr<Interface> interface) : interface(std::move(interface)) {
    }

    void wrapMyCall() {
        longHeader();
        interface->Do();
        longFooter();
    }
  private:
    std::shared_ptr<Interface> interface;
};

int main() {
    using namespace std::chrono_literals;

    std::unique_ptr<WrappedCall> wrapped_call;
    std::thread delayedCallforward;
    {
        auto forward = std::make_shared<Forward>();
        wrapped_call = std::make_unique<WrappedCall>(forward);
        delayedCallforward = std::thread([&] {
            std::this_thread::sleep_for(1s);
            wrapped_call->wrapMyCall();
            std::cout << std::endl;
        });
    }
    delayedCallforward.join();
}

Output

Code:

long header
Forward
long footer

Référence hors du scope

Code:

#include <functional>
#include <iostream>
#include <memory>
#include <thread>
#include <utility>

static void longHeader() {
    std::cout << "long header" << std::endl;
}
static void longFooter() {
    std::cout << "long footer" << std::endl;
}

class Interface {
  public:
    virtual void Do() const = 0;
};

class Forward : public Interface {
  public:
    void Do() const override {
        std::cout << data << std::endl;
    }
    ~Forward() {
        data = "Destroyed";
    }
  private:
    std::string data = "Forward";
};

class Backward : public Interface {
  public:
    void Do() const override {
        std::cout << "Backward" << std::endl;
    }
};

class WrappedCall {
  public:
    explicit WrappedCall(Interface& interface) : interface(interface) {
    }

    void wrapMyCall() {
        longHeader();
        interface.Do();
        longFooter();
    }
  private:
    Interface& interface;
};

int main() {
    using namespace std::chrono_literals;

    std::unique_ptr<WrappedCall> wrapped_call;
    std::thread delayedCallforward;
    {
        Forward forward;
        wrapped_call = std::make_unique<WrappedCall>(forward);
        delayedCallforward = std::thread([&] {
            std::this_thread::sleep_for(1s);
            wrapped_call->wrapMyCall(); // Erreur de la part du développeur? A priori sa responsabilité de ne pas utiliser un objet qui sort du scope
            std::cout << std::endl;
        });
    }
    delayedCallforward.join();
}

Output

Code:

long header
Destroyed
long footer

Après clairement cet exemple me parait un peu trop forcé, en l'occurrence, et je dois bien dire que finalement en terme de choix "général" je pense que tu as raison et que la majorité du temps on n'utilisera un référence.

https://github.com/isocpp/CppCoreGui...-smartptrparam
https://github.com/isocpp/CppCoreGui...-is-part-owner
https://github.com/isocpp/CppCoreGui...shared-pointer

**Anonyme20240202** · 26/10/2019, 17h56

Et une dernière courte référence qui mentionne explicitement ce cas

https://docs.microsoft.com/en-us/vis...8?view=vs-2019

**Cwningen** · 26/10/2019, 18h02

Code:

    {
        auto forward = std::make_shared<Forward>();
        wrapped_call = std::make_unique<WrappedCall>(forward);
        delayedCallforward = std::thread([&] {
            std::this_thread::sleep_for(1s);
            wrapped_call->wrapMyCall();
            std::cout << std::endl;
        });
    }
    delayedCallforward.join();

~~On est d'accord que la référence wrapped_call n'est peut être plus valide quand le thread l'utilise ?~~ Ah, non c'est déclaré plus tôt.

**deathdigger** · 31/10/2019, 08h20

Microsoft ayant définitivement tiré un trait sur tout ce qui est embarqué (c'était à prévoir, vu que ça n'avait pas évolué depuis le .Net 3.5), va falloir que je passe sur Android/Kotlin très rapidement. Vous avez des bons bouquins/des bonnes ressources là-dessus ?

Quelqu'un a testé les cours de Pluralsight dessus ? En .Net, ils étaient top, mais aucune idée de ce qu'ils valent pour cette techno.

**TwinBis** · 31/10/2019, 09h07

Comme souvent de nos jours, la doc officielle est très bien, avec un playground, la description d'idiomes, etc.

Il y a "Kotlin in action", écrit par des gens de Jetbrains qui est pas mal même si un peu verbeux.

Et abonne toi à la newsletter Kotlin weekly, quelques articles intéressants chaque semaine:
http://www.kotlinweekly.net/

**vectra** · 31/10/2019, 09h32

Envoyé par Kamikaze

Et une dernière courte référence qui mentionne explicitement ce cas

https://docs.microsoft.com/en-us/vis...8?view=vs-2019

Envoyé par Cwningen

~~On est d'accord que la référence wrapped_call n'est peut être plus valide quand le thread l'utilise ?~~ Ah, non c'est déclaré plus tôt.

Merci pour vos conseils, c'était très instructif

**Nilct** · 31/10/2019, 10h16

Udacity (https://www.udacity.com/courses/all?keyword=kotlin) propose des cours gratuits (les payants sont à plus de 1000e mais très complets avec la possibilité de faire un portfolio sympathique).

**deathdigger** · 31/10/2019, 10h44

Envoyé par TwinBis

Comme souvent de nos jours, la doc officielle est très bien, avec un playground, la description d'idiomes, etc.

Il y a "Kotlin in action", écrit par des gens de Jetbrains qui est pas mal même si un peu verbeux.

Et abonne toi à la newsletter Kotlin weekly, quelques articles intéressants chaque semaine:
http://www.kotlinweekly.net/

Je vais regarder ça, merci

Envoyé par Nilct

Udacity (https://www.udacity.com/courses/all?keyword=kotlin) propose des cours gratuits (les payants sont à plus de 1000e mais très complets avec la possibilité de faire un portfolio sympathique).

Ça a l'air pas mal, mais quand ils disent 2 mois pour se former, c'est trop long pour moi

**Nilct** · 31/10/2019, 12h35

Tu peux le faire en un WE, c'est à ton rythme. Et tu as accès à tout le programme.

Quand c'est payant, c'est beaucoup de travail et donc de temps nécessaire... mais tu as l'avantage de faire des projets et d'avoir un mentor qui évalue tes productions.

**vectra** · 05/11/2019, 11h33

On m'a envoyé une offre de job CUDA en Bretagne via une SSII je pense.
Si ça intéresse des gens, me contacter. Y'a peu de profils dispo on dirait...

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

Outils de la discussion

Règles de messages