August 2008 - Boost-users - lists.preview.boost.org

Re: [Boost-users] size_type doubts / integer library..
by Lang Stefan 18 Aug '08

18 Aug '08

-----Ursprüngliche Nachricht----- > > If the developer > > chooses either type, others looking at the code might not recognize that > > certain values outside that range (but well within the limits of the > > chosen type) will cause problems or might indicate an error elsewhere. > > That's the job of the programmer. You have the native types with platform > dependent ranges. Good. That's a good start (without which you couldn't do > anything anyways). Now you need integer types to be defined in terms of > ranges, ok, you can do it with templates. Arbitrary precision arithmetic is > not the C++ standard IMO, it sits perfectly fine in third-party library space. > There was also a BigNum boost library proposal for GSoC. After that is done > then maybe everyone will be happy about this. > > -- > Dizzy > "Linux is obsolete" -- AST I am not sure you got my meaning. What I was trying to point out that today, like thirty years ago, when a programmer looks at a variable, he has to consider what integral type it fits in. And he needs to do so in terms of the machine! (can you say DWORD?) This implies two anachronisms: 1) the programmer needs to know the exact range the built-in integral types cover. While this is not a big problem, the mere fact a programmer needs to know such internal details indicates a design problem of the language. 2) the programmer can not easily express the true limits of the integral variables he uses: if he needs to make sure a variable does not exceed a certain limit, this requires excessive testing, or alternativly substituting his type with a custom class. On top of that he needs to devise mechanisms that prevent other programmers from circumventing these limitations. These two artifacts of the C language are the cause for uncountable runtime errors. If a programmer wasn't forced to think about internal representations and could instead just define the type he needs in terms of the range his variable should be tied to, then a lot of run time errors could never happen! Yes, it is the job of the programmer to avoid such errors. Today. As it was thirty years ago. But it shouldn't be! Of course, in many cases there is no need to check a variable's range, simply because it is being used inside a very limited scope. But even then the ability for simple range checking without added effort could help detect runtime errors! Stefan

3 2

[boost signal] Connecting while a notification is being processed
by Eric B 18 Aug '08

18 Aug '08

Hi I wonder what would happen (if) - while a signal is being processed - one of the listener method cause a new listener to connect to this signal Will the new listener append to the end of the listeners and therefore be called last ?

1 0

[boost]smart iterator
by Eduardo Panisset 18 Aug '08

18 Aug '08

Hi, Just for clarifying what I mean by "smart iterator": a smart iterator would be a iterator that acquires/releases locks on container/container items. If we would consider a Reader/Writer paradigm - few writtings and many readings, then a const_iterator would acquire/release a read lock on container and read lock on item, and a iterator would acquire/release a read lock on container and a write lock on item. For writting operations on container (e.g insert, remove), we would acquire write lock on container. Of course, we would consider a container stability, if stable (e.g. std::list, std::map) or unstable( e.g. std::vector, std::deque) in order to optimizing the solution (stable containers would allow simultaneous read/write operations on container). obs:Maybe the paradigm of concurrency could be a parameter. There is an analogous iterator in boost ? Thanks. Eduardo Panisset

1 0

AIX xlC error on static_move_ptr.hpp
by Gary Fu 18 Aug '08

18 Aug '08

Hi, Could anyone help why the AIX (5.3) xlC complains on the include file 'static_move_ptr.hpp' and how to solve the problem if possible ? I tried on Linux g++ without problem. Thanks, Gary 8:52pm > xlC -I $HOME/BOOST/boost_1_36_0 example.cpp -o example "/home_dir/Ggfu/BOOST/boost_1_36_0/boost/ptr_container/detail/static_move_ptr.hpp", line 182.22: 1540-2611 (S) The name "typename move_ptrs::enable_if_convertible<TT,T,boost::ptr_container_detail::static_move_ptr &>::type::type" can only be used to declare a constructor. #include <boost/ptr_container/detail/static_move_ptr.hpp> #include <iostream> #include <string> using namespace std; int main() { //print out the text string, "Hello, World!" cout << "Hello, World!" << endl; return 0; }

1 0

Re: [Boost-users] size_type doubts / integer library..
by Lang Stefan 18 Aug '08

18 Aug '08

Some thoughts: 1. Original problem Assigning a size to an ID type, IMHO appears to be completely unrelated to the general integral types' problem. There are two possibilities: A) you intend to use your ID to later reference some address or offset (which is the same) in memory. If that is your intention, then you should stick to the size type (i. e. std:size_t). Problem solved. B) if you don't intend to ever use your ID in the future to refer to an address in memory, then using an integral type might prove short-sighted. Unless you have a very concise knowledge about how many IDs you will need in, say, 5 years, or maybe 10 years from now, it's dangerous to limit yourself to a specific integral type for such a value. The least I would do is a typedef to hide the true type of that value and prevent anyone from making presumptions about it's potential size. Better yet define a class for this ID. If you do that you can write your own conversions and mathematical operators exactly the way you want them to be. Plus you have a central place to fix your conversions if you decide to change your ID class in a couple of years. Problem solved - in a very clean way. (IMHO) Then again I might be overestimating the importance and scope of this ID value. But in that case, why is 'unsigned long' the 'correct' type? Regarding this question, see my comments in part 3 of this message. 2. Size types (and difference types) I disagree on your complaint about size types all being unsigned. The quotation from B. Stroustrup explicitly made an exception for specific cases, and as I understand it he *was* referring to size types. The problem with size types is that they do need to be able to point to every location within the addressable memory space. Unfortunately this means they will need every single bit of the biggest data entity a CPU can handle at any one time. If size types were signed, they would need one extra bit for the sign, effectively doubling the amount of memory such a type would take up in memory. Unfortunately 'difference types' technically should be both signed and able to address every legal address in memory - which means one bit more than the current size types! However, see below.... 3. Integral types situation I agree with your general assessment of the integral types' situation. For several reasons actually, some of them not pointed out yet: A) Whenever signed and unsigend types are mixed, the compiler implicitly converts some of the values or intermediate results. Unfortunately it's often not obvious, which values and terms are being converted, and whether that can lead to problems. Most of the time (but not always, as you have correctly pointed out) the compiler issues warnings in such situations, but many compilers just point to the line, not the exact variable or term. B) What makes this problem even more difficult, is the widespread use of libraries, which may or may not use signed/unsigned values for specific properties, and thus don't even leave it open to the developers to avoid such combinations! C) Built-in integral types are based on internal representations of numbers. From the perspective of a designer this is just plain wrong! It is a violation of the principle of information hiding! Types shouldn't reveal anything about their internal representation, and after 20+ years of history in object oriented programming I really don't understand why we are still forced to use such types! When a developer selects an integral type for a variable, he considers the preconditions and postconditions, and decides the range of values his variable could legally assume. However, he shouldn't be forced to map this range to one of a few predefined ranges, just because these predefined ranges happen to fit the compiler's preferred internal representation. If a variable can assume values in the range [0..999999], then is 'long' the 'correct' type? Or is it 'unsigned long'? My answer is: neither! If the developer chooses either type, others looking at the code might not recognize that certain values outside that range (but well within the limits of the chosen type) will cause problems or might indicate an error elsewhere. 4. Resolution I like the suggestion of an integral type that is defined as a range of valid values. An additional (optional) parameter could be provided to define policies such as behavior on overflow, conversion problems and the like. This would be in the spirit of information hiding. In the case of size types or difference types, the address space could be reasonably restricted to a range that allows for a sign bit without compromising the maximum internal data size. In most cases anyway. And when it turns out an additional bit is still needed, then so be it! This design would take away the need to think in internal representations, and instead would allow the developers to concentrate on the true limitations of their variable types. 5. Advantages A) Developers can set more concise limits on their variables and behavior on violation of these limits. B) Predefined behavior on violations at runtime. C) Compiler developers can optimize internally needed storage by clustering mechanisms, depending on whatever memory access and processing capabilities the available cores provide. D) Compiler developers need to deal with just one basic integral class instead of a dozen or more. Depending on processor architecture this may or may not be very helpful (it might be neccessary to redefine the current integral types internally), but at least the use of these types would be more secure and less prone to programming errors. (Of course this implies the annihilation of current integral types which won't happen for some time, even after a standard basic adaptable integral type would be provided.) So these are my 5 cents, sorry for the lengthy post. Stefan

4 3

trunk documentation
by Felipe Magno de Almeida 18 Aug '08

18 Aug '08

Is there a link where I can access the generated trunk documentation? Thanks in advance, -- Felipe Magno de Almeida

5 6

Serialization in Bost 1.36
by Hansi 18 Aug '08

18 Aug '08

Hello, has the version used in boost 1.36 now the same features as the version on the homepage www.rrsd.com ? best regards Hansjörg

2 1

What should I do to switch my legacy application to use boost smart pointers
by Meryl Silverburgh 18 Aug '08

18 Aug '08

Hi, I have a legacy application in C++, and I would like to switch it to use boost smart pointers. Can you please tell me what is the best approach for the switch? This application uses stl vector as the class container, vector<MyClass*> function which takes in MyClass* void f1(MyClass* aMyClass) { ...} function which returns MyClass* MyClass* f1() { return new MyClass(); } I am thinking just global replace all MyClass* with MyClassPtr And then put in a common .h file typedef MyClassPtr shared_ptr<MyClass> Will this approach work? Thank you for any tips.

2 1

Boost and Eclipse Integration
by Amir Hossein Jadidinejad 18 Aug '08

18 Aug '08

Hi,I'm using "Eclipse IDE for C/C++ Developers" on Linux SUSE 10.3. How can I integrate boost programs with Eclipse.I used Visual Studio.Net 2008 previously and not familiar with eclipse. Help me please.Regard,----------------------------------- Amir Hossein Jadidinejad Master of Computer Science Islamic Azad University, Iran Home Page: http://jadidi.info E-Mail : amir(a)jadidi.info , amir.jadidi(a)yahoo.com

3 3

LNK2019: unresolved external symbol "int __cdecl test_main
by Ákos Maróy 18 Aug '08

18 Aug '08

Hi, I'm trying to compile a simple unit test using the boost unit test framework, using MS Visual Studio 2008. I can compile the same code on Linux using gcc just fine (and on Windows using MiGW as well, actually). But with Visual Studio, I get the following error: ------ Build started: Project: test, Configuration: Debug Win32 ------ Linking... LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library libboost_test_exec_monitor-vc90-mt-1_35.lib(test_main.obj) : error LNK2019: unresolved external symbol "int __cdecl test_main(int,char * * const)" (?test_main@@YAHHQAPAD@Z) referenced in function "public: void __thiscall test_main_caller::operator()(void)" (??Rtest_main_caller@@QAEXXZ) C:\var\VS_workspace\Debug\test.exe : fatal error LNK1120: 1 unresolved externals Build log was saved at "file://c:\var\VS_workspace\test\Debug\BuildLog.htm" test - 2 error(s), 1 warning(s) ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== this is despite the fact that I'm linking against libboost_test_exec_monitor-vc90-mt-1_35.lib, that would (?) include test_main. here's the Visual C++ linking command parameter list: /OUT:"C:\var\VS_workspace\Debug\test.exe" /INCREMENTAL /NOLOGO /LIBPATH:"C:\usr\boost_1_35_0\lib" /MANIFEST /MANIFESTFILE:"Debug\test.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"C:\var\VS_workspace\Debug\test.pdb" /SUBSYSTEM:CONSOLE /DYNAMICBASE /NXCOMPAT /MACHINE:X86 /ERRORREPORT:PROMPT libboost_unit_test_framework-vc90-mt-1_35.lib libboost_test_exec_monitor-vc90-mt-1_35.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib this unit test sample app I'm trying to work on is very simple: #include <boost/test/unit_test.hpp> using namespace boost::unit_test; void test() { BOOST_CHECK(true); } test_suite * init_unit_test_suite(int, char **) { test_suite *ts = BOOST_TEST_SUITE("Test"); ts->add(BOOST_TEST_CASE(&test)); framework::master_test_suite().add(ts); return 0; } I wonder what I'm doing wrong... Akos

1 0