0

I am using visual studio 2015, c++ project. In properties, C/C++, Preprocessor, I have defined a macro as follows : _SOLUTION_DIR_="$(SolutionDir)".

Using _SOLUTION_DIR_ in the code, I see that it's equal to "blaah\\" where the path blah contains only "\"'s as separators between folders. This makes me having Error C2001: newline in constant

I know that the visual studio environment variable $(SolutionDir) ends with a slash, but why is only this ending backslash that is view as "\\" and not the others ? How to solve my problem ?

Here is the code :

ConvertWchartArrayToCharArray(_SOLUTION_DIR_, pFilePath, MAX_PATH);

where ConvertWchartArrayToCharArray is defined by :

size_t ConvertWchartArrayToCharArray(const char * src, char * dest, size_t dest_len)
{
    size_t i;
    wchar_t code;
    i = 0;
    while (src[i] != '\0' && i < (dest_len - 1))
    {
        code = src[i];
        if (code < 128)
        {
            dest[i] = char(code);
        }
        else
        {
            dest[i] = '?';
            if (code >= 0xD800 && code <= 0xD8FF)
            {
                i++;
            }
        }
        i++;
    }
    dest[i] = '\0';
    return i - 1;
}

EDIT Now I am setting _SOLUTION_DIR_=LR"($(SolutionDir))" and using

ConvertWchartArrayToCharArray(_bstr_t(_SOLUTION_DIR_), pFilePath, MAX_PATH);

and I have the following problem : the file path is valid with \\ separators, containing at the end the filename, but doing a fopen(filepath, "r") give me null ...

Olórin
  • 3,367
  • 2
  • 22
  • 42
  • 1
    Got a Linux background by any chance? In general, this hints at an anti-pattern. An executable shouldn't have dependencies on the environment it was built in; the vast majority of executables will run on other machines. That said, you should show actual code. _How_ are you using `_SOLUTION_DIR_` ? – MSalters Apr 14 '17 at 10:23
  • No no, I am under a "real" windows 8. *How* I am I using `_SOLUTION_DIR_ ` ? As a `const char *`input parameter of a function. – Olórin Apr 14 '17 at 12:29
  • @MSalters I added code – Olórin Apr 14 '17 at 13:34
  • Use the os provided functions for converting to wchar. That's irrelevant, though. You've taken a string with a single backslash at the end, and inserted it directly into the c++ source, where it gets interpreted as an escape character, and wipes out the trailing quote. – Kenny Ostrom Apr 14 '17 at 14:16
  • I was thinking you can use the visual studio prebuild step to put that into an env variable, and use c++ functions to read the env. But, why are you making the final executable dependent on the location of the source code? That seems like a really bad idea. You may want to try relative paths or cwd or argv[0]. – Kenny Ostrom Apr 14 '17 at 14:24
  • @KennyOstrom You're saying that it's a bad idea to make a final executable dependant on the location of the source code ? 1st it's not the case here, as it is not location of the source code, but location of a "flat" text file and 2nd, that eveywhere the case (typically when you debug in visual studio, there's a visual studio addin using code using in turn "flat" .natvis files. – Olórin Apr 18 '17 at 21:53
  • No, the solution dir is where the source code is located. And something that lets a debugger find the original source code is different. But regardless of whether you agree with me, I ALSO explained what the actual problem is with what you are trying to do. Do I need to elaborate on that further in a full answer? – Kenny Ostrom Apr 18 '17 at 22:00
  • The flat file, I ship with my dll. How to handle properly this, then ? – Olórin Apr 18 '17 at 22:17
  • Your question didn't mention anything about a dll. Wait, you completely changed the original question, which was about bad escape codes. If you want to know why fopen failed, then try logging the filename and errno. – Kenny Ostrom Apr 18 '17 at 22:22
  • The code I am referring is the code of a dll I am compiling, and it is based on the text included in a "flat" file. I asked a question indeed, based on what I wanted to do with solution dir, but your remark (it's a bad idea making code depend on solution dir etc...) made me realize I was wrong. So now, I am asking myself : how to handle the case of a dll that depends on a flat file, I mean, ho to refer to it ? Absolute path is the best, isn't it ? – Olórin Apr 18 '17 at 22:26
  • So you need to open a config/data file for the dll, but all the relative paths are based on the application, which doesn't help you? – Kenny Ostrom Apr 18 '17 at 22:46
  • If you have a dll and some file you package with it, then a relative path would allow you to put the two wherever you want, if you know where the dll is. This may help http://stackoverflow.com/questions/6924195/get-dll-path-at-runtime – Kenny Ostrom Apr 18 '17 at 23:02
  • That's indeed the solution I finally opted for, independantly of your comment ! ;-) Thx anyway – Olórin Apr 19 '17 at 10:21
  • Please edit the question to actually ask about your problem. I.e. edit it to contain all information you gave in the comments. E.g. I do not see the dll mentioned. Adapt the title to reflect the new question, so that it can be found. Afterwards, it would be very nice to create an answer (maybe you, @KennyOstrom), so that this becomes a Q/A pair which is useful for other readers. Altogether it seems like an interesting and useful question, but that is very well hidden. – Yunnosch May 08 '17 at 06:31

0 Answers0