Compile issues

Here’s some depressing c++ crapola I can’t fix:

1-

CPreGame.cpp: In member function ‘int SelectionTab::getLine()’:
CPreGame.cpp:802: error: ambiguous overload for ‘operator-=’ in ‘clickPos -= ((SelectionTab*)this)->SelectionTab::<anonymous>.CIntObject::pos.Rect::topLeft()’
GUIBase.h:93: note: candidates are: Point& Point::operator-=(const T&) [with T = Point]
../global.h:185: note:                 bool vstd::operator-=(Container&, const Item&) [with Container = Point, Item = Point]

That line in global.h is causing it:

using vstd::operator-=;

2-

../hch/../lib/NetPacks.h: In member function ‘void TradeComponents::serialize(Handler&, int)’:
../hch/../lib/NetPacks.h:703: error: ‘id’ was not declared in this scope

I don’t see where ‘id’ could come from, nor how vc++ can compile that code. :imp:

It’s simple. TradeComponents is not used anywhere so TradeComponents::serialize is checked only for syntactic correctness (only bracket + ‘’ and “” matching IIRC). Here is a more intriguing example of what vc++ accepts in templates without instantiation:

template<typename T> void foo(int g)
{
	return 5 ,, yeah! <> {}()(<)><> <- brackets match, so everything's' fine till instantiation
}

So #2 is easy to fix.

I just can’t find the right expletive to describe what I think of C++, the people who designed it and those who write the compilers :unamused:

The operator-= clash is a bit troublesome, since you cant undo using directives. I don’t see why gcc doesn’t want to go with Point::operator-= but it was possible to rewrite x -= y as x = x - y. Couldn’t get around it in any other way.

That’s the difference between G CC and MSVC. The second parses the template fully only if it’s instantiated. I don’t know what standard says about that but I find VC behaviour very useful.
Template functions must be defined in the headers. That functions often need to operate on symbols not defined in that header. G CC (parsing and checking all symbols in template) enforces putting includes in includes which leads to the terror of include-hell. With MSVC you need to include necessary files only in compilation units that instantiate the template.

Well, then we have to replace one operator-= with function or another operator.

New one:

GUIClasses.cpp:5537: error: ‘const struct std::basic_string<char, std::char_traits<char>, std::allocator<char> >’ has no member named ‘front’
GUIClasses.cpp:5537: error: ‘const struct std::basic_string<char, std::char_traits<char>, std::allocator<char> >’ has no member named ‘back’

line is a string. front() and back() are a vector thing. Is windows basing the std::string on std::vector ?

No, it’s not. At least for me. But this is one of C++0x extensions to basic_string implemented in Visual C++ 2010. See open-std.org/jtc1/sc22/wg21/ … /n3092.pdf page 622.

I’ll never understand MS. They still haven’t a c99 compiler, but they’re implementing a not yet released C++ spec. Oh well!
And g++ doesn’t have it yet. Can someone write an alternative code ? If I do it, I won’t use the right API.

Actually this: gcc.gnu.org/onlinedocs/libstdc++ … tatus.html suggests that C++0x string are implemented in libstdc++. Anyway, we shouldn’t explicitly use any C++0x feature in our code.

BTW, I think .front() can be replaced with [0] and .back() can be replaced with [line.size()-1].

Actually GCC implements much more of that unreleased spec. I think adding a few C++0x language features and simple extensions to standard library is not the worst thing Microsoft did.

Thanks. I’ve made the change in the tree.

Sorry for trouble. I’ve allowed IDE suggestion to mislead me.

There is very little interest in C99. I don’t see why one would want to use pure C99 if C++ (that contains many features of C99) is available. The primary reason to use C is its portability (C compiler available on countless amount of platforms) that C99 doesn’t provide neither.

May my current build errors (SVN rev. 1671) have something to do with this?
pastebin.com/E9rgf0bp

Not really. It’s a missing include:

../hch/CObjectHandler.h:14:33: error: ../lib/CCreatureSet.h: No such file or directory

Then I’m sorry for hijacking this thread. Still, the file is available in SVN as well as in my local copy. In fact all the “missing” files are there, so I thought there has to be another problem. I double checked the permissions, and now am going to reread the log. Hope I’ll find it.

Do you eventually have another idea?

Thanks,
Daniel

Just that shows there is something wrong with your debian package.

distclean should be present in all Makefiles.

And something is wrong there too:

You’re in the lib directory, and …/lib is also that directory, yet it doesn’t find the file !?

I’m not sure, but this is the clean section in my debian/rules:

clean:
        dh_testdir
        dh_testroot
        rm -f build-stamp 

        # Add here commands to clean up after the build process.
        -$(MAKE) distclean
ifneq "$(wildcard /usr/share/misc/config.sub)" ""
        cp -f /usr/share/misc/config.sub config.sub
endif
ifneq "$(wildcard /usr/share/misc/config.guess)" ""
        cp -f /usr/share/misc/config.guess config.guess
endif


        dh_clean

The question is: What changed in the SVN since revision 1613 that could have messed this up. 1613 worked with the same debian files without changing anything… Guess I might have to try revision by revision. :frowning:

EDIT: Revision 1668 seems to mess it up, but I need revision 1669 to get rid of the front/back error described by ubuntux…

I reverted 3 changes ( pastebin.com/FfmeW1qi ) and now I’m back to that previous (post rev 1613) linker error. libboost_thread is not linked or not linked correctly.

See pastebin.com/GQxhf7Tt

The revert was quite massive, but I could not find the real problem, so I reverted all changes that were made to the files giving me the errors. One could probably track it down to a single line, but I don’t know the code at all. :confused:

Any idea where I’d have to add libboost_thread to make it work again? It worked out of the box in rev. <= 1613…

Daniel

EDIT: I found out that revision 1617 adds the linker errors for me. Hope I may find the actual problem.

EDIT2: Ok, it has to be somewhere in lib/Connection.cpp or lib/Connection.h. Guess I’m stuck here, can’t figure what it could be. Would I have to manually link any library because of the new includes? What boost library makes boost/any.hpp use of?

The problem is not with the debian/rules file. It is with the Makefiles that are generated. All Makefiles should have the distclean rule. Something messed up with the Makefiles. Fix that error first and may be that will fix the others (even if they seem unrelated).

I think the problem regarding the distclean rule is not that important. It worked before and I don’t see any change in revision 1617 that could mess up the Makefile? Or am I wrong? I just don’t want to spend time learning how to add that distclean rule even though I compile it from scratch anyways, and the linker errors probably won’t disappear.

Don’t get me wrong, I very much appreciate your help, I just guess this distclean error is caused my heavily outdated build tools and environment. If you don’t get it on your system, this is even more likely. I didn’t change any file outside of the debian/ dir, so it is probably caused by old tools.

If it was caused by the Makefile, why was it working in <= 1616?

I’ll still have a look into the distclean thingy, tho it seems not to be documented too well (from my first quick search). Hope you have another guess while I do so. :slight_smile:

EDIT: It’s weird but this seems to be completely auto generated. I can’t find any site that tells you what to change to make distclean work. Any chance you could give me a hint?

Yes, the distclean rule is autogenerated. It’s coming from Makefile.am (in your case it’s AI/Makefile.am). The configure tool generates the Makefile fromMakefile.am, in all the directories. One thing to do is to look at the generated makefile after the failure, and find out why the distclean rule is not there.