- Boost - lists.boost.org

Re: [boost] Boost and pkg-config support
by Vladimir Prus 01 Mar '11

01 Mar '11

On Sunday, February 27, 2011 23:08:42 Roger Leigh wrote: > Hi Steve and Vladimir, > > I know you're both really busy, so if you haven't got time for this > right now, don't worry. However, this is becoming increasingly > important. It was previously a nice to have; with new GCCs, it's > going to become rather more essential if one wishes to have any > hope of proper linking and support more than one Boost release. > > With --as-needed in GCC making linking much stricter, knowing > which Boost libraries need linking in is becoming much more of > an issue, especially since you can't rely on indirect linking > doing the right thing. You are required to know *all* the libraries > you need to link with in advance--and this can change with Boost > versions, and we have no hope of being able to do this reliably without > the same level of support that auto-linking provides Windows users with > suitable compilers. Could you brief me on what's --as-needed, why is it needed, and why does it break a perfect model of "I link to shared library foo, and whatever dependecies are used automatically". > https://svn.boost.org/trac/boost/ticket/1094 > is the upstream ticket for adding pkg-config support. I've already > done the bulk of the work, the patches are all there. Do you have > any knowledge of bjam? I don't, and the missing part is integrating > the patch with the build system. This is probably trivial if you > have any idea how bjam works, but I don't have the first clue. I had > a good look, but after several hours I'm still no wiser, so it would > probably be a much more effective use of time and effort for someone > with working bjam knowledge to do the last bit. With the patches in > the ticket, bjam just needs telling how to spit out and install the > pkg-config .pc files. > > auto-link-pkg-config.2.patch is the header patch to supply us with > the needed library dependency information. > > boost-pkg-config-gen.cc is the program to acquire the information > and generate the .pc file. It just needs building with these defines: > TEST_HEADER - the header to include for a given boost library > PREFIX - the bjam prefix (however you get at it) > LIBDIR - the bjam libdir (however you get at it) > So the program just needs building and running once for each Boost > library (bjam must have a list of libraries, or at least provide some > means for us to get at the information). Then those files just need > installing in $prefix/lib/pkgconfig and the job is done. Oh, using autolink headers to extract dependency information is cute. > If you wish > to support cross-compiling, this could be done by a script post-install. Well, this is obviously somewhat messy. Another alternative approach is to have dependency information extracted by Boost.Build -- which obviously knows what other libraries any given one is linked to. However, I still would like to understand why this is becoming more important now. For all I could tell, with our current naming scheme (without compiler and other decoration in library name), and with dynamic linking, you should be able to just say -lboost_whatever and it should work. What am I missing? - Volodya

2 2

[local] What do you think of the new syntax?
by Lorenzo Caminiti 28 Feb '11

28 Feb '11

Hello all, Before I spend 2+ weeks updating Boost.Local docs... can you please express an opinion about Boost.Local new and simplified syntax? If variadic macros are supported by your compiler: #include <boost/local/function.hpp> #include <iostream> int main() { double sum = 0.0; int factor = 10; void BOOST_LOCAL_FUNCTION_PARAMS(double num, const bind factor, bind& sum) { sum += factor * num; std::clog << "Summed: " << sum << std::endl; } BOOST_LOCAL_FUNCTION_NAME(add) add(100.0); return 0; } On all compilers (with variadic macros or not): #include <boost/local/function.hpp> #include <iostream> int main() { double sum = 0.0; int factor = 10; void BOOST_LOCAL_FUNCTION_PARAMS( (double num) (const bind factor) (bind& sum) ) { sum += factor * num; std::clog << "Summed: " << sum << std::endl; } BOOST_LOCAL_FUNCTION_NAME(add) add(100.0); return 0; } See also http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/index.html… Thanks a lot. -- Lorenzo

5 4

[filesystem v3] [iostreams] [interprocess] no windows access to memory mapped file
by Jeff Flinn 28 Feb '11

28 Feb '11

Filesystem V3 does a great job of handling unicode/utf8 paths in a windows/posix independent manner. boost::interprocess::file_mapping's constructor takes a raw const char* and explicitly calls CreateFileA to get a handle to a memory mapped file disallowing access to paths with non-ascii characters. boost::iostreams::mapped_file has a 7 month old ticket #4485 outlining the problems using it with filesystem V3. There is some path width switching logic that dispatches to CreateFileA or CreateFileW when the mapped_file is constructed with a filesystem V2 wpath. I tried faking things out by creating a wpath class in the filesystem namespace, but gave up and created a mapped file class for windows that uses filesystem::path and CreateFileW. I posted the issue with interprocess and Ion was of the opinion that this shorcoming needs to be addressed. I'm not sure if Steven is maintaining iostreams, or if he has given thought to how to address the iostreams implementation. My opinion is that boost libraries using paths in their interfaces should be using filesystem v3 paths. Beman, I think, suggested in the recent utf8 thread that boost libraries should use the wide version of the windows api passing path.wstring().c_str() where appropriate. Do others have thoughts on this issue? Are the windows wide api usage part of boost guidelines? Should they be? Thanks, Jeff

4 5

[config] help with pathscale-4.x
by Belcourt, Kenneth 28 Feb '11

28 Feb '11

Hi John, Any chance you can take a look at the attached configure generated user.hpp and recommend changes to Boost.config for supporting the Pathscale compiler? -- Noel Belcourt

2 4

[Gauge for interest] Surrogate template
by Alan sinde 28 Feb '11

28 Feb '11

Hi all, Recently I've an surrogate/proxy pattern implemented for storing related type as value. It is based on chapter 5 of Rumination on C++ by Andrew Koenig and Barbara moo. Original version required stored object to define their own virtual copy constructor. I have updated it to template version. Besides, it also relief user from defining virtual copy constructor by moving virtual copy inside surrogate. Thanks to template constructor making this possible. Drawback: 1) Each copy construction of surrogate incurs 2 virtual calls instead of 1 in the original. 2) Object compositing surrogate that has interface taking derived class must change to template member function in order to use template constructor of surrogate. Does anybody interested to include it as boost::surrogate? Example Usage: class boy { public: virtual void tell() = 0; }; class happy_boy : public boy { ... }; class study_boy : public boy { ... }; void say_hi(boy& the_boy) { the_boy.tell(); } int main() { std::cout << "Hello boost::surrogate!" << std::endl; happy_boy Terry; study_boy Thomas; std::vector<boost::surrogate<boy> > boy_list; boy_list.push_back(boost::surrogate<boy>(Terry)); boy_list.push_back(boost::surrogate<boy>(Thomas)); std::for_each(boy_list.begin(), boy_list.end(), say_hi); std::cin.get(); } Regards, Alan Tong

3 4

[GSOC] Coding on Boost for GSoC
by Erwann Gentric 28 Feb '11

28 Feb '11

Hello, As a French student preparing a Master in computer science, I'm highly motivated about coding on Boost C++ for the Google Summer of Code. I'm interested in the "Checks and Hashes" part in particular, and I would like to contact developers in order to specify my project, identifying what I'm expected to do, and to learn more about programming on Boost. Thanks! -- Erwann.

2 1

[interprocess] sharing memory between 32 bit and 64 bit Windows processes
by Arno Schödl 28 Feb '11

28 Feb '11

Hello Ion, ticket #5230 is the patch against the current development head. It would be great if you could review it soon. Our currently shipping product crashes on customer machines, and the patch may rot pretty quickly because there are so many size_t/ptrdiff_t -> size_type/difference_type replacements... Feel free to call if you want a quick answer to a question. Thanks! Arno -- Dr. Arno Schödl | aschoedl(a)think-cell.com Technical Director think-cell Software GmbH | Chausseestr. 8/E | 10115 Berlin | Germany http://www.think-cell.com | phone +49 30 666473-10 | US phone +1 800 891 8091 Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl

2 2

[move] missing in 1.46
by Oliver Kowalke 28 Feb '11

28 Feb '11

I'm still missing boost.move in the current release (it was accepted in may 2010)! Should I use in the meanwhile <interprocess/detail/move.hpp>? Oliver -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl

4 5

Filename length limit for Boost library
by Edward Diener 28 Feb '11

28 Feb '11

In the "Boost Library Requirements and Guidelines Page" in the "Directory Structure and Filenames" topic, it says: 'The maximum length of directory and file names is 31 characters.' and the rationale is: 'We had to draw the line somewhere, and so the limit imposed by a now obsolete Apple file system was chosen years ago. It still seems a reasonable limit to aid human comprehension.' I do not think that there are any real OSs that impose such a limit anymore and would like to see this limit lifted. I have already hit this limit many times, especially in naming test files for my sandbox libraries. I would rather create filenames which described well what a file is about rather than have a 31 character limit for a filename, which is not only highly arbitrary, but almost certainly obsolete in this day and age.

2 2

Rave for proposed Boost.Local (functions)
by Gregory Crosswhite 27 Feb '11

27 Feb '11

Hey everyone, The purpose of this e-mail is to rave about Lorenzo's proposed Boost.Local library in the hopes of inspiring people to start the review process for it. :-) I have been experimenting with using this library in my own code, and it has been a godsend for me. In one of the projects I have been working on I ran into many situations where I needed to call a higher-order function with a closure, and the closure was just complicated enough that I couldn't use Boost.Lambda. Before using this library I frequently found myself either writing a lot of extra code to work-around the need for a higher-order function, or writing a lot of boilerplate to create classes that would only be used by a single function in order to create a function object. This library has let me write the closures that I need in a fairly painless fashion and so has made my life a lot easier! At first I thought that the interface needed to use it was ugly, but as I have gotten used to it I have changed my mind. Part of why I thought it was ugly was because of the way that whitespace was used in the example included in the original e-mail: BOOST_LOCAL_FUNCTION( (void) (add)( (double)(num) (const bind)((factor)) (bind)((&sum)) ) ) { sum += factor * num; std::clog<< "Summed: "<< sum<< std::endl; } BOOST_LOCAL_FUNCTION_END(add) add(100.0); To my mind this example looks a lot clearer if you reformat it as follows: BOOST_LOCAL_FUNCTION( (void) (add)( (double)(num) (const bind)((factor)) (bind)((&sum)) ) ) { sum += factor * num; std::clog<< "Summed: "<< sum<< std::endl; } BOOST_LOCAL_FUNCTION_END(add) add(100.0); I would be happy to volunteer to be the review manager if one is needed to move the process along, but since I am new to the community and personally biased in favor of the library (though I would endeavor to be unbiased as a reviewer) I recognize you all will presumably want someone that you all know better and who is more neutral. Regardless, I hope that we can start down the road of incorporating this library into boost because I believe it would be of great benefit to the C++ community at large. Cheers, Greg

13 59