Salut, je possède un tableau de deux dimension X et Y, que je veux le séparer sur plusieurs tableaux, toute en évitant l'utilisation des boucles, donc l'idée est de crée des pointeurs sur chaque portion du tableau puis d'assigner un tableau pour chaque pointeur, la première étape est facile mais la deuxième semble impossible, je ne sais pas comment je peux créer un tableau à partir d'un pointeur

Int16* P1 = &T[0, 0];
Int16* P2 = P1 + Y;
Int16* P3 = P1 + 2*Y;
Int16* P4 = P1 + 3*Y;
...

Int16[] T1 = P1;
Int16[] T2 = P2;
...

Bon je sais que ça marche pas c'est juste pour illustrer mon but, est-ce possible de faire un truc pareil en c# ?

Ok, maintenant vous reprenez votre "algorithme" en sachant que les objets .NET sur le tas changent souvent d'emplacement mémoire, aux grès des compactages mémoires, le trouvez-vous toujours aussi "pertinent" ?

Ce que vous donnez comme "algorithme" est une solution "tactique" classique en C mais rarement pertinent en programmation objet, et encore moins en .NET.

Pour vous conseillez une solution "meilleure", il faudrait que sache quel est votre besoin final réel ?

Parce que des vues partielles sur de données, en POO, c'est pas les moyens qui manquent : structures de données plus adaptées, fonctions "accesseur" dédié, etc...

bacelar a écrit:

Ok, maintenant vous reprenez votre "algorithme" en sachant que les objets .NET sur le tas changent souvent d'emplacement mémoire, aux grès des compactages mémoires, le trouvez-vous toujours aussi "pertinent" ?

Ce que vous donnez comme "algorithme" est une solution "tactique" classique en C mais rarement pertinent en programmation objet, et encore moins en .NET.

Pour vous conseillez une solution "meilleure", il faudrait que sache quel est votre besoin final réel ?

Parce que des vues partielles sur de données, en POO, c'est pas les moyens qui manquent : structures de données plus adaptées, fonctions "accesseur" dédié, etc...

Merci pour votre réponse et je m'excuse pour le retard, j'ai créé un program qui lit et affiche les données de plusieurs capteurs en temps réel, l'affichage se fait en utilisant un "DataViewGrid" et plusieurs "Chart" simultanément, depuis longtemps j'essaye d'optimiser le truc car il bouffe toutes les ressources d'un Core et malgré ça il est toujours lent, et puis d'un ordinateur à un autre les performances ne sont pas les mêmes.

Bref pour faire le scrolling d'un seul Chart, je dois toujours décaler le tableau qui contient les valeurs en temps réel à gauche, remplacer la dernière case par la nouvelle valeur et remettre le tout dans le Chart, toute en sachant que la taille du tableau est de 100 (int16) et que je possède 9 Charts.

Donc je me suis dit au lieu de refaire toujours ce décalage je pourrais peut-être simuler un autre tableau qui commence par la case suivante du tableau originale et que je lui rajoute seulement la nouvelle valeur sans faire tout le décalage.

>Donc je me suis dit

C'est, pour moi, la source du problème.

Vous avez une vue bien trop "candide" de comment fonctionne en bas niveau votre application (petite expérience en hardware donnant un effet Dunning-Kruger ou une vue "fantasmée" du hardware ? (blittering 2D, shader, etc...)).

Si vous avez des problèmes de performance sur une application "qui fonctionne", utilisez un profiler pour voir où ça pêche. Et renseignez-vous un peu sur comment ça fonctionne "en vrai", dans votre cas précis d'utilisation et comment les autres optimisent dans ce cas précis de perte de performance, donc pas de règles généralistes "à la noix" sur des "on dit".

Je vais donc faire un truc que je réprouve, donner 'une règle généralistes "à la noix"', mais pour vous faire pensez hors de votre cadre "étriqué" de penser (no offense). Votre besoin est tellement "courant" que des composants "chart" qui optimisent votre type d'utilisation, ça doit être une condition sine qua none, donc, vous êtes vous renseigné sur les possibilités "intrinsèques" de vos contrôles "Charts" sur le scrolling "real time" ?

J'ai un peu le sentiment d'être en face de la situation du proverbe "quand on a qu'un marteau, tous les problèmes ressemblent à des clous" (marteau de Maslow).

-
Edité par bacelar 10 mai 2021 à 9:03:48

Si le marteau représente ma capacité à résoudre un polynôme de premier degré alors je réduirai tout le reste à une simple forme canonique.

Bon c'est vrai que je n'ai pas assez d'expérience en c# mais je sens que les problèmes que je rencontre en utilisant ce language sont uniques, je suis conscient qu'il n'y a pas une règle générale mais c'est hyper difficile de trouver des informations quand il s'agit de créer une application qui interagie avec un composant externe comme un microcontrôleur, et les outils disponible sur Visual Studio ne me semble pas trop optimiser pour faire ce genre d'application, donc j'ai décidé d'éliminer les couches non nécessaire du c# et de m'approcher plus de hardware, comme ça je gagnerai en vitesse.

>et de m'approcher plus de hardware, comme ça je gagnerai en vitesse.

Ca, c'est du bon gros bullshit et encore plus quand on voit que vous n'êtes vraiment pas à jour sur comment fonctionne un ordinateur "moderne".

Les outils de "haut niveau" sont là pour vous épargnez de connaitre si finement comment fonctionne un ordinateur mais si vous voulez jouer les gros barbus, faut assumer et maîtriser un peu la bête (et pas celle de 1983 d'IBM, hein, une typique des années 2020 avec shader, DMA, hiérarchie de cache et tout le toutim).

>les problèmes que je rencontre en utilisant ce language sont uniques

Pouvez-vous être plus précis, SVP ?

Ce que je vois moi, c'est que l'unicité de votre problème, c'est que vous voulez appliquer de vieilles recettes des années 70 ou du petit embarqué dans un environnement où elles n'ont plus lieu d'être.

>créer une application qui interagie avec un composant externe comme un microcontrôleur

Heu, c'est quoi votre canal de communication ??? Parce que, franchement, c'est pas ça qui manque, normalement.

On peut même mettre .NET sur les microcontrôleurs :

https://www.nanoframework.net/

etc...

Que ce n'est pas le cas le plus fréquent, c'est une chose, mais les ressources pour communiquer avec un µ-contrôleur, elles sont fonction du type du canal de communication.

Et j'ai du mal à voir le rapport avec vos problèmes d'affichage de "Charts".

Si vous n'avez pas besoin des services .NET (garbage-collection, virtualisation du hardware, etc...), pourquoi avez-vous besoin de vous prendre la tête avec ? Du C ou du C++ feront aussi bien, non ?

Avant de vouloir appliquer d’hypothétiques solutions à un problème "putativement" attribué aux "services" de .NET, je vous le répète, utilisez un profiler pour localiser votre goulot d'étranglement des performances.

Il existe aussi le C++/CLI pour faire un bridge entre le contrôle "fin" des années 80 (non managé) et .NET.

Le plus simple, montrez-nous votre code (via GitHub/GitLab si c'est long) qu'on puisse voir où vous avez "déconné".