string type troubles

I have been trying to get the following test program to at least compile and find out where I'm getting my memory addressing problems wrong in the main program. Here is my code:

Code:

---

#include <iostream>
#include <windows.h>

BOOL somefunc(const WCHAR* filepath,
                          const wstring* Additions,
                          DWORD AdditionsSize);

int main()
{
        const wstring additions[] = {L"black.dll",
                L"white.dll",
                L"yellow.dll"};
        BOOL ok = somefunc(L"E:\\somepath", additions, sizeof(additions)/sizeof(wstring));

        return 0;
}

BOOL somefunc(const WCHAR* filepath,
                          const wstring* Additions,
                          DWORD AdditionsSize)
{
        for (DWORD i = 0; i < AdditionsSize; ++i)
        {
                wcout << Additions[i] << endl;
        }

        return TRUE;
}

---

However, I'm getting the following compiler error with regards to the types in Visual Studio 2005:

Code:

---

1>------ Build started: Project: ptrtoptr, Configuration: Debug Win32 ------
1>Compiling...
1>ptrtoptrmain.cpp
1>e:\test\ptrtoptr\ptrtoptrmain.cpp(5) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>e:\test\ptrtoptr\ptrtoptrmain.cpp(5) : error C2146: syntax error : missing ',' before identifier 'Additions'
1>e:\test\ptrtoptr\ptrtoptrmain.cpp(10) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>e:\test\ptrtoptr\ptrtoptrmain.cpp(10) : error C2146: syntax error : missing ';' before identifier 'additions'
1>e:\test\ptrtoptr\ptrtoptrmain.cpp(10) : error C2065: 'additions' : undeclared identifier
1>e:\test\ptrtoptr\ptrtoptrmain.cpp(10) : error C2059: syntax error : ']'
1>e:\test\ptrtoptr\ptrtoptrmain.cpp(10) : error C2143: syntax error : missing ';' before '{'
1>e:\test\ptrtoptr\ptrtoptrmain.cpp(12) : error C2143: syntax error : missing ';' before '}'
1>e:\test\ptrtoptr\ptrtoptrmain.cpp(13) : error C2070: ''unknown-type'': illegal sizeof operand
1>e:\test\ptrtoptr\ptrtoptrmain.cpp(19) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>e:\test\ptrtoptr\ptrtoptrmain.cpp(19) : error C2146: syntax error : missing ',' before identifier 'Additions'
1>e:\test\ptrtoptr\ptrtoptrmain.cpp(22) : error C2065: 'AdditionsSize' : undeclared identifier
1>e:\test\ptrtoptr\ptrtoptrmain.cpp(24) : error C2065: 'wcout' : undeclared identifier
1>e:\test\ptrtoptr\ptrtoptrmain.cpp(24) : error C2065: 'Additions' : undeclared identifier
1>e:\test\ptrtoptr\ptrtoptrmain.cpp(24) : error C2065: 'endl' : undeclared identifier
1>Build log was saved at "file://e:\test\ptrtoptr\Debug\BuildLog.htm"
1>ptrtoptr - 15 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

---

Is there a header file that I have missed that could cause this to happen?

Quote:

---

Originally Posted by stanlvw

Is there a header file that I have missed that could cause this to happen?

---

Yes: #include <string>
You also need to either prefix wstring, wcout & endl with std:: or add a using statement.

Thanks for the tip. I've actually found this out right after my post (guess my head wasn't thinking properly). However, I am now trying to perform pointer manipulation, which is pointing to an array like so:

Code:

---

#include <iostream>
#include <vector>
#include <string>
#include <windows.h>
using namespace std;

BOOL somefunc(const WCHAR* filepath,
                          const wstring* Additions,
                          DWORD AdditionsSize);

int main()
{
        const wstring newlist[] = {L"black.dll",
                L"white.dll",
                L"yellow.dll"};
        BOOL ok = somefunc(L"E:\\somepath", newlist, sizeof(newlist)/sizeof(wstring));

        return 0;
}

BOOL somefunc(const WCHAR* filepath,
                          const wstring* Additions,
                          DWORD AdditionsSize)
{
        wstring result;
        wstring* someOtherPath = NULL;

        for (DWORD i = 0; i < AdditionsSize; ++i)
        {
                someOtherPath[i] = filepath + Additions[i];
                wcout << someOtherPath[i] << endl;
        }

        return TRUE;
}

---

However, I'm either getting a compiler error saying I can't add pointers together, or I'm getting a runtime error on the line where I'm attempting the addition. Is there an easy way to get around this?

Code:

---

        wstring* someOtherPath = NULL;

        for (DWORD i = 0; i < AdditionsSize; ++i)
        {
                someOtherPath[i] = filepath + Additions[i];

---

What are you trying to do?
Adding two pointers is illegal and your code wouldn't work right if it was allowed, because it isn't merging the two strings at all, but rather trying to add their address.
Use std::string objects instead and pass by reference. Otherwise you're going to have to reply on C string copy functions.

I'm trying to concatenate the result of filepath and current entry pointed by Additions and store it in someOtherPath. When Elysia said "use std::string" objects and pass by reference, I don't quite understand what was being said. When I pass the array through the function, to my understanding, I'm already passing by reference. And wstring is a typedef of a string object.

Quote:

---

Originally Posted by stanlvw

I'm trying to concatenate the result of filepath and current entry pointed by Additions and store it in someOtherPath.

---

Pointers aren't magical, you know ;)
You must allocate storage first if you wish to add something into it.

Quote:

---

When Elysia said "use std::string" objects and pass by reference, I don't quite understand what was being said. When I pass the array through the function, to my understanding, I'm already passing by reference.

---

Code:

---

void foo1(int) { } // By value
void foo2(int*) { } // By pointer
void foo3(int&) { } // By reference

---

You're passing the address to the string itself and not the actual object:

Code:

---

int main()
{
    std::string mystr = "My string";
    const char* mystr2 = "My string";
    foo(mystr); // Passing object by reference (or value)
    foo(mystr2); // Passing address of string by pointer (by value, actually)
}

---

Quote:

---

And wstring is a typedef of a string object.

---

Yes, but you should probably make your new string of type std::wstring, as well, so you concatenate the strings there.

I've actually managed to get around the problem minimizing the use of an extra pointer now, and it seems to be working quite well without problems (at least right now). Thanks for your help.

There's something that I'm having trouble with in terms of cleaning up my code. I'm trying to define a macro as shown to be used in the concatenation process:

Code:

---

#define SLASH                        TEXT("\\")

---

and this is the concatenation that I tried to do here:

Code:

---

someOtherPath = filepath + SLASH + Additions[i];

---

someOtherPath is wstring, filepath is const WCHAR*, and Additions[i] is wstring from having Additions passed in as const wstring*. I'm trying to concatenate slash in the code, but I can't think of anyway of doing so without obtaining a wstring copy of SLASH. Would appending the text be the way to go?

Either you do:

Code:

---

someOtherPath = filepath + std::wstring(SLASH) + Additions[i];

---

Or

Code:

---

someOtherPath += filepath;
someOtherPath += SLASH;
someOtherPath += Additions[i];

---

I believe for the + operator to work, the left-most variable being added (i.e. filepath) needs to be a std::wstring.

Unless there's a free operator + which takes const wchar_t* and std::wstring.
I don't know it this is the case, however.

I don't know enough about C++ to give a definite answer, but the following compiles on GCC. Only the commented-out line produced an error for me.

Code:

---

#include <string>

int main() {
    std::string r, s = "s";
    const char *c = "c";

    r = s + c;
    r = c + s;
    r = s + c + s;
    r = c + s + c;
    r = s + c + c;
    //r = c + c + s;

    return 0;
}

---

They all work fine, as well.
The last line shouldn't work, as we know because the same problem exists in C (you can't add two pointers!).

Umm . . . what?

You can add and subtract pointers in both C and C++.

Code:

---

#include <stdio.h>
#include <string.h>

int main() {
    const char *start = "what";
    const char *end = strchr(start, 'a');

    printf("The 'a' in \"&#37;s\" is at index %i\n",
        start, (int)(end - start));

    return 0;
}

---

What Elysia meant, but did not say, was that you cannot add pointers at all, and can only subtract pointers when they both point to the same array (or one past the end of the array).

Yes, I guess I should have seen that.

Besides, I think I was wrong: you can't add pointers at all. I guess if I thought about it that would make sense . . . .

(Note: you can subtract two arbitrary pointers if you want to, but you'll get undefined behaviour. :) )

Who says you can't? :D
Here's two ways of doing it!

Code:

---

        const char* c = "c";
        const char* d = c;
        c = (const char*)( c - (const char*)-(int32_t)d );
        c = d;
        c = c + (uint32_t)d;

---

I admit, it's a hack, but it's possible (although technically, you aren't adding two pointers).
(Don't abuse it, though ;))

Drat, you can't use unary minus on pointers either. :(

Code:

---

#include <stdio.h>
#include <stddef.h>

void *negate(void *data) {
    void *p = 0;
    return (void *)-(data - p);
}

int main() {
    void *a, *b;
    a = &b;
    b = &a;

    printf("&#37;p\n", (void *)(a - negate(b)));

    return 0;
}

---

Note that ptrdiff_t is the type you get when you subtract two pointers, in C99 at least, and apparently you can negate that . . . .

Well, not in C++. But you can cast it to an integral type, negate it and cast it back. Of course, you'd have to do the actual subtraction first since a pointer can't be signed.

Hmm, interesting. I was fiddling with my program, and I came up with this:

Code:

---

#include <stdio.h>
#include <stddef.h>

ptrdiff_t negate(void *data) {
    void *p = 0;
    return -(data - p);
}

int main() {
    void *a, *b;
    a = &b;
    b = &a;

    printf("&#37;p\n", a - negate(b));

    return 0;
}

---

It looks like I managed to add two pointers, without using any casts! Am I missing something here?

Provided you don't use -Werror, I guess you're ok. (I got the warnings "pointer of type 'void *' used in subtraction" and "pointer of type 'void *' used in arithmetic", but then I have -pedantic turned on.) And I suppose it's a little bit of luck that negate does the right thing, but I would be surprised to be on a system where it didn't.

Edit to add: although g++ didn't compile the program at all -- "pointer of type 'void *' used in arithmetic" is an error, not a warning, to g++.

Quote:

---

Originally Posted by dwks

It looks like I managed to add two pointers, without using any casts! Am I missing something here?

---

Yes.

1) Undefined behaviour from subtracting the null pointer from a dereferenceable pointer.
2) As far as the compiler is concerned, you're not adding pointers. You're subtracting pointers, yielding an integer, and you're subtracting an integer from a pointer, yielding a pointer.
3) Why the complicated negate stuff?

Code:

---

int main() {
    int i, j;
    int *a, *b, *n = 0;
    a = &i;
    b = &j;

    printf("%p\n", a + (b - n));

    return 0;
}

---

If you're passing an integer type to printf, you should use &#37;x, not %p.

But the code is passing a pointer.

Quote:

---

Originally Posted by dwks

Hmm, interesting. I was fiddling with my program, and I came up with this:

It looks like I managed to add two pointers, without using any casts! Am I missing something here?

---

That's very C-ish. A c++ compiler would complain the instant you ran that program.
In C++, void** != void*. And it could probably turn up a few other errors, as well.

Quote:

---

Edit to add: although g++ didn't compile the program at all -- "pointer of type 'void *' used in arithmetic" is an error, not a warning, to g++.

---

Indeed. I only tried it with GCC . . . . I didn't even think try to it as C++, because I though ptrdiff_t was C99-only.

Quote:

---

In C++, void** != void*.

---

I know you hate command lines, but bear with me here.

Code:

---

$ cat ppvoid.cpp
#include <iostream>

int main() {
    void *a, *b;
    a = &b;
    b = &a;
    return 0;
}
$ g++ -W -Wall -ansi -pedantic ppvoid.cpp -o ppvoid
$

---

No warnings at all.

It's true that something like this is invalid

Code:

---

    void *p = 0;
    void **pp = p;  // error: invalid conversion from ‘void*’ to ‘void**’

---

but the code I used above compiles for some reason. Another thing:

Code:

---

    void ***ppp = 0;
    void **pp = ppp;  // g++ doesn't like this
    void *p = pp;  // but is fine with this

---

Anyway . . . .

Quote:

---

2) As far as the compiler is concerned, you're not adding pointers. You're subtracting pointers, yielding an integer, and you're subtracting an integer from a pointer, yielding a pointer.

---

That's true.

Quote:

---

3) Why the complicated negate stuff?

---

I have no idea. :)

You can convert any pointer to void* implicitly, even in C++.

It seems to accept any type, even void*** -> void*. Sillyness, really.
At least it could try to differentiate between pointer levels.
Oh well. It's not like we use void* in C++ very often.
(Yay for templates!)

Quote:

---

Originally Posted by Elysia

It seems to accept any type, even void*** -> void*. Sillyness, really.
At least it could try to differentiate between pointer levels.
Oh well. It's not like we use void* in C++ very often.
(Yay for templates!)

---

If you need to cast among unrelated pointer types, prefer casting via void* instead of using reinterpret_cast directly.

C++ casts are too long to type.

Quote:

---

Originally Posted by Elysia

C++ casts are too long to type.

---

The long names help them stand out. They shouldn't be used frequently, so typing a long name shouldn't be much trouble.

Quote:

---

Originally Posted by cpjust

If you need to cast among unrelated pointer types, prefer casting via void* instead of using reinterpret_cast directly.

---

Why? That link doesn't explain.

Quote:

---

Originally Posted by Elysia

C++ casts are too long to type.

---

Typing std::lexicographical_compare_3way is too long to type too, but that doesn't mean I'm going to avoid using it if I need it. :p

C casts are dangerous!
You can't easily search for all C casts, unless you search specifically for the type like (int*) (char*) (float*)...
You can't tell why the cast was needed with a C cast. Did they need to remove const-ness, did they need to convert between related types, did they need to cast between base and derived classes...?

Quote:

---

C++ casts are too long to type.

---

Like what King Mir pointed out, Stroustrup considers that a side benefit: "Maybe, because static_cast is so ugly and so relatively hard to type, you're more likely to think twice before using one? That would be good, because casts really are mostly avoidable in modern C++."

Quote:

---

Originally Posted by King Mir

Why? That link doesn't explain.

---

I don't think I fully understand it either; I just remember reading it in that book.
If anyone else here can explain what kind of danger the book is talking about, can you please enlighten us?

Quote:

---

I don't think I fully understand it either; I just remember reading it in that book.
If anyone else here can explain what kind of danger the book is talking about, can you please enlighten us?

---

The hard copy version of the book does not provide any elaboration either, but I believe that Sutter and Alexandrescu are concerned because "the mapping performed by reinterpret_cast is implementation-defined", and thus "it might, or might not, produce a representation different from the original value" (section 5.2.10 of the C++ Standard (2003)), whereas for static_cast, 'a value of type pointer to object converted to "pointer to cv void" and back to the original pointer type will have its original value' (section 5.2.9 of the C++ Standard (2003)).

Quote:

---

Originally Posted by laserlight

The hard copy version of the book does not provide any elaboration either, but I believe that Sutter and Alexandrescu are concerned because "the mapping performed by reinterpret_cast is implementation-defined", and thus "it might, or might not, produce a representation different from the original value" (section 5.2.10 of the C++ Standard (2003)), whereas for static_cast, 'a value of type pointer to object converted to "pointer to cv void" and back to the original pointer type will have its original value' (section 5.2.9 of the C++ Standard (2003)).

---

I was able to gather that much from the book, but what I'm not too sure about is how some types get messed up by reinterpret_cast so that they aren't equal to the original value if cast back again? An example of such a case and an explaination of what's happening would be helpful.

Quote:

---

Originally Posted by King Mir

The long names help them stand out. They shouldn't be used frequently, so typing a long name shouldn't be much trouble.

---

The problem is that I disagree with Bjarne's analogy "casts shouldn't be used so often." So I don't like go typing reinterpret_cast<char*>(something) everytime I need to cast something. I don't care what type it is I'm casting to or why.

Quote:

---

Originally Posted by cpjust

Typing std::lexicographical_compare_3way is too long to type too, but that doesn't mean I'm going to avoid using it if I need it. :p

C casts are dangerous!
You can't easily search for all C casts, unless you search specifically for the type like (int*) (char*) (float*)...
You can't tell why the cast was needed with a C cast. Did they need to remove const-ness, did they need to convert between related types, did they need to cast between base and derived classes...?

---

Yes, I know C casts are too dangerous (I do remember), but IMO, they brought this upon themselves by making C++ casts long and tedious.
As for me, I don't work in projects with multiple people so I haven't had any problems searching for casts or wondering why they're there.
I'm experienced with types and I know exactly what they do - so using C casts have never really been a problem for me.

Quote:

---

Originally Posted by laserlight

Like what King Mir pointed out, Stroustrup considers that a side benefit: "Maybe, because static_cast is so ugly and so relatively hard to type, you're more likely to think twice before using one? That would be good, because casts really are mostly avoidable in modern C++."

---

It also makes it a pain where you NEED to do it. Contrary to Bjarne, I do believe casts are more necessary than he admits and therefore I tend to use C-style casts, but use C++-style casts in examples.
I typically do use const_cast to get rid of const whenever necessary, too.

Quote:

---

Originally Posted by Elysia

The problem is that I disagree with Bjarne's analogy "casts shouldn't be used so often." So I don't like go typing reinterpret_cast<char*>(something) everytime I need to cast something. I don't care what type it is I'm casting to or why.

---

C++ is meant to be a type-safe language. What is it that you are doing that requires you to do away with this safety? Chances are if you find yourself having to use casts frequently, that there is something wrong with your approach.

The also long cast names serve as a yellow warning flag that something dangerous is going on.