Comment supprimer un élément d'un tableau (unidimensionnel bidimensionnel) ? - page 7

 
Ilya Malev:


Tâche : retirer un élément d'un tableau.

 
Алексей Тарабанов:

Tâche : retirer un élément d'un tableau.

Unidimensionnel ou bidimensionnel. Les tâches ont des réponses différentes parce que vous ne ferez pas le même code pour les deux. Ou plutôt vous pouvez le faire, mais vous ne pourrez pas l'appeler sans connaître au préalable le nombre de mesures dans le tableau. Puisque vous n'êtes pas un programmeur, à en juger par vos paroles, je vous suggère de le prendre sur la foi...

 
Dmitry Fedoseev:
Les tableaux ne peuvent pas avoir plus de 4 dimensions ici. Ainsi, vous pouvez écrire 4 fonctions différentes et c'est tout.

Ne pouvez-vous pas en construire une en 8 dimensions ?

 
Ilya Malev:

Si l'on considère le problème sous cet angle, les tableaux multidimensionnels ne devraient pas être déclarés du tout - il faudrait plutôt utiliser des tableaux de structures avec différents champs. Mais la question est différente : que pouvons-nous faire avec un tableau de dimension arbitraire (inconnu à l'avance) qui existe déjà en tant que donnée ?

Vous êtes donc dans l'impasse :( . Pourquoi n'aimez-vous pas la variante avec plusieurs fonctions ?
 
Aliaksandr Hryshyn:
Comment ne pas apprécier l'option de fonctions multiples ?

En devant dupliquer le même code (celui dont vous parlez), dans des fonctions avec des noms différents pour chaque dimension du tableau de paramètres.

 
Dmitry Fedoseev:
Les tableaux n'ont pas plus de 4 dimensions ici. Ainsi, vous pouvez écrire 4 fonctions différentes et c'est tout.

Le problème n'est pas d'écrire 4 fonctions, mais de ne pas pouvoir en utiliser une pour n'importe quel tableau, comme c'est le cas pour tous les autres types. Par conséquent, il vaut mieux éviter d'utiliser des tableaux multidimensionnels (type intégré []) dans µl.

 
Алексей Тарабанов:

Vous ne pouvez pas en faire un en 8 dimensions ?

Les structures sont faciles à utiliser.

 
d'ailleurs, typename, disponible au moment de la compilation, ne dira pas seulement le nombre de mesures, mais même le fait que le paramètre est un tableau. bien que cela puisse être compris par sizeof==52. mais encore une fois, cela ne dira rien sur le nombre de mesures. donc je ne vois pas non plus de solution pratique via #define. À moins que l'ensemble du code de la fonction, qui n'utilise que des appels intégrés tels que ArrayCopy et ArrayResize, auxquels différentes dimensions de tableaux peuvent être transmises, ne puisse être poussé dans define
 
Dmitry Fedoseev:

Eh, et la surcharge ne le sauve pas :

Est-ce que ça compile comme ça ?

void z(int & z[],int shift){}; 
void z(int size_second_dimension,int & z[][],int shift){};
Je ne me souviens pas exactement, mais il semble que la deuxième mesure et la suivante ne peuvent pas être dynamiques. En conséquence, des erreurs peuvent survenir lors de la compilation de ce code. Ici, la variable size_second_dimension peut être utilisée pour définir la taille de la deuxième dimension et permettre de surcharger la fonction. De plus, cela évite de devoir définir la dimensionnalité à travers ArrayRange().
 
Alexey Viktorov:

Est-ce que ça compile comme ça ?

Bien que je ne me souvienne pas exactement, il semble que la deuxième mesure et la suivante ne puissent être dynamiques. En conséquence, il peut y avoir des erreurs dans la compilation de ce code. Ici, la variable size_second_dimension peut être utilisée comme la taille prédéfinie de la seconde dimension et permet de surcharger la fonction. De plus, cela évite de devoir définir la dimensionnalité à travers ArrayRange().

Cela compilera, mais ce n'est pas intéressant, et qu'en est-il de z[][][] ?

La deuxième dimension et les dimensions supérieures ne peuvent pas être dynamiques, mais la fonction ne doit pas être personnalisée pour une taille particulière de la deuxième dimension, elle peut être trouvée par ArrayRange().

Si le nombre de mesures ne permet pas de surcharger la fonction, la taille de la seconde et des autres mesures ne le permettra certainement pas. D'ailleurs, ce n'est pas du tout intéressant, puisque ce n'est pas du tout universel. Il serait plus facile d'écrire des fonctions avec des noms différents.