- Boost - lists.boost.org

Re: [boost] [Boost-build] Milestone 11, release candidate 3
by Vladimir Prus 21 Jul '06

21 Jul '06

On Wednesday 12 July 2006 20:13, Bronek Kozicki wrote: Hi Bronek, I'm replying on list, so that Win32 experts can comment too. > attached .diff is addressing 3 bugs in execnt.c > - memory leak in is_parent_child > - closing unrelated dialogs (displayed by descendants of explorer.exe) > - missing dialogs displayed by csrss.exe ("... - Unable To Locate > Component") > > there are also other improvements and changes that I tested much more > thoroughly than previous update to execnt.c > --- C:\Documents and Settings\Bronek Kozicki\Desktop\execnt.c Thu Jun 8 02:25:58 2006 UTC > +++ E:\DEVEL\BOOST_RTEST\boost\tools\jam\src\execnt.c Sun Jun 25 18:55:27 2006 UTC > @@ -1001,8 +1001,10 @@ > int is_parent_child(DWORD parent, DWORD child) > { While we're at it, can be have a comment for this function, at least saying what are 'parent' and 'child' arguments. Are they pids or something else? > HANDLE process_snapshot_h = INVALID_HANDLE_VALUE; > > + if (!child) > + return 0; > if (parent == child) > return 1; > > process_snapshot_h = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS,0); > @@ -1015,49 +1017,100 @@ > ok = Process32First(process_snapshot_h, &pinfo); > ok == TRUE; > ok = Process32Next(process_snapshot_h, &pinfo) ) > { > - if (pinfo.th32ProcessID == child && pinfo.th32ParentProcessID) > + if (pinfo.th32ProcessID == child) > + { > + CloseHandle(process_snapshot_h); > + if (!stricmp(pinfo.szExeFile, "explorer.exe")) This will be clearer if written like: if (stricmp(pinfo.szExeFile, "explorer.exe") == 0) > + { > + /* explorer.exe is orphaned and process_id of its parent may > + accidentally match process_id of process we are after. We must not > + close dialog boxes displayed by children of explorer.exe even > + though (thanks to its parent process id) it might appear to be > + our child. This is not very reliable - there might be more > + orphaned processes or shell might be something else than > + explorer.exe, but this is most common and important scenario */ The last line of this comment is longer than 80 characters. At the same time, thanks for detailed comments! This is tricky code so it's good to have explanations. > + return 0; > + } > + if (!stricmp(pinfo.szExeFile, "csrss.exe")) > + { > + /* csrss.exe may display message box like following: > + xyz.exe - Unable To Locate Component > + This application has failed to start because boost_foo-bar.dll > + was not found. Re-installing the application may fix the problem > + This actually happens when starting test process that depends on > + dynamic library which failed to build. We want to automatically > + close these message boxes even though csrss.exe is not our > + child process. We may depend on the fact that (in all current > + versions of Windows) csrss.exe is indirectly child of System which > + always has process id == 4 */ > + if (is_parent_child(4, pinfo.th32ParentProcessID)) > + return 1; Oh, closing those message box is cool. The comment has lines longer than 80 characters, though ;-) > + } > return is_parent_child(parent, pinfo.th32ParentProcessID); > + } > } > > CloseHandle(process_snapshot_h); > } > > return 0; > } > > -int related(HANDLE h, DWORD p) > +int related(DWORD d, DWORD p) > { > - return is_parent_child(get_process_id(h), p); > + return is_parent_child(d, p); > } If this function just forwards to is_parent_child, can we just change all callers to call is_parent_child? > +typedef struct PROCESS_HANDLE_ID {HANDLE h; DWORD pid;} PROCESS_HANDLE_ID; > + > BOOL CALLBACK window_enum(HWND hwnd, LPARAM lParam) > { > - char buf[10] = {0}; > - HANDLE h = *((HANDLE*) (lParam)); > + char buf[7] = {0}; > + PROCESS_HANDLE_ID p = *((PROCESS_HANDLE_ID*) (lParam)); > DWORD pid = 0; > + DWORD tid = 0; > + > + if (!IsWindowVisible(hwnd)) > + return TRUE; > > - if (!GetClassNameA(hwnd, buf, 10)) > - return TRUE; // failed to read class name > + if (!GetClassNameA(hwnd, buf, 7)) > + return TRUE; /* failed to read class name; presume it's not a dialog */ Use sizeof(buf), perhaps? > if (strcmp(buf, "#32770")) While we're at it, it will be clearer if written like: if (strcmp(buf, "#32770") != 0) I realize this is not originally yours code, but anyway. > - return TRUE; // not a dialog > + return TRUE; /* not a dialog */ BTW, what does this code does? Do all dialogs have class name of #32770? Or this is specific class of dialogs we're interested in? > - GetWindowThreadProcessId(hwnd, &pid); > - if (related(h, pid)) > + tid = GetWindowThreadProcessId(hwnd, &pid); > + if (tid && related(p.pid, pid)) What's the point of check for 'tid'? > { > - PostMessage(hwnd, WM_QUIT, 0, 0); > - // just one window at a time > + /* ask really nice */ > + PostMessageA(hwnd, WM_CLOSE, 0, 0); > + /* now wait and see if it worked. If not, insist */ > + if (WaitForSingleObject(p.h, 200) == WAIT_TIMEOUT) > + { > + PostThreadMessageA(tid, WM_QUIT, 0, 0); > + if (WaitForSingleObject(p.h, 500) == WAIT_TIMEOUT) > + { > + PostThreadMessageA(tid, WM_QUIT, 0, 0); > + WaitForSingleObject(p.h, 500); Is posting WM_QUIT message twice better than posting it once? > + } > + } > return FALSE; > } > > return TRUE; > } > > void close_alert(HANDLE process) > { > - EnumWindows(&window_enum, (LPARAM) &process); > + DWORD pid = get_process_id(process); > + /* If process already exited or we just cannot get its process id, do not go any further */ > + if (pid) > + { > + PROCESS_HANDLE_ID p = {process, pid}; > + EnumWindows(&window_enum, (LPARAM) &p); > + } > } > > static int > my_wait( int *status ) > @@ -1093,23 +1146,29 @@ > } > > if ( globs.timeout > 0 ) > { > + unsigned int alert_wait = 1; > /* with a timeout we wait for a finish or a timeout, we check every second > to see if something timed out */ > - for (waitcode = WAIT_TIMEOUT; waitcode == WAIT_TIMEOUT;) > + for (waitcode = WAIT_TIMEOUT; waitcode == WAIT_TIMEOUT; ++alert_wait) > { > waitcode = WaitForMultipleObjects( num_active, active_handles, FALSE, 1*1000 /* 1 second */ ); > if ( waitcode == WAIT_TIMEOUT ) > { > /* check if any jobs have surpassed the maximum run time. */ > for ( i = 0; i < num_active; ++i ) > { > double t = running_time(active_handles[i]); > + > + /* periodically (each 5 secs) review and close alert dialogs hanging around */ > + if ((alert_wait % ((unsigned int) 5)) == 0) > + close_alert(active_handles[i]); > + Is the point here to close dialogs right away, and not wait possibly long time for timeout? If so, maybe this should be added to comment? Overall, looks reasonable. Would you like to address the comments and sent the patch again, or it will be more convenient if I commit the patch right now and you'll send further patches when you have the time? Thanks, Volodya

3 6

Re: [boost] [asio] Modified SSL client to reproduce error
by Scott 21 Jul '06

21 Jul '06

>OK, this is almost certainly not going to work :) My apologies Chris. You are absolutely right and only proves I need to work on example programs in the morning after a good night's sleep! :) Our software does have appropriate locking and works fine (outside of SSL). The thread code I wrote in the example client was terrible. I took a new direction with the client/server example. I removed the thread and rewrote the client and server to pass ever increasing message sizes. In the beginning, everything works fine. But once messages start getting over 8k in size, the server eventually just locks up. If I keep the messages small, the client/server seems to run continually without problems. BTW, I am using a version of the boost asio implementation you are working on. I believe you send me a link to it back in May or June for downloading. This version is actually in the "boost::asio" namespace and not just "asio". If there's a newer version I should use, please let me know. Thanks, Scott

2 1

[filesystem] committee proposal
by Felipe Magno de Almeida 21 Jul '06

21 Jul '06

Is there any proposal for filesystem to the standard committee? Thanks, -- Felipe Magno de Almeida

2 1

[iostreams] fix for vc-6_5
by Joaquín Mª López Muñoz 21 Jul '06

21 Jul '06

Recent changes to boost/iostreams/positioning.hpp cause VC 6.5 to fail as for instance in http://tinyurl.com/jkdhx . The simple problem is that Dinkum lib for this compiler does not define fpos_t in namespace std, only as a global type. The attached patch just reverts to global ::fpos_t under the aforementioned circumstances. Is there any objection to my commiting to trunk and RC_1_34_0? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo 16a17 > #include <boost/config.hpp> 17a19 > #include <boost/detail/workaround.hpp> 48a51,53 > #if BOOST_WORKAROUND(BOOST_MSVC, < 1300) && defined(BOOST_DINKUMWARE_STDLIB) > inline stream_offset fpos_t_to_offset(::fpos_t pos) > #else 49a55 > #endif

2 7

[conversion][implicit_cast] Failure on como-4_3_3-vc7_1
by Gennaro Prota 21 Jul '06

21 Jul '06

Hi guys, the failure indicated in the subject line is really odd. The test is marked "compile-fail" in both Jam files but an error is reported for a compilation failure. Any clue? -- [ Gennaro Prota, C++ developer for hire ]

1 0

BGL - cycles in an undirected graph
by Michal 20 Jul '06

20 Jul '06

Hi all, my task is to find cycles in an undirected graph and to assign a cycle id to each vertex in this cycle. It is still a bit more complicated, because I do not need just the simple cycles, but all simple cycles which are sharing edges, must get the same cycle id. I think this problem is already solved somewhere, but I cann not find the right approach, thus I am asking here if somebody have an idea how to solve it best with BGL. I think the brute force approach will work, but as the application needs to be very fast, I think I can not go this way. With brute force I mean, to collect all edges of each simple cycle and than check which are intersecting. Thanks, Michal

2 1

boost::array support for runtime-sized arrays
by Steven Burns 20 Jul '06

20 Jul '06

Recently I came up with a modified version of boost::array that supports runtime sized arrays. The current boost::array implementation is great but every now and then you'll need runtime-sized arrays: it's simply impossible to know everything at compile time. It is backwards compatible: boost::array<int, 10> sarray; but it can be used this way now: boost::array<int> darray(10); I realize you could simply use std::vector, but sometimes all you want is a fixed-size array (but sized at runtime). Besides, I am not sure about the overhead involved with std::vector for these simple scenarios. Comments welcome, Steven

6 11

Re: [boost] boost::array support for runtime-sized arrays
by Sohail Somani 20 Jul '06

20 Jul '06

But scoped_array is meant to be a C++ array. Its only goal is (and probably should be) to call delete[]. > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Steven Burns > Sent: Thursday, July 20, 2006 9:22 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] boost::array support for runtime-sized arrays > > Actually the size of the container I have would be (sizeof(void*) + > sizeof(size_t)) because you have to store the array's length, > so I have to > agree is starting to look like we are better of using std::vector. > > The problem I see with scoped_array is that it doesnt even > have a size() or > equivalent method which is kind of mandatory for very array class. > > Steven. > > > > "John Maddock" <john(a)johnmaddock.co.uk> wrote in message > news:005e01c6ac13$0cd8f8e0$ea8c0252@fuji... > > Steven Burns wrote: > >> Indeed I did a partial spec. when the size is 0 (size_t > cannot be -1) > >> Losing the aggregate behavior was not an option so I only have > >> constructors on this specialization. > >> > >> This means you can still do this: > >> > >> boost::array<int, 5> sarray = {1,2,3,4,5}; // works! > >> > >> but not this: > >> > >> boost::array<int> sarray(5) = {1,2,3,4,5}; // no way jose :( > >> > >> There's simply no way to create runtime-sized aggregates > (that I know > >> of) > >> I am looking for a test suite for boost::array (if exists) to make > >> sure I didnt break anything, and I also wanted to hear > some opinions > >> on the subject. > > > > Unfortunately that would break Boost.Array in Boost-1.34 > onwards which > > already has a TR1-compatible partial specialisation for > zero-sized arrays. > > > > I've been trying to think of what array-like objects I use > already and how > > this would fit in: > > > > C style arrays: > > Hardly ever, except for small immutable arrays. For > example tables of > > coefficients for rational approximations. > > > > Boost.Array: > > Mostly for fixed size tables of immutable data, test data > for example. > > > > Scoped_array: > > Useful for temporary buffers whose size is determined at > runtime. Doesn't > > have a container interface though, and probably mostly used for > > interfacing > > with legacy C API's. > > > > Shared_array: > > Never used it. Might do if I wanted to write a copy-on-write > > string/vector, > > but that's about all. > > > > std::vector/std::string: > > Used for everything else, which encompasses quite a lot :-) > > > > So.... you have quite a lot of competition here, and I've > yet to see a > > compelling reason to have yet-another-vector :-) > > > > Thinking out loud, the issues, seems to boil down to: > > > > Code size: I would be very surprised to see any difference, although > > vector/string have "fatter" interfaces, you only pay for the member > > functions you actually use. Indeed if vector<whatever> is > instantiated > > already somewhere else in the program, or if you can use > std::string and > > that's already in use elsewhere, then you may *save* on > code size by > > reusing > > these. > > > > Object size: I guess your runtime-sized array would be > sizeof(void*) in > > size, compared to typically three times that for a vector. > There may be > > times when that's important - embedded systems for example > - but then > > unless > > you really need a container-like interface scoped_array is > probably a > > better > > bet. > > > > Actually I think I may have just provided a compelling > reason for a real > > lightweight container after all then! It would have to be called > > something > > other than array though :-) > > > > Just thinking out loud, > > > > John. > > > > _______________________________________________ > > Unsubscribe & other changes: > > http://lists.boost.org/mailman/listinfo.cgi/boost > > > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

Boost.Build
by Glenn Williamson 20 Jul '06

20 Jul '06

First time Boost user, trying to get it to build on VS C++ v8 .. and to be quite honest, haven't touched C++ itself for about 5 years so it's taken me a cuppla hours to even get to this point ;) I know the new version of Boost.build (2.0 v11) was only released this morning, but I think I may have found a bug. I get an assertion when I try to "build vc8" (which I've attached to the bottom of the email). For some reason it's trying to call _loctotime64_t, when I'm running on a 32 bit machine. While that's a little weird, what's weirder is that the assertion fails. And even weird than that - I've commented out the assertion from dtoxtm64.c, and it still comes up! Someone lend a hand to a newbie please ;) gleNN --------------------------- Microsoft Visual C++ Debug Library --------------------------- Debug Assertion Failed! Program: ... File: dtoxtm64.c Line: 67 Expression: ( ( ( long )( yr - 1900 ) >= _BASE_YEAR ) && ( ( long )( yr - 1900 ) <= _MAX_YEAR64 ) ) For information on how your program can cause an assertion failure, see the Visual C++ documentation on asserts. (Press Retry to debug the application) --------------------------- Abort Retry Ignore ---------------------------

2 2

Boost regression notification (2006-07-20 [RC_1_34_0])
by Douglas Gregor 20 Jul '06

20 Jul '06

Boost Regression test failures Report time: 2006-07-20T11:49:22Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/i… 255 failures in 24 libraries algorithm/string (1) concept_check (1) filesystem (2) graph (5) integer (3) io (1) iostreams (39) mpl (7) numeric/conversion (4) numeric/interval (1) numeric/ublas (7) parameter (30) pool (3) program_options (9) python (25) random (1) rational (4) serialization (32) signals (16) statechart (1) test (2) tr1 (53) typeof (7) utility (1) |algorithm/string| regex: borland-5_6_4 |concept_check| class_concept_check_test: vc-7_1-stlport |filesystem| operations_test: vc-7_1-stlport operations_test_dll: vc-7_1-stlport |graph| adjacency_matrix_test: vc-7_0 bidir_remove_edge: vc-7_0 graphviz_test: msvc-8.0 msvc-8.0 vc-7_1-stlport |integer| integer_traits_test: qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp |io| ios_state_unit_test: gcc-4.1.0_linux_x86_64 |iostreams| array_test: vc-6_5 auto_close_test: vc-6_5 buffer_size_test: vc-6_5 bzip2_test: msvc-7.1 msvc-8.0 code_converter_test: vc-6_5 component_access_test: vc-6_5 compose_test: borland-5_6_4 vc-6_5 copy_test: vc-6_5 counter_test: vc-6_5 direct_adapter_test: vc-6_5 example_test: vc-6_5 vc-6_5-stlport file_descriptor_test: vc-6_5 file_test: vc-6_5 filtering_stream_test: vc-6_5 vc-7_1-stlport finite_state_filter_test: cw-9.4 flush_test: vc-6_5 gzip_test: msvc-7.1 msvc-8.0 invert_test: vc-6_5 line_filter_test: vc-6_5 mapped_file_test: vc-6_5 newline_test: vc-6_5 null_test: vc-6_5 pipeline_test: vc-6_5 positioning_test: vc-6_5 regex_filter_test: vc-6_5 restrict_test: vc-6_5 seekable_file_test: vc-6_5 seekable_filter_test: vc-6_5 stdio_filter_test: vc-6_5 symmetric_filter_test: vc-6_5 tee_test: vc-6_5 wide_stream_test: vc-6_5 zlib_test: msvc-7.1 msvc-8.0 |mpl| apply: gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc multiset: gcc-4.0.3_linux gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc gcc-4_0_3_tru64 |numeric/conversion| converter_test: borland-5_8_2 traits_test: borland-5_8_2 udt_example_0: borland-5_8_2 udt_support_test: borland-5_8_2 |numeric/interval| test_float: vc-7_1-stlport |numeric/ublas| concepts: vc-7_1-stlport vc-7_1-stlport test1: vc-7_1-stlport test2: vc-7_1-stlport test4: vc-7_1-stlport test5: vc-7_1-stlport vc-7_1-stlport |parameter| basics: borland-5_6_4 borland-5_8_2 duplicates: borland-5_6_4 borland-5_8_2 earwicker: borland-5_6_4 borland-5_8_2 macros: borland-5_6_4 borland-5_8_2 maybe: vc-6_5 vc-6_5-stlport vc-7_0 mpl: borland-5_6_4 borland-5_8_2 preprocessor: borland-5_6_4 borland-5_8_2 vc-6_5 vc-6_5-stlport python-parameter-test: vc-6_5 vc-6_5-stlport vc-7_0 sfinae: borland-5_6_4 borland-5_8_2 vc-6_5-stlport singular: borland-5_6_4 borland-5_8_2 unnamed: borland-5_6_4 borland-5_8_2 unnamed_fail: vc-6_5 vc-6_5-stlport vc-7_0 |pool| test_pool_alloc: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp |program_options| cmdline_test_dll: cw-9.4 options_description_test_dll: cw-9.4 parsers_test_dll: cw-9.4 positional_options_test_dll: cw-9.4 unicode_test_dll: borland-5_8_2 cw-9.4 variable_map_test_dll: borland-5_8_2 cw-9.4 winmain_dll: cw-9.4 |python| bases: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux exec: cw-9.4 darwin-4.0.1 gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux msvc-8.0 qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp pointee: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux pointer_type_id_test: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux select_from_python_test: darwin-4.0.1 qcc-3.3.5_cpp qcc-3.3.5_gpp upcast: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux |random| random_test: intel-linux-9.0 |rational| rational_test: borland-5_6_4 vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_class_info_load_text_warchive: vc-6_5 test_codecvt_null: qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp test_non_default_ctor2_text_archive: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_non_default_ctor2_text_archive_dll: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_non_default_ctor2_text_warchive: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_non_default_ctor2_text_warchive_dll: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_recursion_binary_archive_dll: msvc-8.0 test_reset_object_address: vc-7_0 test_reset_object_address_dll: vc-7_0 test_shared_ptr_132_xml_archive_dll: msvc-8.0 test_simple_class_binary_archive_dll: vc-6_5 test_simple_class_text_archive_dll: vc-6_5 test_simple_class_text_warchive_dll: vc-6_5 test_simple_class_xml_archive_dll: vc-6_5 test_simple_class_xml_warchive_dll: vc-6_5 test_utf8_codecvt: qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp test_variant_xml_archive: borland-5_8_2 test_variant_xml_archive_dll: borland-5_8_2 test_variant_xml_warchive: borland-5_8_2 test_variant_xml_warchive_dll: borland-5_8_2 |signals| dead_slot_test: gcc-3.3.6 gcc-3.3.6_linux qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp trackable_test: gcc-3.3.6 gcc-3.3.6_linux qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp |statechart| TransitionTestRelaxed: msvc-8.0 |test| parameterized_test_test: vc-6_5 vc-6_5-stlport |tr1| std_test_bind: darwin-4.0.1 std_test_ref_wrapper_tricky: borland-5_6_4 borland-5_8_2 darwin-4.0.1 gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.3_sunos gcc-3.4.5_linux gcc-3.4.5_linux_x86_64 gcc-3_4_4_tru64 gcc-4.0.3_linux gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc hp_cxx-71_006_tru64 intel-linux-9.0 msvc-7.1 msvc-8.0 msvc-8.0 qcc-3.3.5_cpp qcc-3.3.5_gpp test_bind: darwin-4.0.1 test_boost: vc-7_1-stlport test_hash: vc-7_1-stlport test_random: vc-7_1-stlport test_ref_wrapper_tricky: borland-5_6_4 borland-5_8_2 darwin-4.0.1 gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.3_sunos gcc-3.4.5_linux gcc-3.4.5_linux_x86_64 gcc-3_4_4_tru64 gcc-4.0.3_linux gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc hp_cxx-71_006_tru64 intel-linux-9.0 msvc-7.1 msvc-8.0 msvc-8.0 qcc-3.3.5_cpp qcc-3.3.5_gpp test_regex: vc-7_1-stlport tr1_has_trivial_destr_test: borland-5_6_4 tr1_has_virtual_destr_test: borland-5_6_4 tr1_tky_abstract_type_test: borland-5_6_4 tr1_tky_function_type_test: borland-5_6_4 tr1_tky_incomplete_type_test: borland-5_6_4 borland-5_8_2 tr1_tky_partial_spec_test: borland-5_6_4 |typeof| function_binding_native: vc-6_5 vc-6_5-stlport vc-7_0 nested_typedef_emulation: cw-9.4 odr_no_uns: vc-6_5 vc-6_5-stlport vc-7_0 |utility| operators_test: gcc-3.4.5_linux_x86_64

1 0