Bonjour,  
 
je développe une petite macro sous vba dans le cadre de mon travail, et pour augmenter sa rapidité j'ai décidé d'en faire une partie en c++.  
 
Ainsi, je rentre toutes mes données sous excel, puis ma macro crée des fichiers .txt avec ces données, puis mon programme c++ lis et récupère ces données.  
 
Si j'exécute mon programme sur mon outil de dev (visual studio) ou si je double clique sur le .exe, tout fonctionne parfaitement.  
Par contre, lorsque je veux lancer l exécutable depuis excel avec la fonction shell cela ne fonctionne pas : l'exécutable est bien lancé mais il ne parvient pas a trouver les fichiers de données d'entrée. Ainsi le problème réside dans la lecture des fichiers.  
 
Je ne sais pas si cela est pertinent mais je donne quelques faits qui peuvent peut être donner des pistes.  
 
Je donne vite fait l arborescence :  
mon projet ->  Debug------>monprojetdebug.exe, fichiers de données d entrée  
                    Release---->monprojetrelease.exe, fichiers de données d entrée  
                    monprojet->fichiers de données d'entrée, fichiers de projet visual studio etc  
 
Bon je suis d'accord c'est pas très propre de copier 3 fois les fichiers de données mais c'est parce que je ne comprends pas le fonctionnement de visual studio.  
 
Si j'exécute le programme directement depuis vs, la seule maniere de faire fonctionner c'est d'appeler mon fichier sans chemin :  
string input_file = "donnees.txt"  
Si je mets un quelconque chemin (absolu (ou même relatif en fait)) cela ne fonctionne plus. Les fichiers peuvent indifféremment se trouver dans le dossier monprojet, ou release.  
Il semble qu'il y est un souci avec les "\" :quand je rentre mon chemin absolu,  
string input_file = "C:\chemin\donnees.txt" et qu'ensuite je demande au programme de l'afficher (avec cout) il affiche la string sans les "\".  
 
Si j'exécute directement mon programme (double clic sur le .exe) il faut absolument que les fichiers se trouvent dans le dossier Release (pourquoi y a t il ce fonctionnement différent ? je n'en sais rien, peut etre que visual studio parvient a faire un lien avec le dossier contenant les fichiers de projet vs alors que lorsqu on exécute directement il ne trouve plus).  
 
Si je lance l'exécutable depuis le windows PowerShell shell, cela fonctionne.  
 
J'espère avoir été clair, sinon n'hésitez pas à me demander des précisions.  
Si vous pensez à des explications, merci parce que là cette histoire commence à me rendre fou

 
            Bonjour.
 
            Désolé de ne pouvoir apporter de l'aide à votre problématique mais ceci me fait réagir :
 

            Sur un PC portable i5-3210M sous Win 7, en VBA only (donc sans FSO ou autre dll) il faut entre 4 et 15 centièmes de secondes
            (selon la pleine puissance de 2.5 GHz ou le mode économie d'énergie de 1.5 GHz et ce avec un disque dur normal, pas un SSD)
            pour lire un fichier de 1.01 Mo (de 1 060 035 octets exactement) de précisément 72 124 lignes
            et séparer les lignes dans un tableau en mémoire :  je doute qu'une dll externe fasse beaucoup mieux !
 
            Je n'ai plus les mesures exactes des tests sur un i3 mais ce n'est guère plus long, plus que correct …
 
            Edit :  + 4 centièmes de secondes sur un i3-2370M à 2.4 GHz.

Oui bien sûr la lecture/récupération des données n'est pas plus rapide, mais la macro en question n'a pas pour but de simplement récupérer ces données, mais est en fait un programme d'optimisation dynamique. (je constate en gros un facteur 60 au niveau de la rapidité...)
Je me sers d'excel juste pour les fonctionnalités sympa déjà intégrées, notamment pour la gestion des dates. Et puis c'est plus facile pour faire des interfaces cools et des beaux graphes.

Avez-vous essayé en doublant les "\\", comme on fait en C  
 
string input_file = "c:\\chemin\\donnees.txt"
 
Pour Visual Studio, de mémoire, le répertoire de travail par défaut est l'endroit où se trouve le fichier du projet/de la solution, quel que soit l'endroit où il génère l'exécutable (Release/Debug).
 
Cela ne doit pas être grand chose ...
 
Bonne continuation !