Pourquoi pas votre instruction switch type de données long, Java?

Voici un extrait de Java de Sun tutoriels:

Un switch fonctionne avec le byte, short, char, et int types de données primitifs. Il travaille également avec des types énumérés (discuté dans les Classes et l'Héritage) et quelques classes spéciales que "wrap" de certains types de primitives: Character, Byte, Short, et Integer (discuté dans de Simples Objets de Données).

Il doit y avoir une bonne raison pour laquelle l' long type de données primitif n'est pas autorisé. Quelqu'un sait ce que c'est?

InformationsquelleAutor Fostah | 2010-04-20
  1. 45

    Je pense que dans une certaine mesure, c'était probablement une décision arbitraire basée sur l'utilisation typique de l'interrupteur.

    Un commutateur peut essentiellement deux façons (ou, en principe, une combinaison): pour un petit nombre de cas, ou ceux dont les valeurs sont très dispersées, un interrupteur devient essentiellement l'équivalent d'une série de fi sur une variable temporaire (la valeur étant sous tension ne doit être évaluée une fois). Pour un nombre modéré de cas qui sont plus ou moins consécutifs de valeur, un commutateur de table est utilisée (le TABLESWITCH instruction en Java), dans lequel l'emplacement de saut est effectivement regardé dans un tableau.

    L'une de ces méthodes pourrait, en principe, utiliser une valeur de type long plutôt qu'un entier. Mais je pense que c'était probablement juste une décision pratique à l'équilibre de la complexité du jeu d'instructions et le compilateur avec le besoin réel: le cas où vous avez vraiment besoin de passer un long assez rare qu'il est acceptable d'avoir à ré-écrire comme une série d'instructions if, ou autour d'une autre façon (si le long valeurs en question sont proches, vous pouvez dans votre code Java basculer l'int résultat de la soustraction de la valeur la plus faible).

    • Je suis d'accord avec la "rareté" de l'argument que j'ai développé en Java pour un moment, et je n'étais jamais venu dans une situation où j'avais besoin d'/essayé de passer sur un long jusqu'à maintenant.
    • "L'une de ces méthodes pourrait, en principe, utiliser une valeur de type long plutôt qu'un entier". Donc, cette réponse fait valoir que, en principe allumer longs sont possibles (de sorte qu'ils peuvent être ajoutés dans le futur?). Faible. Dans ma réponse ci-dessous, je montre pourquoi passer sur nostalgie serait fondamentalement être une fracture de la notion dans les plates-formes 32 bits, donc non, même pas, en principe, l'interrupteur sur la nostalgie pourrait être pris en charge. Je ne peux pas aider mais de souligner le fait que Neil est venu et (probablement) downvoted ma réponse, avec un raisonnement basé sur une incompréhension de fil de sécurité. Nice.
    • Dimitris, mon raisonnement n'était pas basée sur un midunderstanding du filet de sécurité, juste que je ne pense pas que le fil de sécurité argument mis en avant est titulaire.
    • J'ai du mal voir qui. Pourtant si, la "quelle que soit la largeur" que vous mentionnez n'est pas trop précis. Si la largeur est un mot, alors vous savez qu'au moins quelqu'un a effectivement écrit la valeur qui a été lu, alors ça ne va pas être une adresse hors de l'air mince, mais l'adresse de quelqu'un devrait l'être. Les deux sont des problèmes, mais dans la nostalgie, le problème est certainement plus grand, plus les moyens d'aller mal. C'est tout ce que je veux dire.
    • Plus stupide décision de conception jamais. J'ai une longue qui est un tas de drapeaux, et j'ai à faire avec des if...else if...else... Totalement ridicule.
    • Je suis d'accord w/ @m0skit0. Dans mon cas, quelqu'un d'autre a écrit une API à l'aide de longs tant que constantes, parce que c'est ce qu'ils enregistrent dans la DB. Maintenant, je ne peux pas utiliser un switch/case à cause de quelqu'un d'autre mauvaise décision.
    • Si vous voulez vraiment utiliser un switch, il y a divers moyens de contourner cela, par exemple: l'utilisation d'une fonction de hachage pour convertir le aspire à ints, construire une Map<Long, Integer> à la carte, datant de la DB int constantes, l'utilisation de Long.toString() et ensuite passer sur des chaînes de caractères (qui est pris en charge comme des JDK7)... je me demande vraiment si ne pas être en mesure de passer sur la nostalgie est un cessez-le-monde scénario!
    • Je ne dis pas que c'est de la "fin du monde". Et, oui, il y a des façons de contourner cela, mais ils semblent tous comme des hacks. Mon point est que, en tant que développeurs, nous devrions toujours essayer de penser plus loin que la façon dont nous pensons que les gens vont utiliser les trucs de construction. Dans ce cas, quelqu'un a fait une décision de ne pas autoriser switch/case sur le long basé sur l'idée que "Qui honnêtement avoir 2^64 cas". C'est peut-être un des simplifications. Peut-être il ya une autre raison pourquoi la nostalgie ne peut pas être commuté que nous étions juste pas du trop. Pour moi, il semble juste étrange de ne pas le soutenir.
    • Sérieusement, je pense que vous êtes en train d'inventer un problème qui n'existe pas...!

    InformationsquelleAutor Neil Coffey
  2. 19

    Parce qu'ils n'ont pas mis en œuvre les instructions du bytecode et vous vraiment ne veux pas écrire que de nombreux cas, n'importe comment "prêt pour la production" votre code est...

    [EDIT: Extrait de commentaires sur cette réponse, avec quelques ajouts sur fond]

    Pour être exact, 232 est un beaucoup de cas et de tout programme avec une méthode assez long pour contenir plus que ça va être absolument horrible! Dans n'importe quelle langue. (La plus longue de la fonction je ne connais dans tout le code dans n'importe quelle langue est un peu plus de 6k SLOC – oui, c'est un gros switch et c'est vraiment ingérable.) Si vous êtes vraiment coincé avec le fait d'avoir un long où vous ne devez avoir qu'un int ou moins, alors vous avez deux alternatives réelles.

    1. Utiliser une variante sur le thème de fonctions de hachage pour compresser le long dans un int. Le plus simple, à utiliser uniquement quand vous avez le type de mal, est de les jeter! Plus utile serait de le faire:

      (int) ((x&0xFFFFFFFF) ^ ((x >>> 32) & 0xFFFFFFFF))

      avant de passer sur le résultat. Vous aurez à travailler sur la façon de transformer le cas que vous faites des tests à l'encontre de trop. Mais vraiment, c'est toujours horrible, car il ne traite pas le problème réel de beaucoup de cas.

    2. Une bien meilleure solution si vous travaillez avec un très grand nombre de cas est de changer votre conception à l'aide d'un Map<Long,Runnable> ou quelque chose de similaire à ce que vous êtes à la recherche de la façon de l'envoi d'une valeur particulière. Cela vous permet de séparer le cas dans plusieurs fichiers, ce qui est beaucoup plus facile à gérer lorsque l'affaire-comte est grande, même si elle est plus complexe à organiser l'enregistrement de l'hôte de la mise en œuvre des classes concernées (les annotations peuvent aider en vous permettant de construire le code d'enregistrement automatiquement).

      FWIW, je l'ai fait il y a plusieurs années (nous nous sommes mis à la nouvellement libérés J2SE 1.2 mi-chemin à travers le projet) lors de la construction d'un personnalisé du bytecode moteur de simulation massivement parallèle de matériel (non, la réutilisation de la JVM n'aurait pas été approprié en raison de la radicalement différentes de la valeur et de l'exécution des modèles concernés) et énormément simplifié le code par rapport à la grande switch que la version C du code était de l'utiliser.

    De réitérer le message, voulant switch sur un long est un signe que soit vous avez les types de mal dans votre programme ou que vous êtes en train de construire un système avec beaucoup de variation impliqué que vous devriez être à l'aide de classes. Le temps pour repenser dans les deux cas.

    • Un commutateur n'ont pas besoin d'être mis en œuvre avec un TABLESWITCH bien, et c'est sur le gamme des étiquettes, comme le nombre.
    • Mais la portée est d'être basculé vraiment plus de 32 bits de large? Je n'ai jamais entendu parler de code nécessaire que de nombreux changez de bras. Sans cela, vous pouvez compacte de la gamme (par exemple, en utilisant quelques variations sur le thème de fonctions de hachage) pour faire quelque chose qui fonctionne. Ou utiliser un Map<Long,Runnable> pour résoudre le problème dans un tout autre chemin. 🙂
    • N'est-ce pas répondre à tout type de renvoyer la balle? La question devient juste "pourquoi n'ont-ils pas mettre en œuvre les instructions nécessaires?"
    • Torgamus: sans doute parce que son idiot. Pensez-y un instant: pourquoi tout le monde, quelqu'un, avoir le code avec plus de 232 les bras dans une switch? Vouloir choisir sur un ensemble fini de beaucoup d'éléments tout simplement des points pour une erreur dans la conception fondamentale du programme. Que les gens demandent, il indique simplement que **ils ont leur conception de mal.
    • BTW, si quelqu'un veut discuter avec moi sur ce point, veuillez commencer par donner un cas d'utilisation pour la commutation sur une longue. Sinon, nous allons être coincé en argumentant avec hypothétiques pour toujours...
    • Je ne dis pas que vous avez tort; en fait, je vais aller de l'avant et de l'état de droit, maintenant que vous êtes de droite. Mon point est que votre commentaire il n'y en aurait fait une meilleure réponse que le texte que vous avez réellement présenté comme une réponse.
    • Torgamus: Juste point de, et je vais le modifier en suivant. 🙂
    • Voici les cas d'utilisation qui introduit le présent à mon attention. BlackBerry événements mondiaux sont indexés avec les Guid, qui sont de type long dans la plate-forme BlackBerry. J'ai eu une poignée d'événements, j'ai voulu créer un commutateur pour. Je n'ai jamais prévu d'avoir de nombreux cas, je préfère juste un commutateur de format plus "if...else if" des déclarations.
    • Je me demande pourquoi le BB plate-forme utilise la nostalgie de là. Ont-ils vraiment que de nombreux événements dont ils ont besoin Guid? (Probablement pas. Plus probable que certains développeurs à BB était un crétin.) De toute façon, de faire un rapide et sale de hachage ou d'un plâtre pour int fonctionnera probablement. Le mal de pirater, mais à bas prix. Vous aurez à vérifier que les événements qui se déroulent autour de ne frappez pas votre code par hasard, mais avec Guid/Uuid qui est assez rare. (Ou utiliser un Map rempli avec anonyme intérieur des instances de classe.)
    • J'ai juste touché à cette question, en utilisant les trésors des bibliothèques ont décidé d'utiliser un hash map <long, Object> (pas Longtemps) pour des raisons de performances et depuis que j'utilise la carte de tous les plus de l'application il y a des endroits où les longues plutôt que int est nécessaire. Maintenant j'ai aussi l'utiliser pour la diffusion de données alors, quand je reçois ma carte de retour je fais un switch sur les touches et hop je peux pas le faire. Maintenant, il na pas me prendre autant de temps pour type (int) quelques fois qu'il a taper, mais c'est un WTF moment, et je m'attendais à une meilleure raison pour expliquer pourquoi il n'est pas mis en œuvre.
    • Une autre possibilité est d'écrire votre propre fonction de hachage (par exemple, en enveloppant le GUID à l'intérieur de sa propre classe) qui convertit du peu de valeur de l'espace en quelque chose de plus compact (et qui est un int). Aussi longtemps que vous l'utiliser comme une condition préalable pour l'égalité (c'est à dire, la valeur de l'égalité implique de hachage de l'égalité, et pas l'inverse), alors vous n'aurez pas de réels dangers.
    • Une autre affaire est en Android avec de ListView. Alors que les listViews peut avoir long nombre de lignes, j'ai uniquement besoin de 4. C'est un cas de m'avoir un long me tendit que l'indique la ligne qui est agi, et j'ai besoin de faire des choses différentes en fonction sur la ligne qui il est. Je suppose que je pourrais cast en int, mais il aurait rendu ma vie plus facile si je pouvais avoir juste switched sur la variable. Comme il est, je suis juste en utilisant une chaîne de if et else if à la place.
    • Hey, et ce sur une longue mise en œuvre de drapeaux? C'est un stupide Java décision de conception.
    • "Pour réitérer le message, en voulant allumer une longue, est un signe que soit vous avez les types de mal dans votre programme" - Non, il ne l'est pas! Avoir un long ne signifie pas que vous allez vérifier toutes les possibilités, un peu comme avoir un int ou un String ne veut pas dire que ce soit. Cela signifie que les valeurs que vous avez, ce qui pourrait être une poignée, ont un grand gamme. Vous pourriez être vérifier quelques cas simples et de tomber dans default pour le reste. Avoir à faire des changements et jette signifie que vous risquez de perdre des données. Bas de ligne, c'est un mauvais dessin Java décision de ne pas un utilisateur en question.

    InformationsquelleAutor Donal Fellows
  3. 3

    Parce que la table de recherche de l'indice doit être de 32 bits.

    • Mais là encore une switch n'a pas besoin d'être mis en œuvre avec une table de recherche nécessairement.
    • Si c'était le cas, ils n'ont jamais pu mettre en œuvre interrupteur pour Cordes (comme ils le prévoient actuellement).
    • oui, nous pouvons passer maintenant dans les Cordes 😀 (depuis des années maintenant 😛 )
    InformationsquelleAutor JRL
  4. -10

    Une longue, dans les architectures 32 bits, est représenté par deux mots. Maintenant, imaginez ce qui pourrait arriver si, en raison de l'insuffisance de la synchronisation, l'exécution de l'instruction switch observe avec son haut de 32 bits à partir d'une écriture, et le 32 bas à partir d'un autre! Il pourrait essayer d'aller en......qui sait où! Fondamentalement, quelque part au hasard. Même si les deux écrit représenté cas valables pour l'instruction switch, leur drôle de la combinaison de probablement conduire ni à la première ni à la seconde, ou extrêmement pire, il pourrait conduire à un autre, mais sans rapport avec les cas!

    Au moins avec un int (ou moins de types), peu importe à quel point vous vous trompez, l'instruction switch permettra au moins de lire une valeur qui quelqu'un a effectivement écrit, au lieu d'une valeur "out of thin air".

    Bien sûr, je ne connais pas la réelle raison (ça fait plus de 15 ans, je n'ai pas fait attention que long!), mais si vous vous rendez compte à quel point dangereux et imprévisible, une telle construction pourrait être, vous serez d'accord que c'est certainement un très bonne raison de ne pas jamais ont un commutateur à longs (et tant -jeu de mots - il y aura des machines 32 bits, cette raison demeureront valides).

    • Je ne pense pas que ce suit. La valeur de commutation doit être calculée et stockée dans un registre ou sur la pile. Si cette valeur est calculée en se basant sur les données accessibles par plusieurs threads, ce calcul doit être thread-safe, quelle que soit la largeur de la suite. Mais alors, une fois que le résultat est dans un registre ou sur la pile, il est accessible uniquement par la commutation de fil et sans danger.
    • Neil, votre argument est assez confus: "Mais alors, une fois que le résultat est dans un registre ou sur la pile, il est accessible uniquement par la commutation de fil et est sûr". Bien sûr, en utilisant cette valeur est thread-safe! Mais mon point est que que la valeur peut _already_ être mauvaise en raison de la synchronisation des bugs dans le code de l'utilisateur. À l'aide de fil en toute sécurité une valeur incorrecte est moins utile 🙂 Cette question ne peut être éliminée: buggy code concurrente pourrait déjà avoir produit le "out of thin air"/mauvaise valeur de type long, qui peut ensuite être utilisé dans le switch, ce qui rend le commutateur aller à un cas d'adresse personne n'a jamais spécifié.
    • Dimitris, peut-être il y a quelque chose dans votre argumentation, je ne suis pas la compréhension. La valeur allumé pourrait en effet être mauvaise en raison de la synchronisation des bugs dans le code de l'utilisateur. Mais je ne crois pas qu'il y ait quelque chose d'inhérent à propos de l'instruction switch qui fait ce plus souvent que dans d'autres cas. Et de le penser par le biais du mieux que je peux, je ne crois pas que la non-atomicité de hi/low paroles de longues lectures/écritures de la mémoire est en fait un problème. (Penser à des choses antoher façon: vous pouvez décider que si la comparaison sur une longue n'a pas été autorisé basé sur le même argument.)
    • Alors que les problèmes potentiels à long représentée sous la forme de deux mots, sans garantie atomique écrit est un problème général, d'accord, dans le cas de switch, il serait encore plus prononcé danger. C'est comme envoyer une enveloppe avec un message où la moitié de l'adresse d'une personne, la moitié est de l'autre - l'adresse finale pourrait être valide et correspondent à une totalement aléatoire chap qui serait alors recevoir l'enveloppe et d'agir en conséquence. C'est une chose de la lecture de déchets et la production de déchets (comme un faux boolean), mais la lecture des ordures et de faire des sauts aléatoires t son un peu plus dangereux pour moi.
    • Je sais que c'est vieux et commentant c'est discutable, mais je tiens à souligner que votre argument s'applique à if ainsi et le résultat serait tout aussi mauvais: mauvais résultat ~> mauvaise direction prise. Création d'un long if-else-if chaîne au lieu d'une switch entraînerait en fait exactement le même résultat.
    InformationsquelleAutor Dimitris Andreou