Question

I am just using these wide character literals in my code to learn about them

     wchar_t* wpsub = wcstok(names, names_delim);
     wpsub = wcstok(NULL, names_delim);
     wchar_t* wcopied=new wchar_t[wcslen(wname) + 1];
     strcpy(nameptr, "singh");
     wcscpy(wcopied, wname);
     wcscat(wcopied, L" Singh");

why am I getting these warning,I ignored it anyway.
do we need to ignore any such warnings.

    : warning C4996: 'wcstok': This function or variable may be unsafe. Consider using wcstok_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
    : see declaration of 'wcstok'
    : warning C4996: 'wcstok': This function or variable may be unsafe. Consider using wcstok_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
    : see declaration of 'wcstok'
    : warning C4996: 'strcpy': This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
    : see declaration of 'strcpy'
    : warning C4996: 'wcscpy': This function or variable may be unsafe. Consider using wcscpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
    : see declaration of 'wcscpy'
    : warning C4996: 'wcscat': This function or variable may be unsafe. Consider using wcscat_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
    : see declaration of 'wcscat'

Answer 1

There is another reason not to use the original strtok family function:

[…] However, within a single thread, interleaving calls to one of these functions is highly likely to produce data corruption and inaccurate results. When parsing different strings, finish parsing one string before starting to parse the next. Also, be aware of the potential for danger when calling one of these functions from within a loop where another function is called. If the other function ends up using one of these functions, an interleaved sequence of calls will result, triggering data corruption.

The reason is that strtok is not reentrant: When designed, is was believed it would be a good idea for it to use a global variable as repository for the context (how did you think strtok can remember where to continue between each function call?).

The past is the past, and we should not judge code from decades ago, but then, with all the new standards (C99 comes to mind), I’m still surprised this function didn’t get refactored.

At the very least, the strtok_s family of function produced by Microsoft uses a user-provided variable for that (called context). If you have the choice, for production code, use strtok_s.

And if you need to provide cross platform code, my advice is :

1. write a function which will be used as an indirection to the real one
2. On Windows, redirect to strtok_s
3. On whatever platform where there is a safe strtok (I found strtok_r when Googling), redirect to that function
4. On platforms where there are not safe strtok, write your own (it’s far from being difficult, and is a good exercise to learn programming)

Now, there are C++ alternatives to these C functions, either combining std::string methods together, or using boost::tokenizer