This seems like a non-argument. After all myobj == "something" is still valid using a non-member equality operator; you're not forced out of your habit. There isn't a logical problem with "something" == myobj either.

Maybe the problem is that the operator '+=' does not exist. You might think it does, but only its template exists. What if you try specializing the template function with the type of 'test' ?
(I might be wrong on this)

Further, you might consider using

1) only one template argument for the operator, which then calls a function in a template class. Simple reason: function templates cannot have (yet) default arguments, while template classes can.

or,

2) don't use the trait as template parameter. Simply parametrize the trait by the first parameter and use the type in the trait as the return type.

Note that the 'typename' is necessary to overcome a language ambiguity: do you use the trait as you defined earlier, you mean the static variable. Then don't use 'typename'. Do you use the trait as I suggested, then use 'typename': you mean the type.

(From inside class.)
If not specified, the code won't compile (compile error).
And if they do exist, it will give linking error - or in other words, they seem to refer to a function that does not exist.

Last edited by Elysia; 05-10-2008 at 10:30 AM.

Originally Posted by Adak

io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.

Originally Posted by Salem

You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

But the operator= is not defined yet! That you do lateron. So don't use '*this = strData' , but copy data members one-by-one. Then it works on my machine!

Further, I really really think you should not derive from your structs, because
1) it does not satisfy at all the Liskov substitution principle (just learned, but very useful)
2) it isn't a trait, and if it was so, traits are always template parameters.

You'd better have a composition: make a private/protected object of it in your string class.

But the operator= is not defined yet! That you do lateron. So don't use '*this = strData' , but copy data members one-by-one. Then it works on my machine!

I don't think that really matters because operator = is defined later (and besides, the definition comes first, so the compiler knows there is an operator =). Plus before breaking out the operators, the code passed every test in the suite, so it's in no way wrong.
But does it matter if it's inherited, just placed as an object or the members just made static so I can access them as a namespace? I did the latter, because it seems more efficient (I only need one instance of every member of the trait class).

Here's in the newest code I'm trying with.

Last edited by Elysia; 05-10-2008 at 11:40 AM.

Originally Posted by Adak

io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.

Originally Posted by Salem

You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

What compiler are you using? I guess a Microsoft compiler, which is known to accept more than the gnu or sun compilers/linkers. I'm using g++-4.3 . Sometimes it gives errors in very early stages, preventing difficult to track errors lateron.

Can you attach a simplified library with only one friend function which causes the error?

VS's default compiler is what I use. 2008 edition, so it's top of the line.
I'll attach the dumbed down class. Just remove all the comments if you want to shrink it in size.
Construct an object, then add a string literal +=, and you will get either a linking error or ambiguous error (I left two += operators there, you can check them).

Originally Posted by Adak

io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.

Originally Posted by Salem

You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

This code... has so very much wrong with it. The code... the concepts... ;_;

Eventually I just decided to post the code as fixed rather than waste time telling you everything, but I highly suggest you read everything with extreme care: unless I missed something every single change is crucial to successful compilation.

You also should probably get a good stingy C++ compiler. Obviously whatever you are using isn't informing you of all the problems that it should be telling you about.