I have a file that needs to use boost numeric bindings's library. How can I get that binding library?
The following link seems not able to work anymore. The zipped file is corrupted.
http://mathema.tician.de/dl/software/boost-numeric-bindings/
And I hope I could use it in Window and Visual Studio tool.
I have a file that needs to use boost numeric bindings's library. How can I get that binding library?
You can grab the sources of the current version via
svn co http://svn.boost.org/svn/boost/sandbox/numeric_bindings
The version from http://mathema.tician.de/dl/software/boost-numeric-bindings/ is an older version with a different interface. You can grab the sources of that older version via
svn co http://svn.boost.org/svn/boost/sandbox/numeric_bindings-v1
And I hope I could use it in Window and Visual Studio tool.
You need a blas/lapack library in addition to the bindings. For windows, Intel MKL, AMD's ACML, clapack and atlas used to work, last time I checked. (You only need one of these, but note that atlas only implements blas and a small subset of lapack). These libraries have widely different performance and license conditions, but they all implement the same interface (more or less).
In general, the people at http://lists.boost.org/mailman/listinfo.cgi/ublas seem to be helpful, if you try to use the bindings (or ublas) and run into problems. But I'm not sure if any of them checks here at stackoverflow for potential users that ran into problems.
Related
I've recently become interested in learning more about parallel computing, concurrency, etc. My main language is C++, so obviously I decided to use that in my personal studies.
After some research (read: looking things up on Google), I decided that using Intel's TBB library would be the most ideal.
The one thing that's got me stuck so far, though, is setting it up to use on my computer. I have looked on the Internet for some sort of tutorial on setting TBB up with MinGW (in my case, specifically Nuwen) and haven't really found anything.
So, here's my question: how would I set up TBB to use with a Nuwen distro?
TBB doesn't provides binaries for mingw in a Windows package. So you should build it from source code. You need compiler and GNU make;
Download source code(.zip) from https://github.com/01org/tbb/releases
Unpack somethere (not sure, but in common: beware of spaces in the dir path)
Open your console with compiler's environment, go to $archive_root/src and call gmake tbb tbbmalloc compiler=gcc. Also you could try to add stdver=c++11 in the build command if your complier supports this mode.
You will find a library build in the $archive_root/build/windows_... directory
I'm working on a large project, cross platform between Linux and OSx.
I'm would like to include boost functionalities, but I don't want to force all the the collaborators to install on their machine (with totally different environment) all the boost libraries.
If I compile boost on my machine, and put the static libraries inside the repository, which problem could I face? Can my colleagues use the same static libraries on their environment?
AFAIK there will be difference. The static libraries are not the same on OS X and Linux. Also compilation depends on toolset (see boost guide). And there can be issues if IDEs are different.
However you can compile both versions from one platform (see Cross-compilation) and put them in repository, but putting binary objects is not the best idea (even if they don't depend on platform).
I think you could try to compile and link boost on different platforms, maybe you will succeed, but you can not cover all the scenarios for sure. It is better to create boost compilation script and tell everyone to use it.
I want to use Boost.Thread library in a C++ software that I'm developing.
Since I'm a complete newbie in C++, I would like to know if there are any differences between:
Downloading and building Boost manually for MSVC9-x64
Using a pre-built package: http://boost.teeks99.com/
Option 1 seems so painful...
As far as I can tell, these are the default builds and not from patched or tweaked sources or anything.
If you take care to use the correct version of binaries for your application target and version of VC (including service packs) and link against the correct libraries (shared, static CRT, debug, etc.) you should be absolutely fine.
Also, since it seems that these packages don't contain Boost headers, you must take care to get and use the correct version of headers.
Concerning the "differences". Boost is a large and complex collection of libraries. For a software of that size, it has a quite simple and straightforward build process, but still, there are many options and customizations you can do when building Boost (e.g. you can build Boost.Iostreams with or without zlib and bzip2 support, build Boost.Regex with or without Unicode support, build Boost.Python against different versions of Python, and much more.) When you build Boost, you have control over these options.
The defaults work for most people, but some people may need certain customizations. You might want a specific version of a specific optional dependency, or a certain library built a certain way. For that, you probably will need to build Boost yourself and maintain the build throughout your project. This is not a scary task!
If you don't have any special requirements, then a generic build would most probably be fine for you.
I made a small program with Boost in Linux 2 yrs ago. Now I want to make it work in Windows. I found there are few .a files in my libs folder. I am wondering how to make it works in Windows? do I need to build Boost in Windows to get library or I can download somewhere? I am using Visual Studio 6.
Yes, you'll need to recompile for different platforms. Coincidentally, I posted instructions on this not long ago.
I hugely recommend you do not use Visual Studio 6. It's very dated, and terribly non-conforming. You can get the newer versions for free, as Express. You won't be missing anything.
Many boost libraries are header-only, you don't need to link against anything to use them. Libraries such as boost::filesystem require you to build libs appropriate for your platform and link against them.
Precompiled boost for MSVC7,8,9 can be found here (in the hope that you follow GMan's advice and get rid of VS6 …)
.a files from Unix are like .lib files in Windows. They will not work, and there is no way of "converting" them, short of using a compiler on the original source code.
However, Boost does build on Windows. Just download it (or more likely, the closest version you can find to the one your code was using).
Older versions of Boost did work under VS6, but with a whole lot of stuff disabled (VS6 really just barely qualified as a C++ compiler). If you can, I highly suggest you use a newer version of Visual Studio.
You have a few options. Building Boost will give you the greatest flexibility in working with your application and boost libraries. However, you can download pre-built Boost libraries wrapped up in a nice windows installer here, Boost Packages
But one thing to keep in mind, depending on what you used in Boost, a lot of it is template based so no libraries are required. If you're only using some templatized portions, you don't need to worry about any of this. Just make sure you have boost in your include path when building.
As a side note, you can get free but limited versions of newer MS compilers here: http ://www.microsoft.com/exPress/
I'm regularly running into similar situations :
I have a bunch of COM .DLLs (no IDL files) which I need to use and invoke to be able to access some foreign (non-open, non-documented) data format.
Microsoft's Visual Studio platform has very nice capabilities to import such COM DLLs and use them in my project (Visual C++'s #import directive, or picking and adding them using Visual Basic .NET's dialogs) - and that's the vendors recommended way to use them.
I would be interested into finding a way to use those DLLs on non-microsoft development platforms. Namely, using these COM classes in C++ project compiled with MinGW or Cygwin, or even Wine's GCC port to linux (compiles C++ targeting Win32 into binary running natively on Linux).
I have got some limited success using this driver, but this isn't successful in 100% of situations (I can't use COM objects returned by some methods).
Has someone had success in similar situations ?
Answering myself but I managed to find the perfect library for OLE/COM calling in non-Microsoft compilers : disphelper.
(it's available from sourceforge.net under a permissive BSD license).
It works both in C and C++ (and thus any other language with C bindings as well). It uses a printf/scanf-like format string syntax.
(You pass whatever you want as long as you specify it in the format string, unlike XYDispDriver which requires the arguments to exactly match whatever is specified in the type library).
I modified it a little bit to get it also compile under Linux with WineGCC (to produce native Linux elf out of Win32 code), and to handle "by ref" calls automatically (stock disthelper requires the programmer to setup his/her own VARIANT).
My patched version and patches are available as a fork on github:
https://github.com/DrYak/disphelper
And here are my patches :
patch for single source
patch for split source
The problem with the Ole/Com Object Viewer packaged with Visual Studio and Windows SDKs is that it produces a broken .IDL out of the .DLL, which can't further be compiled by MIDL into a .H/.CPP pair.
Wine's own reimplementation of OleViewer is currently unstable and crashes when trying to use those libraries.
I think you should be able to use the free tool Ole/Com Object Viewer to make the header files.