J'ai une application C / C ++ qui écrit des valeurs numériques dans Redis en tant que chaîne. J'ai aussi une application Java qui lira ces valeurs de Redis. À l'occasion de raisons valables, nous nous retrouvons avec une valeur à virgule flottante qui a une valeur de Cette application a été portée à partir de Solaris à Linux et a ensuite suivi certaines mises à niveau Linux et, à un moment donné, "Nan" est devenu "Nan". Je ne peux pas dire que certains sur quelle mise à niveau introduisit finalement ce comportement.
J'ai parcouru une exercice d'utilisation de En fin de compte, je dois être capable de décoder des données écrites par l'application C ++ en Java. Nan et Inf ne peuvent pas être décodés par Java comme écrit. Mon objectif était sur Nan, mais l'infini est un cas qui devrait être couvert. nan ou -Nan . Cependant, lorsque vous utilisez sprintf (charptr, "% E", DBLVAL); , la valeur est sortie sous forme nan . J'ai également essayé la même déclaration avec % e , et il a abouti à nan . Lorsque Java tente d'analyser via float.parsfloat () ou double.parsedouble il jette une exception numérique.
std :: isnan () et peut définir finalement mon propre (- ) Nan ou (-) Infinity Strings, mais cela ne semble pas que je dois réinventer des chaînes normalisées de NaN et d'Infinity. L'infini peut être un peu différent que les sorties du côté C inf Java veulent Infinity .
3 Réponses :
Pourquoi ne pas simplement utiliser quelque chose comme celui-ci dans votre code Java pour analyser un double?
Cela semble être un cas raisonnable, car il ne serait coché que dans le cas d'une mauvaise analyse en premier lieu, nous ne vérifierions donc pas toutes les analyses valides. J'attendrai un peu de temps pour voir si quelqu'un a autre chose à dire sur la question.
Il pourrait être utile de suivre ce que les autres Libcs utilisent pour ces valeurs (je pense que Windows CRT utilise quelque chose comme 1. # qnan ?) Et les comptabiliser aussi.
La fonctionnalité de la façon dont nous passons le virage flottant me dérange depuis un moment. Fondamentalement, je suis à la merci de la manière dont cela a été mis en œuvre dans les langues et je ne vois pas les changements qui arrivent pour accueillir de chaque côté. Votre réponse couvre ma question étant donné que Java et Libc sont simplement différents. Cela dit, je pense que la gestion du format sur le côté C des choses serait potentiellement plus efficace que je ferais une comparaison binaire via Isnan et isminite par opposition aux comparaisons de chaîne en Java, mais sur Java, la comparaison ne se produirait que si l'analyse échoue. première.
L'affaire Linux est (a) Comportement correct selon ISO / CEI 9899: 2001 :
[
% E ,% e ][...] A
Double L'argument représentant une infini ou une nan est converti dans le style d'unF ouf Spécificateur de conversion.et le texte pour
Un double argument représentant une infini est converti dans l'un des styles
[-] inf ou[-] infini - quel style est défini par la mise en œuvre. Un double argument représentant une NAN est converti dans l'un des styles[-] nan ou[-] nan (n-char-séquence) - quel style et La signification de toute séquence N-Char est définie par la mise en œuvre. Le spécificateur de conversion F produitinf ,Infinity ounan au lieu deinf ,infini , ounan , respectivement.277)I.e. Le plus sûr de Java serait d'essayer d'analyser le double, et si cela échoue, minuscule la chaîne - comme premier caractère et le reste après le Signe possible avec
.startswith ("nan") et.tpartSwith ("INF")Bien sûr, cela ne vous aide pas si vous devez prendre en charge les exécutions Windows C conformes aux normes non conformes aux normes.
Une option potentiellement plus universelle serait de convertir le numéro de point flottant en hexadécimens lorsqu'il est écrit sur Redis, puis converti en arrière lors de la lecture. Cela garantirait qu'il n'y aurait aucune perte de précision en la convertissant en une chaîne décimale, mais couvre également les cas +/- INF et NAN.
Ceci est possible car les deux côtés utilisent des nombres de points flottants IEEE.
Info Intéressant Info-Info, mais quelle est la question / but?