[Regex] Building Boost.Regex with ICU
Hello, I'm trying to build some basic Boost.Locale Jam file on base of Boost.Regex one, however... I can't even build Boost.Regex with ICU at all. Version 1.43 ------------ Debian, ICU 3.8 installed in regular place /usr/lib/libicu*.so Build: bjam -d+2 -sHAVE_ICU=1 stage Shows that the build is done with ICU (i.e. -DBOOST_HAS_ICU=1 in command line of gcc) However when afterward I check ldd stage/lib/libboost_regex.so It shows no evidence of linking with ICU. Version 1.44 ------------ Build: bjam -d+2 -sHAVE_ICU=1 stage Shows that the build is done without ICU! i.e. -DBOOST_HAS_ICU=1 in command line of gcc is NOT defined. And of course ldd shows the same Even if I specify bjam -d+2 -sHAVE_ICU=1 -sICU_PATH=/usr stage Or try to use ICU4.4 installed on other location bjam -d+2 -sHAVE_ICU=1 -sICU_PATH=/opt/icu44 stage Same result. I don't understand how can I actually get the library (especially recent) built with ICU. Artyom
I'm trying to build some basic Boost.Locale Jam file on base of Boost.Regex one, however... I can't even build Boost.Regex with ICU at all.
Version 1.43 ------------
Debian, ICU 3.8 installed in regular place /usr/lib/libicu*.so
Build:
bjam -d+2 -sHAVE_ICU=1 stage
Shows that the build is done with ICU (i.e. -DBOOST_HAS_ICU=1 in command line of gcc)
However when afterward I check
ldd stage/lib/libboost_regex.so
It shows no evidence of linking with ICU.
Does the linker command show that it's being linked to ICU? Come to that if the compiler command line has BOOST_HAS_ICU set, then you *will* get compiler errors if it's not being built against ICU. Stupid question, but are you sure that you're looking at the correct binaries?
Version 1.44 ------------
Build:
bjam -d+2 -sHAVE_ICU=1 stage
-sHAVE_ICU has no effect in 1.44 - it should detect and configure it automatically. When you build there should be a message something like: Performing configuration checks - has_icu builds : no And if you see a "no" here then look in bin.v2/config.log to see the actual error messages that caused the configure check to fail. HTH, John.
Does the linker command show that it's being linked to ICU?
No. Libraries are not given during linking command
Come to that if the compiler command line has BOOST_HAS_ICU set, then you *will* get compiler errors if it's not being built against ICU.
Not under ELF platform. Unlike with DLLs, you can create shared objects with undefined symbols, you'll discover this when you'll try to link libboost_regex.so to some executable. i.e. this is legal. test.c void foo(); void bar() { foo(); } gcc -shared -fPIC test.c -o libtest.so
Stupid question, but are you sure that you're looking at the correct binaries?
Yep. stage/lib/libboost_regex.so
Version 1.44 ------------
Build:
bjam -d+2 -sHAVE_ICU=1 stage
-sHAVE_ICU has no effect in 1.44 - it should detect and configure it automatically.
When you build there should be a message something like:
Performing configuration checks
- has_icu builds : no
No, this message is not shown. I had also forgotten to mention one parameter that I add "--with-regex" as I want boost_regex only bjam -d+2 -sHAVE_ICU=1 --with-regex stage
And if you see a "no" here then look in bin.v2/config.log to see the actual error messages that caused the configure check to fail.
Ok I'll take a look on this file when I get home. Thanks, Artyom
Does the linker command show that it's being linked to ICU?
No. Libraries are not given during linking command
I would need the complete output to try and debug that, I don't understand how BOOST_HAS_ICU can be set, but the link libraries not be given on the command line.
Performing configuration checks
- has_icu builds : no
No, this message is not shown.
Then something is very wrong somewhere - are you using an up to date bjam executable? John.
Then something is very wrong somewhere - are you using an up to date bjam executable?
John.
Ok, indeed I was using bjam 3.1.16; once I build bjam 3.1.18 from 1.44 it works and ICU is detected and linked correctly even without explicit HAVE_ICU (and with it as well) My bad, thanks, Artyom P.S.: Maybe it would be useful to make some kind if assert if bjam version is too old or unsupported.
Thanks,
Can you please just write in few works what should I do. I want to continue with Boost.Locale Jam files development.
In theory just adding: path-to-boost-root/libs/regex/build//icu_options to the list of your sources for the library build should do the trick.... but you need to find out why the regex lib build isn't working for you first, HTH, John.
AMDG On 9/20/2010 8:42 AM, John Maddock wrote:
Thanks,
Can you please just write in few works what should I do. I want to continue with Boost.Locale Jam files development.
In theory just adding:
path-to-boost-root/libs/regex/build//icu_options
to the list of your sources for the library build should do the trick.... but you need to find out why the regex lib build isn't working for you first,
We should probably create a separate ICU module for Boost.Build if it's going to be used by more than one library. In Christ, Steven Watanabe
We should probably create a separate ICU module for Boost.Build if it's going to be used by more than one library.
Nod, I guess we need to add a "runtime configuration" section to Boost.Config. In the mean time, updated docs for ICU configuration with Boost.Regex are here: http://svn.boost.org/svn/boost/trunk/libs/regex/doc/html/boost_regex/install... Note that the --disable-icu option is specific to Trunk at this time. John.
Steven Watanabe wrote:
AMDG
On 9/20/2010 8:42 AM, John Maddock wrote:
Thanks,
Can you please just write in few works what should I do. I want to continue with Boost.Locale Jam files development.
In theory just adding:
path-to-boost-root/libs/regex/build//icu_options
to the list of your sources for the library build should do the trick.... but you need to find out why the regex lib build isn't working for you first,
We should probably create a separate ICU module for Boost.Build if it's going to be used by more than one library.
How about making a configure check for ICU be libs/config//icu ? - Volodya
We should probably create a separate ICU module for Boost.Build if it's going to be used by more than one library.
How about making a configure check for ICU be libs/config//icu ?
- Volodya
Or maybe just document or implement a functionality that allows to check existence and likability of generic library and generic header? (as I for example need iconv as well) Once time pass more and more Boost libraries would actually use 3rd part components as reinventing the wheel sometimes quite hard. My $0.02 Artyom
We should probably create a separate ICU module for Boost.Build if it's going to be used by more than one library.
How about making a configure check for ICU be libs/config//icu ?
- Volodya
Or maybe just document or implement a functionality that allows to check existence and likability of generic library and generic header? (as I for example need iconv as well)
Once time pass more and more Boost libraries would actually use 3rd part components as reinventing the wheel sometimes quite hard.
I did actually make a start at boiler plating all this so it works more like autoconf - take a look at the attached example - the thing to look at is the zlib example right at the end of the Jamfile - the rest of the Jamfile is the actual boilerplate plus some tests. Unfortunately there are still a few warts in the code but it should give you the general idea. Even so, if several folks are testing for the same thing, it still makes sense to centralize the tests. Cheers, John.
Or maybe just document or implement a functionality that allows to check existence and likability of generic library and generic header? (as I for example need iconv as well)
Once time pass more and more Boost libraries would actually use 3rd part components as reinventing the wheel sometimes quite hard.
I did actually make a start at boiler plating all this so it works more like autoconf - take a look at the attached example - the thing to look at is the zlib example right at the end of the Jamfile - the rest of the Jamfile is the actual boilerplate plus some tests. Unfortunately there are still a few warts in the code but it should give you the general idea.
Even so, if several folks are testing for the same thing, it still makes sense to centralize the tests.
Cheers, John.
Small note: Generally it is very simple to do a standard template like: int main() { return 0; } And it would fail if you would try to link with not-existing library, no need to specify anything unusual. You don't need to call any function explicitly. This is the way autoconf works. Artyom
Small note:
Generally it is very simple to do a standard template like:
int main() { return 0; }
And it would fail if you would try to link with not-existing library, no need to specify
anything unusual. You don't need to call any function explicitly. This is the way autoconf works.
Nod, and sometimes that works, but I've also been bitten by it not working: for example when checking for a C++ library you need to be sure that it's ABI is compatible with the code you're building, so actually linking against something tangible seems to be the correct thing to do. Cheers, John.
John Maddock wrote:
Small note:
Generally it is very simple to do a standard template like:
int main() { return 0; }
And it would fail if you would try to link with not-existing library, no need to specify
anything unusual. You don't need to call any function explicitly. This is the way autoconf works.
Nod, and sometimes that works, but I've also been bitten by it not working: for example when checking for a C++ library you need to be sure that it's ABI is compatible with the code you're building, so actually linking against something tangible seems to be the correct thing to do.
I think the important question here is what mode do we want. One mode is where you have a feature test as a .cpp file which tries to use "important" functions from a library, and then declare a Boost.Build metatarget that builds that .cpp and links to a library. In this case, if you modify the .cpp, the regular dependency checking will rebuild the test. Also, the test will be repeated if the system headers for the library change -- a particularly nifty example is including "whatever/version.hpp" and making some decisions based on version. Some changes to the way libraries are linked will allow the test to be rebuilt when a system library itself is modified. Another mode is where configure checks tries to compile or link something, and caches the result. One can remove the cache and run all checks again, but otherwise the system assumes nothing changes. I, personally, is not very happy with the second mode as implemented in cmake. However, it might be that the best mode depends on the nature of the test, and we need to support both. Comments? - Volodya
I think the important question here is what mode do we want.
One mode is where you have a feature test as a .cpp file which tries to use "important" functions from a library, and then declare a Boost.Build metatarget that builds that .cpp and links to a library.
What is important part. I noticed that in many cases when you try to do "better" checks and include part of code and test full compilability you find yourself with failed test for 101 other reasons. So, unless you really have very strict specification of what you need, just test of library can be linked or the header can be included. Or even just exists. Sometimes simpler (at least by default) is just better.
In this case, if you modify the .cpp, the regular dependency checking will rebuild the test. Also, the test will be repeated if the system headers for the library change -- a particularly nifty example is including "whatever/version.hpp" and making some decisions based on version. Some changes to the way libraries are linked will allow the test to be rebuilt when a system library itself is modified.
I'm not aware of any build system that does this. Even autoconf would not try to "refind" something if it has changed. Also in autotools there is a separation between configuration part (configure.in) and declaration part (makefile.am) so once you change configure.in all configuration steps are rerun.
Another mode is where configure checks tries to compile or link something, and caches the result. One can remove the cache and run all checks again, but otherwise the system assumes nothing changes.
Actually both autotools and cmake cache results as it is infeasible to reconfigure system after each change.
I, personally, is not very happy with the second mode as implemented in cmake.
The problem with CMake is the fact that it remembers positive checks that sometimes may be incorrect, all negative ones it checks each time. I'm not happy with it either, but I don't think that the approach suggested is feasible as well. For example: bjam - check if library can be linked? no - mark this. I install library and run build again: bjam the "missing" link is remembered and not checked. On other hand, you don't want to check all dependencies each time you run bjam as tests make take huge amount of time. So basically cmake's and auto*'s approach is quite similar even thou cmake's cache little bit more "preserving" for good and bad.
However, it might be that the best mode depends on the nature of the test, and we need to support both. Comments?
No I don't think you need to support all possible ways, just do a one way that works, well documented and consistent. ---------------- Small thing I noticed, Many build systems including BBv2 are very oriented on making "build" system very simple and straightforward. And indeed, in all of them (ok maybe not autotools) you can build simple project with 2-3 lines of code. What most of them missing is how to configure the system easily, how to perform fast and easy environment checks. In this way autoconf did very-very good job, CMake is quite good as well... My $0.02 Artyom
On Sep 21, 2010, at 4:41 PM, Artyom wrote:
On Sep 21, 2010, at 2:06 PM, Vladimir Prus wrote:
One mode is where you have a feature test as a .cpp file which tries to use "important" functions from a library, and then declare a Boost.Build metatarget that builds that .cpp and links to a library.
What is important part. I noticed that in many cases when you try to do "better" checks and include part of code and test full compilability you find yourself with failed test for 101 other reasons.
So, unless you really have very strict specification of what you need, just test of library can be linked or the header can be included. Or even just exists.
I can't even begin to describe how much I *hate* existence checks. They are the most common reason why *every* autoconf-based package I've ever needed to cross-compile has failed to correctly do so out of the box. I know that autoconf support for cross-compilation has improved significantly, but the people writing the configure.in's still have to use that support properly. My impression (from reading documentation, I've not actually used cmake yet) is that the cmake approach avoids at least some of that trap by making it a build error to have such a question be asked and not find an explicit answer in the cross-target configuration. Please, whatever solution is ultimately adopted, try to keep cross-compilation in mind during the decision process.
I think the important question here is what mode do we want.
One mode is where you have a feature test as a .cpp file which tries to use "important" functions from a library, and then declare a Boost.Build metatarget that builds that .cpp and links to a library. In this case, if you modify the .cpp, the regular dependency checking will rebuild the test. Also, the test will be repeated if the system headers for the library change -- a particularly nifty example is including "whatever/version.hpp" and making some decisions based on version. Some changes to the way libraries are linked will allow the test to be rebuilt when a system library itself is modified.
Another mode is where configure checks tries to compile or link something, and caches the result. One can remove the cache and run all checks again, but otherwise the system assumes nothing changes.
I, personally, is not very happy with the second mode as implemented in cmake. However, it might be that the best mode depends on the nature of the test, and we need to support both. Comments?
I'm not happy with the second mode either - if something in the source changes then the test should definitely be rebuilt - most users will presumably only build the thing once anyway during an install so it won't make any difference to them? John.
John Maddock wrote:
I think the important question here is what mode do we want.
One mode is where you have a feature test as a .cpp file which tries to use "important" functions from a library, and then declare a Boost.Build metatarget that builds that .cpp and links to a library. In this case, if you modify the .cpp, the regular dependency checking will rebuild the test. Also, the test will be repeated if the system headers for the library change -- a particularly nifty example is including "whatever/version.hpp" and making some decisions based on version. Some changes to the way libraries are linked will allow the test to be rebuilt when a system library itself is modified.
Another mode is where configure checks tries to compile or link something, and caches the result. One can remove the cache and run all checks again, but otherwise the system assumes nothing changes.
I, personally, is not very happy with the second mode as implemented in cmake. However, it might be that the best mode depends on the nature of the test, and we need to support both. Comments?
I'm not happy with the second mode either - if something in the source changes then the test should definitely be rebuilt - most users will presumably only build the thing once anyway during an install so it won't make any difference to them?
Most users -- yes. However, there are also developers, and I am surely not happy about the existing build system that require to basically reconfigure afresh after each major change. - Volodya
to the list of your sources for the library build should do the trick.... but you need to find out why the regex lib build isn't working for you first,
We should probably create a separate ICU module for Boost.Build if it's going to be used by more than one library.
How about making a configure check for ICU be libs/config//icu ?
Potentially we have a whole load of these, so I was thinking of libs/config/runtime//check-feature and libs/config/runtime//requires-feature The former sets a flag to indicate whether feature is present or not, the latter also sets <build>no if the feature isn't present. John.
Hello, We are happy to announce the forthcoming publication http://www.datasim-press.com/ The authors develop software for computational finance, engineering, optical technology graphics, CAD that benefit greatly from these excellent libraries. We are working on Volume II (advanced libs + applications). Boost is popular in our domain, as seen on www.quantnet.com (blogs) and www.datasimfinancial.com best regards and thanks! Robert Demming Daniel J. Duffy
On Tue, Sep 21, 2010 at 04:15:09PM +0200, Daniel J. Duffy wrote:
Hello, We are happy to announce the forthcoming publication
The authors develop software for computational finance, engineering, optical technology graphics, CAD that benefit greatly from these excellent libraries.
We are working on Volume II (advanced libs + applications).
Congratulations on writing a book. You did however reply to an existing post on the list instead of starting a new thread, so this announcement is buried deep inside a discussion on ICU, threaded together with it instead of as a brand new top-level thread. -- Lars Viklund | zao@acc.umu.se
From: Daniel J. Duffy <dduffy@datasim.nl> To: boost@lists.boost.org Sent: Tue, September 21, 2010 4:15:09 PM Subject: [boost] New Book: Introduction to the C++ Boost Libraries, Volume I - Foundations
Hello, We are happy to announce the forthcoming publication
The authors develop software for computational finance, engineering, optical technology graphics, CAD that benefit greatly from these excellent libraries.
I'm sorry but...
From few glances I see total amateurishness.
General feeling from the book: ------------------------------ 1. Hire a professional to do the typesetting. The typesetting is horrible, you never typeset a book with text aligned to left instead of justified aliment. 2. 2/3 of the book is code... Not good. The author does not know the topic and writes terrible things like this: ------------------------------------------------------------------------ Part: 18.13 Volatile Variables
In order to rectify this situation we declare variables to be volatile in order to disable register optimisations:
// Shared variable volatile int i2; // The same functions as above but use a volatile variable. // Not optimised anymore so results are always correct. void FV1() { while (true) i2++; } void FV2() { while (true) cout<<i2<<endl; }
This is so wrong! And all this from 2 minutes of looking on the book! Artyom
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Artyom Sent: Tuesday, September 21, 2010 4:31 PM To: boost@lists.boost.org Subject: Re: [boost] New Book: Introduction to the C++ Boost Libraries, Volume I - Foundations
From: Daniel J. Duffy <dduffy@datasim.nl> To: boost@lists.boost.org Sent: Tue, September 21, 2010 4:15:09 PM Subject: [boost] New Book: Introduction to the C++ Boost Libraries, Volume I - Foundations We are happy to announce the forthcoming publication
The authors develop software for computational finance, engineering, optical technology graphics, CAD that benefit greatly from these excellent libraries.
I'm sorry but...
From few glances I see total amateurishness.
General feeling from the book: ------------------------------
1. Hire a professional to do the typesetting. The typesetting is horrible, you never typeset a book with text aligned to left instead of justified aliment.
Reasonably convincing research suggests that 'ragged right' is faster to read http://core.ecu.edu/engl/tpc/MennoMenno/ftp/williams%202000.pdf - it's only 'Professional Web Designers and typesetters' who ignore this! It may look less neat and tidy, but it works better, and I prefer it. Function First! It's meant for reading, not looking pretty. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
1. Hire a professional to do the typesetting. The typesetting is
horrible,
you never typeset a book with text aligned to left instead of
justified aliment.
Reasonably convincing research suggests that 'ragged right' is faster to read
http://core.ecu.edu/engl/tpc/MennoMenno/ftp/williams%202000.pdf
- it's only 'Professional Web Designers and typesetters' who ignore this!
It may look less neat and tidy, but it works better, and I prefer it.
Function First! It's meant for reading, not looking pretty.
Ok... you miss the head of the article "The display information on the **WEB**" This is totally different for books. You will never find book that typeset with "ragged right" Also, it is known that the length of the column (at least in English) should be in average at most 66 letters for good reading. Doing very wide columns make text hardly to read. Open any book printed in good typography and count it... You'll be surprised. In this "book" the average is 90 which is much harder to read. Generally the typesetting is horrible. I can point about many other significant mistakes that were done in typesetting... But I just say: use professional tools and professional person who can help you. Microsoft Word 2007 is by no means typesetting tool! Artyom P.S.: I have not so bad knowledge in typesetting as I developed tools for better Hebrew support in LaTeX (BiDiTex), so I know a little about it.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Artyom Sent: Wednesday, September 22, 2010 1:28 PM To: boost@lists.boost.org Subject: Re: [boost] New Book: Introduction to the C++ Boost Libraries, Volume
1. Hire a professional to do the typesetting. The typesetting is horrible, you never typeset a book with text aligned to left instead of justified aliment.
Reasonably convincing research suggests that 'ragged right' is faster to read.
http://core.ecu.edu/engl/tpc/MennoMenno/ftp/williams%202000.pdf Ok... you miss the head of the article "The display information on the **WEB**"
But I believe that was based on earlier research before screens. So we will have to disagree - and I'm sure this is already way off-topic. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
On Wed, Sep 22, 2010 at 3:05 PM, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Artyom Sent: Wednesday, September 22, 2010 1:28 PM To: boost@lists.boost.org Subject: Re: [boost] New Book: Introduction to the C++ Boost Libraries, Volume
1. Hire a professional to do the typesetting. The typesetting is horrible, you never typeset a book with text aligned to left instead of justified aliment.
Reasonably convincing research suggests that 'ragged right' is faster to read.
http://core.ecu.edu/engl/tpc/MennoMenno/ftp/williams%202000.pdf Ok... you miss the head of the article "The display information on the **WEB**"
But I believe that was based on earlier research before screens.
Note that web browser usually do justification by simply increasing spacing within words; more sophisticate justification algorithms (for example in TeX or even Word) add space between characters, change character sizes, slightly move lines left and right to be more visually appealing and do word breaking. In fact even the PDF you linked to is justified. -- gpd
Part: 18.13 Volatile Variables
In order to rectify this situation we declare variables to be volatile in order to disable register optimisations:
// Shared variable volatile int i2; // The same functions as above but use a volatile variable. // Not optimised anymore so results are always correct. void FV1() { while (true) i2++; } void FV2() { while (true) cout<<i2<<endl; }
This is so wrong!
Please explain why this is wrong. Is the code wrong? Is the example wrong? Please note that this is a snippet from the full test program where two different threads are started to execute FV1() and FV2(). On my dual-core machine the version without volatile produces wrong results while the version with volatile produces correct results. Daniel _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Daniel J. Duffy wrote:
Part: 18.13 Volatile Variables
In order to rectify this situation we declare variables to be volatile in order to disable register optimisations:
// Shared variable volatile int i2; // The same functions as above but use a volatile variable. // Not optimised anymore so results are always correct. void FV1() { while (true) i2++; } void FV2() { while (true) cout<<i2<<endl; }
This is so wrong!
Please explain why this is wrong. Is the code wrong? Is the example wrong? Please note that this is a snippet from the full test program where two different threads are started to execute FV1() and FV2().
volatile affects optimizations but not synchronization. You need true synchronization for atomicity. C++0x does not reuse "volatile" to mean atomic because there are still non-synchronization reasons to declare objects volatile (I/O ports, for example). Indeed, one can declare a volatile and atomic object.
On my dual-core machine the version without volatile produces wrong results while the version with volatile produces correct results.
That the code happens to work on a particular platform with a particular toy program does not mean it is correct. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Part: 18.13 Volatile Variables
In order to rectify this situation we declare variables to be volatile in order to disable register optimisations:
// Shared variable volatile int i2; // The same functions as above but use a volatile variable. // Not optimised anymore so results are always correct. void FV1() { while (true) i2++; } void FV2() { while (true) cout<<i2<<endl; }
This is so wrong!
Please explain why this is wrong. Is the code wrong? Is the example wrong? Please note that this is a snippet from the full test program where two different threads are started to execute FV1() and FV2().
In addition to what was told, read following. Read this: http://en.wikipedia.org/wiki/Volatile_variable#In_C_and_C.2B.2B And this: http://kernel.org/doc/Documentation/volatile-considered-harmful.txt Artyom
On Wed, Sep 22, 2010 at 1:13 PM, Artyom <artyomtnk@yahoo.com> wrote:
Part: 18.13 Volatile Variables
In order to rectify this situation we declare variables to be volatile in order to disable register optimisations:
// Shared variable volatile int i2; // The same functions as above but use a volatile variable. // Not optimised anymore so results are always correct. void FV1() { while (true) i2++; } void FV2() { while (true) cout<<i2<<endl; }
This is so wrong!
Please explain why this is wrong. Is the code wrong? Is the example wrong? Please note that this is a snippet from the full test program where two different threads are started to execute FV1() and FV2().
In addition to what was told, read following.
Read this: http://en.wikipedia.org/wiki/Volatile_variable#In_C_and_C.2B.2B And this: http://kernel.org/doc/Documentation/volatile-considered-harmful.txt
Artyom
And from the original author of POSIX Threads himself: http://groups.google.com/group/comp.programming.threads/msg/bd2cb64e70c9d155 HTH, -- gpd
On Tue, Sep 21, 2010 at 07:15, Daniel J. Duffy <dduffy@datasim.nl> wrote:
We are happy to announce the forthcoming publication
Congratulations on finishing your book. I'm surprised that, with bind being the second chapter in the book, I couldn't find an example in the threading chapter of using bind to provide the functor to run in the thread. ~ Scott
participants (11)
-
Artyom -
Daniel J. Duffy -
Giovanni Piero Deretta -
John Maddock -
Kim Barrett -
Lars Viklund -
Paul A. Bristow -
Scott McMurray -
Steven Watanabe -
Stewart, Robert -
Vladimir Prus