October 2006 - Boost - lists.preview.boost.org

[ConceptGCC] for Douglas Gregor
by Andy Little 20 Oct '06

20 Oct '06

Hi Doulas, I sent this privately but have a feeling it may have got sopammed out. If you got it, apologies for abusing the boost list. Hi Douglas, Here is a sample test, but IMO the concept in main should fail, else it is not possible to replace a traits class, hence I have had to use one in the following: regards Andy Little //-----------------------------//line1 //defines result types for binary ops and for static types with no runtime functions #include <quan/meta/binary_operation.hpp> namespace quan {namespace meta{ // is a type mpl::void_? // (binary_operation returns mpl::void for invalid ops, hence the need to query ) namespace detail{ auto concept NotMplVoid<typename T> { typename type = T; }; concept_map NotMplVoid<boost::mpl::void_> { typedef void type; }; } auto concept IsNotMplVoid< typename T> { where std::SameType<detail::NotMplVoid<T>::type,T>; }; auto concept OperatorPlus<typename T1, typename T2>{ typename type = binary_operation<T1, plus, T2>::type; where IsNotMplVoid<type>; }; // should I need to do this ?... see below template <typename T1, typename T2> where OperatorPlus<T1,T2> struct operator_plus{ typedef OperatorPlus<T1,T2>::type type; }; }} #include <quan/meta/rational.hpp> int main() { using quan::meta::rational; // succeeds but shouldnt AFAICS // as this is invalid op and type is mpl::void_ here typedef quan::meta::OperatorPlus<rational<1>,int >::type res; // line 45 // fails as expected but why does the Concept version above succeed? typedef quan::meta::operator_plus<rational<1>,int >::type res; // line 49 } ConceptGCC output: concept_test.cpp: In function 'int main()': concept_test.cpp:49: error: template arguments for 'struct quan::meta::operator_plus<quan::meta::rational<1, 1>, int>' do not meet the requirements of the primary template concept_test.cpp:49: note: no concept map for requirement 'quan::meta::OperatorPlus<quan::meta::rational<1, 1>, int>' concept_test.cpp:49: error: 'type' in class 'quan::meta::operator_plus<quan::meta::rational<1, 1>, int>' does not name a type ConceptGCC --version: conceptg++ (GCC) 4.1.1 (Indiana University ConceptGCC alpha 3) Copyright (C) 2006 Free Software Foundation, Inc. Copyright (C) 2005, 2006 Trustees of Indiana University. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. regards Andy Little

1 0

[rational][operators] VC6/7 supported? (Trying to clear regressions)
by John Maddock 20 Oct '06

20 Oct '06

What's the state of support for VC6/7 in Boost.Operators? I'm asking because I started investigating the remaining regressions for Boost.Rational and I've come up against a road-block: I can get everything to work (at least I think so), but not the comparison operators, so: my_rational_1 != my_rational_2 doesn't compile with VC6/7, but does with everything else. I'm assuming that's because these compilers don't find the necessary friend-functions in the operators base classes, or is there something else going on here? The error message is: rational_test.cpp(261) : error C2678: binary '!=' : no operator defined which takes a left-hand operand of type 'class boost::rational<short>' (or there is no acceptable conversion) ../../boost/test/test_case_template.hpp(73) : while compiling class-template member function 'void __thiscall basic_rational_suite::rational_comparison_test<short>::test_method(void)' BTW is the use of Boost.Operators by the rational lib new to this version? If so we might just have to mark up VC6/7 as unsupported. Thanks, John.

5 16

[array] Construct a variable-length array with "alloca"
by XHChen＠winbond.com 20 Oct '06

20 Oct '06

Dear boost interesters: "alloca" maybe a suitable tool to construct a variable-length array. The attachment demonstrates the class for variable-length array, most of the codes in which are copied from original "array.hpp" in boost libraries. Hope it is useful. Regards, xhchen =========================================================================================== The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Winbond is strictly prohibited; and any information in this email irrelevant to the official business of Winbond shall be deemed as neither given nor endorsed by Winbond.

3 3

Re: [boost] Runtime Dynamic Dispatch (boost-dispatch)
by Sohail Somani 20 Oct '06

20 Oct '06

> From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Dean > Michael Berris > Subject: Re: [boost] Runtime Dynamic Dispatch (boost-dispatch) > > Hi Sohail, > > On 10/20/06, Sohail Somani <s.somani(a)fincad.com> wrote: > > > > > > Can you elaborate on what you mean so that I don't > > > misunderstand what you mean? > > > > What I mean is overloading operator() with the types of the > tuple so you > > can call the dispatcher like a function. > > > > Does that clarify? > > A bit, though I'm still not so sure I understand. I'l' try to explain > why the dispatcher doesn't have that feature: [snip] I think you hit it on the head. Thanks!

1 0

Re: [boost] Runtime Dynamic Dispatch (boost-dispatch)
by Sohail Somani 20 Oct '06

20 Oct '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Dean > Michael Berris > Sent: Thursday, October 19, 2006 10:46 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Runtime Dynamic Dispatch (boost-dispatch) > > Hi Sohail, > > On 10/20/06, Sohail Somani <s.somani(a)fincad.com> wrote: > > > > Is it not possible at all to have a d(1,2,3) interface? > > > > With the tuples, you are specifying the interface already. > > > > I'm not sure what you mean by `d(1, 2, 3)'... If you have > something like: > > void function(int a, int b, int c) { > // do something with a, b, and c > }; > > dispatcher<void(int, int, int)> d; > d[0] = &function; > d[0](1, 2, 3); > > Then definitely that's possible. > > > It would be more natural. > > Can you elaborate on what you mean so that I don't > misunderstand what you mean? What I mean is overloading operator() with the types of the tuple so you can call the dispatcher like a function. Does that clarify?

2 1

Re: [boost] GIL Image Processing Library - Undefined Behavior
by Ullrich Koethe 20 Oct '06

20 Oct '06

Hi again, since there was no response to my earlier questions about undefined behavior, I'd like to bring this up again: GIL makes extensive use of reinterpret_cast and gil_reinterpret_cast. The former is, for example, used in code similar to the following: short * imagedata = new short[3*image_size]; rgb16s_t * rgbdata = (rgb16s_t *)imagedata; gil_reinterpret_cast is defined as template <class OutPtr, class In> OutPtr gil_reinterpret_cast(In * p) { return static_cast<OutPtr>(static_cast<void *>(p)); } I suspect that undefined behavior results in both cases. IIRC, there is no guarantee that the memory layout of an rgb array is equal to that of a corresponding scalar array with three times as many elements (although this will probably work in practice). Likewise, a static_cast from void * is only allowed back to the original pointer type, not to a different type. Can someone more familiar with the fine points of C++ confirm these suspicions? If they are true, I think the issue should be resolved before inclusion into boost. Regards Ulli -- ________________________________________________________________ | | | Ullrich Koethe Universitaet Hamburg / University of Hamburg | | FB Informatik / Dept. of Informatics | | AB Kognitive Systeme / Cognitive Systems Group | | | | Phone: +49 (0)40 42883-2573 Vogt-Koelln-Str. 30 | | Fax: +49 (0)40 42883-2572 D - 22527 Hamburg | | Email: u.koethe(a)computer.org Germany | | koethe(a)informatik.uni-hamburg.de | | WWW: http://kogs-www.informatik.uni-hamburg.de/~koethe/ | |________________________________________________________________|

2 1

GIL Review: example files coming...
by Lubomir Bourdev 20 Oct '06

20 Oct '06

Since several reviewers requested this, we are working on splitting the GIL examples as separate unit example files and consolidating the ones we made due to people's requests. We will provide an "example" directory that compiles the files we have discussed so far: - convolution - affine_transform - packed_pixel (defining 565 RGB pixel) - histogram - x_gradient - mandelbrot (defining a synthetic view) - interleaved_ptr (how to construct your own pixel pointer and reference) (if we get to these:) - vigra_integration - agg_integration (from Joel) We are also going to provide the regression tests (which you can get today if you install ASL) Hopefully these (or most of them) will be available sometime tomorrow, together with a Makefile and jpeg-only dependency. (You can still access all of the above but it is inconvenient) Lubomir

1 0

Re: [boost] GIL Image Processing Library - Undefined Behavior
by Matt Doyle 19 Oct '06

19 Oct '06

Hi Ulli, Section 5.2.10-3 states that this usage is implementation defined, i.e. not portable. That said, if we refer to Sutter[2005] section 92. After he finishes with how bad it is to lie to the compiler he recommends that if it's absolutely necessary it should be done via a void pointer. Given that MHO would be that if the cast really is unavoidable then gil_reinterpret_cast is the correct way to do it (by the book). As for your other example -> rgb16s_t * rgbdata = (rgb16s_t *)imagedata; That's not even C++ is it :-) Matt > [mailto:boost-bounces@lists.boost.org] On Behalf Of Ullrich Koethe > Hi again, > > since there was no response to my earlier questions about undefined > behavior, I'd like to bring this up again: > > GIL makes extensive use of reinterpret_cast and > gil_reinterpret_cast. The > former is, for example, used in code similar to the following: > > short * imagedata = new short[3*image_size]; > rgb16s_t * rgbdata = (rgb16s_t *)imagedata; > > gil_reinterpret_cast is defined as > > template <class OutPtr, class In> > OutPtr gil_reinterpret_cast(In * p) > { > return static_cast<OutPtr>(static_cast<void *>(p)); > } > > I suspect that undefined behavior results in both cases. > IIRC, there is no > guarantee that the memory layout of an rgb array is equal to > that of a > corresponding scalar array with three times as many elements > (although > this will probably work in practice). Likewise, a static_cast > from void * > is only allowed back to the original pointer type, not to a > different type. > > Can someone more familiar with the fine points of C++ confirm these > suspicions? If they are true, I think the issue should be > resolved before > inclusion into boost. > > Regards > Ulli > -- > > ________________________________________________________________ > | | > | Ullrich Koethe Universitaet Hamburg / University of Hamburg | > | FB Informatik / Dept. of Informatics | > | AB Kognitive Systeme / Cognitive Systems Group | > | | > | Phone: +49 (0)40 42883-2573 Vogt-Koelln-Str. 30 | > | Fax: +49 (0)40 42883-2572 D - 22527 Hamburg | > | Email: u.koethe(a)computer.org Germany | > | koethe(a)informatik.uni-hamburg.de | > | WWW: http://kogs-www.informatik.uni-hamburg.de/~koethe/ | > |________________________________________________________________| > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > Scanned by McAfee GroupShield {X3BTB534}

1 0

[Boost-bugs] [ boost-Support Requests-1580760 ] http://www.boost.org ERROR
by SourceForge.net 19 Oct '06

19 Oct '06

Support Requests item #1580760, was opened at 2006-10-19 12:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1580760&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: http://www.boost.org ERROR Initial Comment: Get the following when I try to access http://www.boost.org An error has been encountered in accessing this page. 1. Server: www.boost.org 2. URL path: / 3. Error notes: File does not exist: /home/groups/w/ww/www/htdocs/ 4. Error type: 404 5. Request method: GET 6. Request query string: 7. Time: 2006-10-19 12:34:07 PDT (1161286447) Reporting this problem: The problem you have encountered is with a project web site hosted by SourceForge.net. This issue should be reported to the SourceForge.net-hosted project (not to SourceForge.net) If this is a severe or recurring/persistent problem, please do one of the following, and provide the error text (numbered 1 through 7, above): Contact the project via their designated support resources. Contact the project administrators of this project via email (see the upper right-hand corner of the Project Summary page for their usernames) at user- name(a)users.sourceforge.net If you are a member of the project that maintains this web content, please refer to the Site Documentation regarding the project web service for further assistance. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1580760&group_… ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[program_options] Need workaround for broken stdlib
by Michael Marcin 19 Oct '06

19 Oct '06

Hello, I use program options under 32-bit Windows and I like how easy it is to work with. However I need to support a Windows Mobile 5 based platform that doesn't have a <locale> header. Is there a possible work around for this problem or do I need to roll my own config file solution? P.S. it does have a <locale.h> header which I've attached for reference. Thanks, Michael Marcin // // Copyright (c) Microsoft Corporation. All rights reserved. // // // Use of this source code is subject to the terms of the Microsoft end-user // license agreement (EULA) under which you licensed this SOFTWARE PRODUCT. // If you did not accept the terms of the EULA, you are not authorized to use // this source code. For a copy of the EULA, please see the LICENSE.RTF on your // install media. // /*** *locale.h - definitions/declarations for localization routines * * *Purpose: * This file defines the structures, values, macros, and functions * used by the localization routines. * * [Public] * ****/ #if _MSC_VER > 1000 #pragma once #endif #ifndef _INC_LOCALE #define _INC_LOCALE #if !defined(_WIN32) && !defined(_MAC) #error ERROR: Only Mac or Win32 targets supported! #endif #ifdef _MSC_VER /* * Currently, all MS C compilers for Win32 platforms default to 8 byte * alignment. */ #pragma pack(push,8) #endif /* _MSC_VER */ #ifdef __cplusplus extern "C" { #endif /* Define _CRTIMP */ #ifndef _CRTIMP #ifdef _DLL #define _CRTIMP __declspec(dllimport) #else /* ndef _DLL */ #define _CRTIMP #endif /* _DLL */ #endif /* _CRTIMP */ /* Define __cdecl for non-Microsoft compilers */ #if ( !defined(_MSC_VER) && !defined(__cdecl) ) #define __cdecl #endif /* Define _CRTAPI1 (for compatibility with the NT SDK) */ #ifndef _CRTAPI1 #if _MSC_VER >= 800 && _M_IX86 >= 300 #define _CRTAPI1 __cdecl #else #define _CRTAPI1 #endif #endif #ifndef _MAC #ifndef _WCHAR_T_DEFINED typedef unsigned short wchar_t; #define _WCHAR_T_DEFINED #endif #endif /* ndef _MAC */ /* define NULL pointer value */ #ifndef NULL #ifdef __cplusplus #define NULL 0 #else #define NULL ((void *)0) #endif #endif /* Locale categories */ #define LC_ALL 0 #define LC_COLLATE 1 #define LC_CTYPE 2 #define LC_MONETARY 3 #define LC_NUMERIC 4 #define LC_TIME 5 #define LC_MIN LC_ALL #define LC_MAX LC_TIME /* Locale convention structure */ #ifndef _LCONV_DEFINED struct lconv { char *decimal_point; char *thousands_sep; char *grouping; char *int_curr_symbol; char *currency_symbol; char *mon_decimal_point; char *mon_thousands_sep; char *mon_grouping; char *positive_sign; char *negative_sign; char int_frac_digits; char frac_digits; char p_cs_precedes; char p_sep_by_space; char n_cs_precedes; char n_sep_by_space; char p_sign_posn; char n_sign_posn; }; #define _LCONV_DEFINED #endif /* ANSI: char lconv members default is CHAR_MAX which is compile time dependent. Defining and using _charmax here causes CRT startup code to initialize lconv members properly */ #ifdef _CHAR_UNSIGNED extern int _charmax; extern __inline int __dummy() { return _charmax; } #endif /* function prototypes */ _CRTIMP char * __cdecl setlocale(int, const char *); _CRTIMP struct lconv * __cdecl localeconv(void); #ifndef _MAC #ifndef _WLOCALE_DEFINED /* wide function prototypes */ _CRTIMP wchar_t * __cdecl _wsetlocale(int, const wchar_t *); #define _WLOCALE_DEFINED #endif #endif /* ndef _MAC */ #ifdef __cplusplus } #endif #ifdef _MSC_VER #pragma pack(pop) #endif /* _MSC_VER */ #endif /* _INC_LOCALE */

1 0