bête conversion de string en double

Version imprimable

11/02/2014, 11h40
lucky

bête conversion de string en double

Bonjour,

sous VC++ 2010 (MFC) mode debug 64 bits (win7), j'utilise une bête fonction atof() pour convertir un tableau de char ; lors de la première conversion je récupère bien le double correspondant mais lors des conversions suivantes j'ai 0.0000.. et non la valeur ; ma chaine se termine bien par le caractère nul et j'ai comme chaine un truc du genre "0.7932". (observé avec espion sur la variable...)
Est ce lié à l'environnement 64 bits ou autres ?

Merci
11/02/2014, 13h54
bacelar

Votre code svp.

voici le code (en gros) de la fonction appelé plusieurs fois dans l'exécution

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
double fct(...)
{
double d_resistance = 0.0 ;
static char  buffer[60] = {'\0'} ;
static char  buffdest[60] = {'\0'} ;
 
//...........
 
 
		if (....)
		{
			buffer[7] = 0 ;                         // ex : buffer est " 0.7210Ohm" 
			memcpy(buffdest,buffer+1,7);
			// 			i = 1 ;
			if ( (buffer[1]) == '>')
			{
				d_resistance = 0.0 ;
				......
				return d_resistance ;
			} 
			else
			{
 
				.....
// point d'arret >> buffdest est bien = "0.7210" dans notre exemple
                                d_resistance = atof(buffdest);           // premier passage OK, second d_resistance = 0.00000000000
				.....
				m_st_recept_rs232 = strtmp ;
			}
		}
                else
                {
                       ....
                       return 0.0 ;
               }
 
return  d_resistance;
}

Merci

11/02/2014, 14h35
lucky

je viens de mettre :

Code:

memset(buffdest,'\0',sizeof(buffdest));

avant le memcpy :
problème identique
11/02/2014, 15h14
lucky

Je viens d'essayer à la place :

Code:

d_resistance = strtod(buffdest,&stopstr);

problème identique !!!!
11/02/2014, 15h32
bacelar

Code fragile, static plus multi-threading => nimprotenawak

Code difficile à lire : indices, pointeurs, opération mémoire sur des char*, magique value '>' ...

Concrètement, faites un code complet qui reproduit le problème.

dernier code essayé (car j'ai un peu tout essayé...)
si vous arrivez à vous y retrouver :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
 
double CPosteCtrleBougiesGCSView::RS232LectureResistance(void)
	{
		static char  buffer[60] = {'\0'} ;
// 		static char  buffdest[20] = {'\0'} ;
		char *  buffdest ;
		char * stopstr ;
		static CString strtmp ;
		double d_resistance = 0.0 ;
		UINT i = 1 ;
 
 
		if (RS232EnvoieRecept(charx04,buffer))         // reception de la chaine dans buffer
		{
			buffer[7] = 0 ;                                     // à partir du 7eme caractère : à éliminer
			buffdest = buffer ;
// 			memset(buffdest,'\0',sizeof(buffdest));
// 			memcpy(buffdest,buffer+1,7);
 
			if ( (buffer[1]) == '>')                             // car dans certain cas j'ai ">>>" comme chaine
			{
				d_resistance = 0.0 ;
				strtmp = _T("Pas de résistance lue") ;
				m_st_recept_rs232 = strtmp ;
				m_st_recept_rs232.SetBkColor(ROUGEVIF);
				return d_resistance ;
			} 
			else
			{
 
// 				d_resistance = 0.0f ;                                                          //*****************************************************************************
//  				d_resistance = atof(buffdest);                                            // le problème de conversion se trouve ici en testant en debug la variable d_resistance / buffdest (buuffdest = bonne chaine
				d_resistance = strtod(buffdest,&stopstr);                            // essayé avec des variables static ou non static...                      
				m_st_recept_rs232 = strtmp ;                                           //*****************************************************************************
			}
		}
		else
		{
			strtmp = _T("Erreur de lecture résistance") ;
			m_st_recept_rs232 = strtmp ;
			m_st_recept_rs232.SetBkColor(ROUGEVIF);
			return 0.0f ;
		}
 
		RS232EnvoieRecept(charx00,buffdest);
 
// 		strtmp.Format(_T("%s"),buffer+1);
		m_st_recept_rs232 =  strtmp;
 
		return d_resistance ;
	}

Merci

11/02/2014, 16h20
bacelar

>Concrètement, faites un code complet qui reproduit le problème.
Donner le code source d'une fonction qui appel des primitives "maison" et qui doit avoir un RS232 au cul, n'est pas ce que j'appel un code "complet".

Nous, avec ça, on n'a aucune chance de faire fonctionner un debuggeur avec.

Au lieu de tester tout est surtout n'importe quoi, commencez par essayer de comprendre pour quoi l'approche simple ne fonctionne pas.

N'utilisez pas l'espion sur variable, mais les vues "mémoire" du débuggeur pour voir concrètement le contenu de la mémoire avec valeurs des pointeurs que vous fournissez aux fonctions.

En fait j'ai trouvé un paliatif qui fonctionne aprés avoir crée la fonction :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
#include <iostream>
#include <sstream>
#include <string>
 
// Using stringstream :
template <typename T>
T string_to_T(const std::string &param)
{
	    std::istringstream istr(param);
	    T t;
	    istr >> t;
 
	    return t;
}

ensuite j'ai remplacé mes atof ou autres par :

Code:

1
2
3
 
				const std::string &stst(buffdest) ; // ex buffer = "0.7245"
				d_resistance = string_to_T<double>(stst); // converts string to double

et là c'est OK à chaque fois

11/02/2014, 17h05
bacelar

GG.
Un beau marteau pilon pour écraser une mouche. :aie:

C'est très probablement l'utilisation ou la non utilisation d'un setlocale qui vous fait construire ce marteau pilon.

Ce marteau pilon a les mêmes faiblesses que atof mais pas les mêmes primitives de configuration, mais cela ne serait tarder.

Vérifiez que c'est '.' et non ',' qui est en mémoire pour la chaine dans le buffer.
12/02/2014, 08h01
lucky

Bonjour,

il y a bien une chaine avec le point du type 0.7215 ; c'est sûr qu'il y a quelque chose qui m’échappe mais je creuserai quand j'aurai plus de temps.
Je vous remercie pour avoir essayé de m'aider.
Je ne serai remercier tous ceux qui apportent du soutien et des réponses à des problèmes souvent bénins.
Dans mon cas, c'est peut être l'arbre qui cache la forêt.
Encore merci.