Possibly not in the default c++ language mode, but check out -fwhole-program-vtables. It can be a useful option in cases where all relevant inheritance relationships are known at compile time.

https://reviews.llvm.org/D16821

Which is good, but may not apply. I have an application where I can't do that because we support plugins and so a couple classes will get overridden outside of the compilation (this was in hindsight a bad decision, but too late to change now). Meanwhile most classes will never be overriden and so I use final to saw that. We are also a multi-repo project (which despite the hype I think is better for us than mono-repo), another reason why -f-whole-program-vtables would be difficult to use - but we could make it work with effort if it wasn't for the plugins.

I think the callee expects the return address in %rbp, and by System V convention will pull certain arguments from above %ebp on the stack.

This might not help, but it's an interesting article on stack frames for all interested: http://eli.thegreenplace.net/2011/09/06/stack-frame-layout-o...

Looks like fastcall, or any convention on x86_64.

I think you can do bound functions if you do callee-cleanup, then your intermediate bound trampolines can just jmp and you don't end up with (too many) weird problems. But it means that the final return address ends up at the bottom of the stack, rather than at the top, like it would with a conventional push/call system.

In any case it looks like cdecl is out of the question.

Some further discussion in a slightly different context, if you're interested: http://stackoverflow.com/questions/11271848/implementing-bou...

Brilliant.

### An Update

SICP will not be abandoned at Berkeley.

Although Python will be used to convey the material, I have been assured that much of the content from SICP will be preserved.

I recognize now that CS61A is a fusion of sorts: an exciting modern treatment of traditionally intellectual material. This change reflects concerns about the difficulty of SICP, the popularity of Python, and a general lack of interest on the part of students and teachers in Scheme. Fair enough. I think this is the best possible solution for an introductory course, but that's just my opinion.

I want to reiterate that I mean Berkeley or its professors no disrespect, and that I only raised this issue because I was concerned about a potentially drastic shift in the curriculum.

I can't begin to thank you all for your comments, criticism, emails, and interest. It's made a world of difference.

Reading the last email was gratifying and cathartic. I used to have experiences like this on Windows all of the time. There's some savage pleasure in knowing that Bill Gates had to put up with stuff like this too.

The install.sh and install_script.sh scripts are Mac-dependent. How would you compile this on Linux? Qmake?

edit: Yep. Clone the git repo, then run qmake, followed by make.

edit #2: Here is a patch I wrote to make the project compile under OpenCV 2.2, and Linux: https://gist.github.com/999061

Even after applying your patch I had a little trouble getting everything to link properly on x86_64 Fedora (14). I ended up manually tweaking my make files after running qmake.

Changed the LIBS line (in MLDemos/Makefile, _AlgorithmPlugins/<n>/Makefile.<n>, _IOPlugins/<n>/Makefile.<n>) to:

LIBS = $(SUBLIBS) -L/usr/lib64 -L/usr/local/lib -lhighgui -lcv -lcxcore -lQtGui -lQtCore -lpthread

I suspect there's an easier way, but this at least allowed me to build and everything seems to work properly.

I'm glad it built.

I think the issue we're all having stems from the structural redesign of opencv 2.2. Everything has been split up into smaller headers, and the functionality is similarly separated into different shared libraries. It's a more logical code structure, but it means that we need to have different makefile rules for pre-2.2 and 2.2+ code.

As far as -lhighgui -lcv -lcxcore is concerned, those libraries don't exist on my machine anymore. "highgui" is "/usr/lib/libopencv_highgui.so", and so on. That would explain why my 'fix' didn't work for you.

Here's a patch that lets you compile with opencv2: https://gist.github.com/999061.

edit: I'm still getting a Make error for cvSumPixels (unless I comment that check out);

sampleManager.cpp:(.text+0x1a06): undefined reference to `cvSumPixels'

you might need to add #include <opencv2/legacy/legacy.hpp> #include <opencv2/legacy/compat.hpp> to get those I haven't gotten around to porting it to opencv2.2 so the patch is very welcome!

Good call. I added those headers and linked to their related libraries. It's working perfectly on my Arch install.

Here are my modifications; https://gist.github.com/999427

Yeah, the install(_script).sh are to allow deployment on the Mac (which wants absolute paths to libraries). They will need to be changed to direct to the local libraries in case you need them... (hopefully a new version of MacDeployQt will appear at some point to take care of all that)