RE: svn commit: r611307 - in /incubator/stdcxx/trunk/examples: include/stocks.h tutorial/stocks.cpp
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Saturday, January 12, 2008 12:43 AM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: svn commit: r611307 - in
> /incubator/stdcxx/trunk/examples: include/stocks.h tutorial/stocks.cpp
>
> [EMAIL PROTECTED] wrote:
> > Author: vitek
> > Date: Fri Jan 11 13:36:11 2008
> > New Revision: 611307
> >
> > URL: http://svn.apache.org/viewvc?rev=611307&view=rev
> > Log:
> [...]
> > @@ -153,8 +150,12 @@
> > if (!p)
> > std::cerr<< "\nNot a valid locale: " <<
> GERMAN_LOCALE << '\n';
> > else {
> > +FrankFurtStockXchange *fse = new FrankFurtStockXchange;
>
> We should probably fix the spelling here, too. The city is
> Frankfurt, not Frank Furt. That makes me laugh! ;-)
Strictly speaking in Germany (since I were there recently) exists 2
Frankfurt's:
Frankfurt on the Main and Frankfurt on the Oder... Probably then we
should rename
FrankfurtStockXchange to BerlinStockXchange
(FrankfurtOnTheMainStockXchange is not
so convinient, and all other city's are the country capital's except
NewYork) :-).
Farid.
RE: svn commit: r612428 - /stdcxx/branches/4.2.x/include/rw/_config-msvcrt.h
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Wednesday, January 16, 2008 6:17 PM > To: stdcxx-dev@incubator.apache.org > Subject: Re: svn commit: r612428 - > /stdcxx/branches/4.2.x/include/rw/_config-msvcrt.h > > [EMAIL PROTECTED] wrote: > > Author: faridz > > Date: Wed Jan 16 04:04:48 2008 > > New Revision: 612428 > > > > URL: http://svn.apache.org/viewvc?rev=612428&view=rev > > Log: > > 2008-01-16 Farid Zaripov <[EMAIL PROTECTED]> > > > > * include/rw/_config-msvcrt.h: Don't #define > _RWSTD_NO_LONG_LONG as __int64 > > if long long type is supported by compiler. > > IIRC, this was hardcoded to work around an MSVC 7 bug that > rejected long long and unsigned long long overloads. I don't > have access to 7.0 at the moment to check but if you do and > can confirm this we might want to make the change conditional > on 7.1 and better. I haven't access to MSVC 7.0 anymore since I'm working on 64-bit Windows XP. I can install MSVC 7.0 on the 32-bit Windows XP on VMware virtual machine to verify this change, but instead I propose to dismiss supporting the MSVC 7.0 as we already done with MSVC 6.0. Actually MSVC 7.0 is closer to MSVC 6.0 than to MSVC 7.1 and the stdcxx source has many workarounds for MSVC 7.0, which could be removed. I think that supporting of the 3 latest versions of the MSVC is enough :) Farid.
Re: [PATCH] _mutex.h
From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Ср, 02.01.2008 20:41 To: stdcxx-dev@incubator.apache.org Subject: Re: [PATCH] _mutex.h >> +extern "C" long __cdecl _InterlockedIncrement (long volatile*); >> +extern "C" long __cdecl _InterlockedDecrement (long volatile*); >> +extern "C" long __cdecl _InterlockedExchange (long volatile*, long); > Shouldn't the type of the argument be _RWSTD_INTERLOCKED_T* instead? No. _RWSTD_INTERLOCKED_T #defined only for 32-bit compiler, while intrinsic functions are available in 32 and 64-bit compilers. > If not, our convention is to put the cv-qualifier(s) before the type, > not after it (i.e., const T* or volatile T*, rather than T const* or > T volatile*). Farid.
Running the boost regression tests with stdcxx
Running the boost regression tests on Windows: 1. install svn client and setup PATH variable to point to svn.exe dirctory. 2. install the latest release of the python (2.5.1). 3. build stdcxx library (it's enough to build only in 15d configuration) 4. extract https://issues.apache.org/jira/secure/attachment/12372322/boost_regress_win.zip archive to the hard disk. 5. update stdcxx_ver variable in boost_regress\runtests.bat file if the version of the stdcxx is differ from 4.2.0 6. update stdcxx_dir variable in boost_regress\runtests.bat file to point to directory, specified as BUILDDIR parameter when for configure.bat in step 3. 7. update %compiler%.patch files: - the path to the python installation directory in "using pythion" line; - the version of the stdcxx if it's differ from 4.2.0, the path to the stdcxx source directory (TOPDIR), the path to the stdcxx build directory (BUILDDIR) in "using stdcxx" line; Format of the using stdcxx line: using stdcxx : VERSION : TOPDIR BUILDDIR ; - the path to the intel compiler if needed. 9. run runtests.bat with one or more compilers for the testring, i.e. for perform testing ith the all compilers use: runtests.bat msvc-7.1 msvc-8.0 msvc-8.0-x64 msvc-9.0 msvc-9.0-x64 icc-9.1 icc-9.1-x64 icc-10.0 icc-10.-x64 Note that the disk space, used for the one compiler about to 5Gb. The time per single compiler testing about to 2.5 hours on my Intel Core2Duo E4400 at 3GHz clock speed. I've not ported the runtests.bat to unix shell script yet, so I've attached the set of the files, which I've used for the testing. Running the boost regression tests on gcc: 1. assuming that the python 2.5 already installed 2. build stdcxx library (it's enough to build only in 15d configuration) specifying BUILDIR=%BUILDROOT%/gcc/%BUILDMODE% 3. extract https://issues.apache.org/jira/secure/attachment/12372323/boost_regress_gcc.zip archive to the hard disk and set executable attribute for run.sh and patch_boost files. 6. update gcc.patch file: - the version of the stdcxx if it's differ from 4.2.0, the path to the stdcxx source directory (TOPDIR), the path to the stdcxx build directory (%BUILDROOT%) in "using stdcxx" line; Format of the using stdcxx line: using stdcxx : %VERSION% : %TOPDIR% %BUILDROOT% ; 7. update the stdcxx version in run.sh file 8. run run.sh Running the boost regression tests on sunpro/linux: 1. assuming that the python 2.5 already installed 2. build stdcxx library (it's enough to build only in 15d configuration) specifying BUILDIR=%BUILDROOT%/sun/%BUILDMODE% 3. extract https://issues.apache.org/jira/secure/attachment/12372324/boost_regress_sun.zip archive to the hard disk and set executable attribute for run.sh and patch_boost files. 6. update sun.patch file: - the version of the stdcxx if it's differ from 4.2.0, the path to the stdcxx source directory (TOPDIR), the path to the stdcxx build directory (%BUILDROOT%) in "using stdcxx" line; Format of the using stdcxx line: using stdcxx : %VERSION% : %TOPDIR% %BUILDROOT% ; 7. update the stdcxx version in run.sh file 8. run run.sh To not interfere with my test results change the --runner= option in runtests.bat and run.sh files, i.e. by using some suffix (platform name or something else). The tests results will be shown in some time at this page: http://beta.boost.org/development/tests/trunk/developer/summary.html Farid.
[PATCH] _mutex.h
The one of the problems in boost regression tests on MSVC 7.1 was caused by
#definition
_InterlockedIncrement as InterlockedIncrement. The patch below fixes the
problem. The MSVC 7.1
also has the intrinsic interlocked functions, but the are not declared in any
header files (in MSVC 8.0
and higher they are declared in ). The patch below resolves this
problem.
ChangeLog:
* include/rw/_config-msvcrt.h: Don't #define _RWSTD_NO_LONG_LONG as __int64
if long long type is supported by compiler.
* include/rw/_mutex.h: Use intrinsic interlocked functions on MSVC 7.1 and
ICC.
Declare the interlocked functions instead of #including .
Index: include/rw/_config-msvcrt.h
===
--- include/rw/_config-msvcrt.h (revision 607181)
+++ include/rw/_config-msvcrt.h (working copy)
@@ -89,7 +89,9 @@
#endif // _RWSTD_NO_STATIC_CONST_MEMBER_DEFINITION
// enable iostream and locale support for long long integers
-#define _RWSTD_LONG_LONG __int64
+#ifdef _RWSTD_NO_LONG_LONG
+# define _RWSTD_LONG_LONG __int64
+#endif
#if defined (_WIN64)
// FIXME: handle by forward declaring fuctions in
Index: include/rw/_mutex.h
===
--- include/rw/_mutex.h (revision 607181)
+++ include/rw/_mutex.h (working copy)
@@ -119,6 +119,12 @@
#include
#define _RWSTD_MUTEX_T _RTL_CRITICAL_SECTION
+#ifndef _MSC_VER
+# define _InterlockedIncrement InterlockedIncrement
+# define _InterlockedDecrement InterlockedDecrement
+# define _InterlockedExchange InterlockedExchange
+#endif// _MSC_VER
+
# else // if defined (_RWSTD_NO_FWD_DECLARATIONS)
// avoid #including this header (MFC doesn't like it)
@@ -142,7 +148,7 @@
DeleteCriticalSection (_RTL_CRITICAL_SECTION*);
-#if defined _RWSTD_INTERLOCKED_T && (!defined (_MSC_VER) || _MSC_VER < 1400)
+#if defined (_RWSTD_INTERLOCKED_T) && !defined (_MSC_VER)
__declspec (dllimport) long __stdcall
InterlockedIncrement (_RWSTD_INTERLOCKED_T*);
@@ -157,7 +163,7 @@
# define _InterlockedDecrement InterlockedDecrement
# define _InterlockedExchange InterlockedExchange
-#endif // _RWSTD_INTERLOCKED_T && (!_MSC_VER || _MSC_VER < 1400)
+#endif // _RWSTD_INTERLOCKED_T && !_MSC_VER
} // extern "C"
@@ -176,21 +182,35 @@
# endif // _RWSTD_NO_FWD_DECLARATIONS
-# if defined (_MSC_VER) && _MSC_VER >= 1400 && !defined (__INTEL_COMPILER)
-#include
+# ifdef _MSC_VER
+extern "C" long __cdecl _InterlockedIncrement (long volatile*);
+extern "C" long __cdecl _InterlockedDecrement (long volatile*);
+extern "C" long __cdecl _InterlockedExchange (long volatile*, long);
+#ifndef __INTEL_COMPILER
+# pragma intrinsic (_InterlockedIncrement)
+# pragma intrinsic (_InterlockedDecrement)
+# pragma intrinsic (_InterlockedExchange)
+#endif // __INTEL_COMPILER
-#pragma intrinsic (_InterlockedIncrement)
-#pragma intrinsic (_InterlockedIncrement16)
-#pragma intrinsic (_InterlockedDecrement)
-#pragma intrinsic (_InterlockedDecrement16)
-#pragma intrinsic (_InterlockedExchange)
+#if _MSC_VER >= 1400 && !defined (__INTEL_COMPILER)
+extern "C" short __cdecl _InterlockedIncrement16 (short volatile*);
+extern "C" short __cdecl _InterlockedDecrement16 (short volatile*);
+# pragma intrinsic (_InterlockedIncrement16)
+# pragma intrinsic (_InterlockedDecrement16)
+#endif // _MSC_VER >= 1400 && !__INTEL_COMPILER
#ifdef _M_X64
-# pragma intrinsic (_InterlockedIncrement64)
-# pragma intrinsic (_InterlockedDecrement64)
-# pragma intrinsic (_InterlockedExchange64)
-#endif
-# endif // _MSC_VER >= 1400 && !__INTEL_COMPILER
+extern "C" long long __cdecl _InterlockedIncrement64 (long long volatile*);
+extern "C" long long __cdecl _InterlockedDecrement64 (long long volatile*);
+extern "C" long long __cdecl _InterlockedExchange64 (long long volatile*,
+ long long);
+# ifndef __INTEL_COMPILER
+#pragma intrinsic (_InterlockedIncrement64)
+#pragma intrinsic (_InterlockedDecrement64)
+#pragma intrinsic (_InterlockedExchange64)
+# endif // __INTEL_COMPILER
+#endif // _M_X64
+# endif // _MSC_VER
_RWSTD_NAMESPACE (__rw) {
[jira] Issue Comment Edited: (STDCXX-430) building Boost with stdcxx
[ https://issues.apache.org/jira/browse/STDCXX-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554907 ] farid edited comment on STDCXX-430 at 12/29/07 3:07 AM: The new tickets in boost tracking system: http://svn.boost.org/trac/boost/ticket/1542 http://svn.boost.org/trac/boost/ticket/1543 http://svn.boost.org/trac/boost/ticket/1545 http://svn.boost.org/trac/boost/ticket/1547 was (Author: farid): The new tickets in boost tracking systm: http://svn.boost.org/trac/boost/ticket/1542 http://svn.boost.org/trac/boost/ticket/1543 http://svn.boost.org/trac/boost/ticket/1545 http://svn.boost.org/trac/boost/ticket/1547 > building Boost with stdcxx > -- > > Key: STDCXX-430 > URL: https://issues.apache.org/jira/browse/STDCXX-430 > Project: C++ Standard Library > Issue Type: Improvement > Components: External >Affects Versions: 4.2.0 >Reporter: Martin Sebor > Assignee: Farid Zaripov >Priority: Critical > Fix For: 4.2.1 > > Attachments: boost-1.34.1.patch, boost_regress_gcc.zip, > boost_regress_sun.zip, boost_regress_win.zip > > > This is a placeholder issue to make it possible and easy to build the Boost > libraries on top of stdcxx. > Each stdcxx bug revealed by Boost must have an issue. The issue should be > linked to this one. > Changes contributed to Boost (such as stdcxx .jam files) should be tracked as > subtasks of this issue. > Each bug in Boost should be filed in the Boost bug tracking database and > cross-referenced in comments on this issue. > See the following threads for details of the project: > http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg02910.html > http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03089.html > http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03410.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-430) building Boost with stdcxx
[ https://issues.apache.org/jira/browse/STDCXX-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554907 ] Farid Zaripov commented on STDCXX-430: -- The new tickets in boost tracking systm: http://svn.boost.org/trac/boost/ticket/1542 http://svn.boost.org/trac/boost/ticket/1543 http://svn.boost.org/trac/boost/ticket/1545 http://svn.boost.org/trac/boost/ticket/1547 > building Boost with stdcxx > -- > > Key: STDCXX-430 > URL: https://issues.apache.org/jira/browse/STDCXX-430 > Project: C++ Standard Library > Issue Type: Improvement > Components: External >Affects Versions: 4.2.0 >Reporter: Martin Sebor > Assignee: Farid Zaripov >Priority: Critical > Fix For: 4.2.1 > > Attachments: boost-1.34.1.patch, boost_regress_gcc.zip, > boost_regress_sun.zip, boost_regress_win.zip > > > This is a placeholder issue to make it possible and easy to build the Boost > libraries on top of stdcxx. > Each stdcxx bug revealed by Boost must have an issue. The issue should be > linked to this one. > Changes contributed to Boost (such as stdcxx .jam files) should be tracked as > subtasks of this issue. > Each bug in Boost should be filed in the Boost bug tracking database and > cross-referenced in comments on this issue. > See the following threads for details of the project: > http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg02910.html > http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03089.html > http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03410.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-430) building Boost with stdcxx
[ https://issues.apache.org/jira/browse/STDCXX-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-430: - Attachment: boost_regress_win.zip > building Boost with stdcxx > -- > > Key: STDCXX-430 > URL: https://issues.apache.org/jira/browse/STDCXX-430 > Project: C++ Standard Library > Issue Type: Improvement > Components: External >Affects Versions: 4.2.0 >Reporter: Martin Sebor > Assignee: Farid Zaripov >Priority: Critical > Fix For: 4.2.1 > > Attachments: boost-1.34.1.patch, boost_regress_gcc.zip, > boost_regress_sun.zip, boost_regress_win.zip > > > This is a placeholder issue to make it possible and easy to build the Boost > libraries on top of stdcxx. > Each stdcxx bug revealed by Boost must have an issue. The issue should be > linked to this one. > Changes contributed to Boost (such as stdcxx .jam files) should be tracked as > subtasks of this issue. > Each bug in Boost should be filed in the Boost bug tracking database and > cross-referenced in comments on this issue. > See the following threads for details of the project: > http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg02910.html > http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03089.html > http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03410.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-430) building Boost with stdcxx
[ https://issues.apache.org/jira/browse/STDCXX-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-430: - Attachment: boost_regress_sun.zip boost_regress_gcc.zip > building Boost with stdcxx > -- > > Key: STDCXX-430 > URL: https://issues.apache.org/jira/browse/STDCXX-430 > Project: C++ Standard Library > Issue Type: Improvement > Components: External >Affects Versions: 4.2.0 >Reporter: Martin Sebor > Assignee: Farid Zaripov >Priority: Critical > Fix For: 4.2.1 > > Attachments: boost-1.34.1.patch, boost_regress_gcc.zip, > boost_regress_sun.zip, boost_regress_win.zip > > > This is a placeholder issue to make it possible and easy to build the Boost > libraries on top of stdcxx. > Each stdcxx bug revealed by Boost must have an issue. The issue should be > linked to this one. > Changes contributed to Boost (such as stdcxx .jam files) should be tracked as > subtasks of this issue. > Each bug in Boost should be filed in the Boost bug tracking database and > cross-referenced in comments on this issue. > See the following threads for details of the project: > http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg02910.html > http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03089.html > http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03410.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-430) building Boost with stdcxx
[ https://issues.apache.org/jira/browse/STDCXX-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554324 ] Farid Zaripov commented on STDCXX-430: -- Steps for the building boost with stdcxx. 1. build the all build types of the stdcxx with BUILDDIR=%stdcxx_build_dir%/%buildtype% 2. extract the boost sources and apply attached boost-1.34.1.patch 3. build bjam executable by invoking %boostdir%/tools/jam/src/build.sh (build.bat for Windows) and copy the built bjam excutable from %boostdir%/tools/jam/src/bin.linux86 (%boostdir%/tools/jam/src/bin.ntx86 for Windows) to some directory in the path i.e. /usr/local/bin (C:\windows for Windows) 4. edit %boostdir%/tools/build/v2/user-config.jam file to configure the available toolsets and tools and add the line for configuring the stdcxx: using stdcxx : %stdcxx_version% : %stdcxx_root_dir% %stdcxx_build_dir% ; I.e. for linux add the following lines: using gcc ; using python ; using stdcxx : 4.2.0 : /usr/src/stdcxx-4.2.0 /usr/tmp/stdcxx-4.2.0 ; I.e. for windows add the following lines: using msvc ; using python : 2.5 : C:/Python25 ; using stdcxx : 4.2.0 : C:/stdcxx-4.2.0 C:/build/stdcxx-4.2.0 ; 5. build the requested boost libraries by invoking bjam from %boostdir%, i.e.: bjam --v2 --toolset=msvc-7.1 stdlib=stdcxx-4.2.0 variant=release link=static runtime-link=static threading=single address-model=32 stage or bjam --v2 --toolset=gcc stdlib=stdcxx-4.2.0 variant=debug link=shared runtime-link=shared threading=multi address-model=64 stage 6. install the built boost libraries: bjam --v2 --toolset=msvc-7.1 stdlib=stdcxx-4.2.0 variant=release link=static runtime-link=static threading=single address-model=32 install or bjam --v2 --toolset=gcc stdlib=stdcxx-4.2.0 variant=debug link=shared runtime-link=shared threading=multi address-model=64 install > building Boost with stdcxx > -- > > Key: STDCXX-430 > URL: https://issues.apache.org/jira/browse/STDCXX-430 > Project: C++ Standard Library > Issue Type: Improvement > Components: External >Affects Versions: 4.2.0 >Reporter: Martin Sebor > Assignee: Farid Zaripov >Priority: Critical > Fix For: 4.2.1 > > Attachments: boost-1.34.1.patch > > > This is a placeholder issue to make it possible and easy to build the Boost > libraries on top of stdcxx. > Each stdcxx bug revealed by Boost must have an issue. The issue should be > linked to this one. > Changes contributed to Boost (such as stdcxx .jam files) should be tracked as > subtasks of this issue. > Each bug in Boost should be filed in the Boost bug tracking database and > cross-referenced in comments on this issue. > See the following threads for details of the project: > http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg02910.html > http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03089.html > http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03410.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-430) building Boost with stdcxx
[ https://issues.apache.org/jira/browse/STDCXX-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-430: - Attachment: boost-1.34.1.patch > building Boost with stdcxx > -- > > Key: STDCXX-430 > URL: https://issues.apache.org/jira/browse/STDCXX-430 > Project: C++ Standard Library > Issue Type: Improvement > Components: External >Affects Versions: 4.2.0 >Reporter: Martin Sebor > Assignee: Farid Zaripov >Priority: Critical > Fix For: 4.2.1 > > Attachments: boost-1.34.1.patch > > > This is a placeholder issue to make it possible and easy to build the Boost > libraries on top of stdcxx. > Each stdcxx bug revealed by Boost must have an issue. The issue should be > linked to this one. > Changes contributed to Boost (such as stdcxx .jam files) should be tracked as > subtasks of this issue. > Each bug in Boost should be filed in the Boost bug tracking database and > cross-referenced in comments on this issue. > See the following threads for details of the project: > http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg02910.html > http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03089.html > http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03410.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-610) [Windows] add version information to the library
[ https://issues.apache.org/jira/browse/STDCXX-610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-610: - Attachment: libstd.rc The draft of the libstd.rc is attached. > [Windows] add version information to the library > > > Key: STDCXX-610 > URL: https://issues.apache.org/jira/browse/STDCXX-610 > Project: C++ Standard Library > Issue Type: New Feature > Components: Build >Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0 > Environment: MSVC and Intel C++ on Windows >Reporter: Martin Sebor >Assignee: Farid Zaripov >Priority: Minor > Fix For: 4.2.1 > > Attachments: libstd.rc > > > From the thread starting at > http://www.nabble.com/-VERSION-linker-option-on-Windows-tf4650202.html: > Original Message > Subject: Re: /VERSION linker option on Windows > Date: Thu, 18 Oct 2007 18:20:09 -0500 > From: William A. Rowe, Jr. <[EMAIL PROTECTED]> > Reply-To: stdcxx-dev@incubator.apache.org > To: stdcxx-dev@incubator.apache.org > References: <[EMAIL PROTECTED]> > Martin Sebor wrote: > > Are we making use of it? If not, should we be? > > > > http://msdn2.microsoft.com/en-us/library/h88b7dc8(VS.80).aspx > It's not terribly interesting. > You really want to focus on the VERSIONINFO member of the library's dll > resource, > which provides a whole lot more meaningful information to the user/developer. > I presume you already attach that? > Bill -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: [jira] Commented: (STDCXX-675) [MSVC] implement autolinking feature
> -Original Message- > From: Travis Vitek (JIRA) [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 19, 2007 1:22 AM > To: stdcxx-dev@incubator.apache.org > Subject: [jira] Commented: (STDCXX-675) [MSVC] implement > autolinking feature > > > [ > https://issues.apache.org/jira/browse/STDCXX-675?page=com.atla > ssian.jira.plugin.system.issuetabpanels:comment-tabpanel#actio > n_12552933 ] > > Travis Vitek commented on STDCXX-675: > - > > If the new user takes advantage of the autolinking feature, > they will have to modify their build system to get it to work > with a previous version of the library. i.e. they will need > to explicitly link the library file when they go back to 4.2.0. You're right, but what the type of incompatibility of this case? :) Source? - No, because there no source changes. Binary? - No again :) > Will this ever be useful for any compiler other than MSVC and > ICC/Windows? Yes, if the autolinking feature will be implemented there :) > Is there a way that we can ensure the user links > the right library on all platforms? We can define some symbol in the library with the unique name for the each build type, and make the reference to this symbol in . Then in case the linking with incorrect library the "undefined symbol reference" linker error will be issued. > This wouldn't avoid the > need to explicitly link the library, but it would eliminate > issues with linking the wrong library. Right. Farid.
RE: _RWSTD_VER value on trunk
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Wednesday, December 19, 2007 7:17 AM > To: stdcxx-dev@incubator.apache.org > Subject: Re: _RWSTD_VER value on trunk > I like the idea to #define _RWSTD_VER macro in config.h. This solution will helps in the implementing the STDCXX-610 issue (#include instead of a bit complex ). Also I'd like to #define _RWSHARED there, because at the moment the user should explicitly #define this macro in user's project settings (like as the build infrastructure defines this macro when building the examples and tests in shared builds). Actually _RWSHARED is required only on Windows, and we can avoid this macro if we will check the __declspec(dllexport/dllimport) at the configure step (the DLL_EXPORT.cpp test from https://issues.apache.org/jira/secure/attachment/12371951/dllexport.patc h will fail in static builds). And, possibly, the _RWSTDDEBUG. Because what the sence to link the some project, compiled without _RWSTDDEBUG #defined, with the library, built with _RWSTDDEBUG #defined? And vice versa. Farid.
[jira] Assigned: (STDCXX-610) [Windows] add version information to the library
[ https://issues.apache.org/jira/browse/STDCXX-610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov reassigned STDCXX-610: Assignee: Farid Zaripov > [Windows] add version information to the library > > > Key: STDCXX-610 > URL: https://issues.apache.org/jira/browse/STDCXX-610 > Project: C++ Standard Library > Issue Type: New Feature > Components: Build >Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0 > Environment: MSVC and Intel C++ on Windows >Reporter: Martin Sebor >Assignee: Farid Zaripov >Priority: Minor > Fix For: 4.2.1 > > > From the thread starting at > http://www.nabble.com/-VERSION-linker-option-on-Windows-tf4650202.html: > Original Message > Subject: Re: /VERSION linker option on Windows > Date: Thu, 18 Oct 2007 18:20:09 -0500 > From: William A. Rowe, Jr. <[EMAIL PROTECTED]> > Reply-To: stdcxx-dev@incubator.apache.org > To: stdcxx-dev@incubator.apache.org > References: <[EMAIL PROTECTED]> > Martin Sebor wrote: > > Are we making use of it? If not, should we be? > > > > http://msdn2.microsoft.com/en-us/library/h88b7dc8(VS.80).aspx > It's not terribly interesting. > You really want to focus on the VERSIONINFO member of the library's dll > resource, > which provides a whole lot more meaningful information to the user/developer. > I presume you already attach that? > Bill -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[PATCH] using dllexport/dllimport directives where they are supported
The patch is attached here: https://issues.apache.org/jira/secure/attachment/12371951/dllexport.patc h I've tried to build the stdcxx with this patch on aCC/HP-UX. --- $ uname -a HP-UX td194 B.11.31 U ia64 3426292962 unlimited-user license $ aCC -V aCC: HP C/aC++ B3910B A.06.14 [Feb 22 2007] -- The library itself is build successfully, but many examples are failed (I suppose that they are failed because of internal compiler error). The error test (the build log for the localedef utility is here: https://issues.apache.org/jira/secure/attachment/12371955/gmake.log ) --- Signal 11, code 2 (invalid permissions for object) (0) 0x05bc8520 term_on_signal + 0x3c0 [/opt/aCC/lbin/ecom] (1) 0xe00108756900 Signal 11 (SIGSEGV) delivered (2) 0x066ad990 $cold_define_one_virtual_function_table + 0xd0 [/opt/aCC/lbin/ecom] (3) 0x05c3d6d0 f_define_virtual_function_tables + 0x210 [/opt/aCC/lbin/ecom] (4) 0x05c3d820 f_define_virtual_function_tables + 0x360 [/opt/aCC/lbin/ecom] (5) 0x05c3de30 define_virtual_function_tables + 0x110 [/opt/aCC/lbin/ecom] (6) 0x05c3dfc0 define_scope_virtual_function_tables + 0x120 [/opt/aCC/lbin/ecom] (7) 0x05c3e090 define_scope_virtual_function_tables + 0x1f0 [/opt/aCC/lbin/ecom] (8) 0x04ce56f0 lower_il_memory_region + 0x1d0 [/opt/aCC/lbin/ecom] (9) 0x05bc2cf0 file_scope_il_wrapup_part_3 + 0xa0 [/opt/aCC/lbin/ecom] (10) 0x05bc3250 wrap_up_file_scopes + 0x1b0 [/opt/aCC/lbin/ecom] (11) 0x05b53c30 fe_wrapup + 0xf0 [/opt/aCC/lbin/ecom] (12) 0x05bae170 cfe_main + 0x1f0 [/opt/aCC/lbin/ecom] (13) 0x05bab230 main + 0x30 [/opt/aCC/lbin/ecom] (14) 0x6000c004e550 main_opd_entry + 0x50 [/usr/lib/hpux32/dld.so] Compilation terminated. -- Another issue is dropping the dllexport attribute in case when the some class is declared as _RWSTD_EXPORT, but the class member definition doesn't have the _RWSTD_EXPORT attribute: -- "/house/FZaripov/trunk/include/loc/_ctype.h", line 329: warning #3397-D: dllexport/dllimport conflict with "std::ctype::narrow" (declared at line 264); dllimport/dllexport dropped ctype::narrow (char_type __c, char __dfault) const -- The MSVC doesn't requires to specify the dllexport attribute in function or class member definition if this function or class is declared with this attribute. Farid.
[jira] Updated: (STDCXX-408) make use of __declspec(dll{export,import}) on all platforms
[
https://issues.apache.org/jira/browse/STDCXX-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov updated STDCXX-408:
-
Attachment: gmake.log
The gmake.log file is attached.
> make use of __declspec(dll{export,import}) on all platforms
> ---
>
> Key: STDCXX-408
> URL: https://issues.apache.org/jira/browse/STDCXX-408
> Project: C++ Standard Library
> Issue Type: Improvement
> Components: Build
>Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0
> Environment: HP aCC 3.37 and beyond, gcc/Linux
>Reporter: Martin Sebor
>Assignee: Farid Zaripov
> Fix For: 4.2.1
>
> Attachments: dllexport.patch, gmake.log
>
>
> Starting with HP aCC 3.37 the compiler supports the __declspec(dllexport) and
> __declspec(dllimport) decorators on declarations of symbols with external
> linkage. According to the Release Notes for the compiler, "Support of these
> keywords enhances the performance of shared libraries and relieves the usage
> of HP_DEFINED_EXTERNAL pragmas and +Oextern= list to hide the non-exported
> symbols." See http://docs.hp.com/en/2212/A-03-37relnotes.html.
> We should enable this in our builds.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
RE: svn commit: r605548 - in /incubator/stdcxx/branches/4.2.x/include: rw/_defs.h rw/_specialized.h sstream string
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Wednesday, December 19, 2007 6:27 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: svn commit: r605548 - in
> /incubator/stdcxx/branches/4.2.x/include: rw/_defs.h
> rw/_specialized.h sstream string
> incubator/stdcxx/branches/4.2.x/include/rw/_specialized.h Wed Dec
> > +++ 19 06:19:33 2007
> > @@ -69,8 +69,12 @@
> > {
> > typedef _RWSTD_CONTAINER_SIZE_TYPE _RWSizeT;
> >
> > -_RWSizeT __cap = _RWSTD_STATIC_CAST (_RWSizeT,
> > - __size *
> _RWSTD_NEW_CAPACITY_RATIO);
> > +const _RWSizeT __ratio = _RWSizeT (
> (_RWSTD_NEW_CAPACITY_RATIO << 10)
> > + / _RWSTD_RATIO_DIVIDER);
> > +
> > +const _RWSizeT __cap = (__size >> 10) * __ratio
> > + + (((__size & 0x3ff) * __ratio) >> 10);
> > +
>
> Sorry to bringing this up only now that you've committed it...
>
> Would it make sense to make __ratio a global macro instead of
> repeating the same computation in several places?
But we have two __ratio's: __ratio for _RWSTD_NEW_CAPACITY_RATIO
and __ratio for _RWSTD_STRING_CAPACITY_RATIO.
> Also, since
> the divider is used only in the computation of the ratio and
> since we're hardcoding the 10 in the left shift, it sees we
> might as well hardcode the 1000 and forget the divider.
The 10 in left shift is related to the ">> 10" and "& 0x3ff"
operations, but 1000 value is independent from them.
We can define _RWSTD_NEW_CAPACITY_RATIO as 16180
and use 1 instead of 1000 (i.e. if the _RWSTD_NEW_CAPACITY_RATIO
will contain the 5 significant digits).
Are we need the possibility to change the _RWSTD_NEW_CAPACITY
value to some other? Or we can assume that this value is fixed?
Farid.
[jira] Updated: (STDCXX-408) make use of __declspec(dll{export,import}) on all platforms
[
https://issues.apache.org/jira/browse/STDCXX-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov updated STDCXX-408:
-
Patch Info: [Patch Available]
> make use of __declspec(dll{export,import}) on all platforms
> ---
>
> Key: STDCXX-408
> URL: https://issues.apache.org/jira/browse/STDCXX-408
> Project: C++ Standard Library
> Issue Type: Improvement
> Components: Build
>Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0
> Environment: HP aCC 3.37 and beyond, gcc/Linux
>Reporter: Martin Sebor
>Assignee: Farid Zaripov
> Fix For: 4.2.1
>
> Attachments: dllexport.patch
>
>
> Starting with HP aCC 3.37 the compiler supports the __declspec(dllexport) and
> __declspec(dllimport) decorators on declarations of symbols with external
> linkage. According to the Release Notes for the compiler, "Support of these
> keywords enhances the performance of shared libraries and relieves the usage
> of HP_DEFINED_EXTERNAL pragmas and +Oextern= list to hide the non-exported
> symbols." See http://docs.hp.com/en/2212/A-03-37relnotes.html.
> We should enable this in our builds.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-408) make use of __declspec(dll{export,import}) on all platforms
[
https://issues.apache.org/jira/browse/STDCXX-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov updated STDCXX-408:
-
Attachment: dllexport.patch
The patch is attached.
> make use of __declspec(dll{export,import}) on all platforms
> ---
>
> Key: STDCXX-408
> URL: https://issues.apache.org/jira/browse/STDCXX-408
> Project: C++ Standard Library
> Issue Type: Improvement
> Components: Build
>Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0
> Environment: HP aCC 3.37 and beyond, gcc/Linux
>Reporter: Martin Sebor
>Assignee: Farid Zaripov
> Fix For: 4.2.1
>
> Attachments: dllexport.patch
>
>
> Starting with HP aCC 3.37 the compiler supports the __declspec(dllexport) and
> __declspec(dllimport) decorators on declarations of symbols with external
> linkage. According to the Release Notes for the compiler, "Support of these
> keywords enhances the performance of shared libraries and relieves the usage
> of HP_DEFINED_EXTERNAL pragmas and +Oextern= list to hide the non-exported
> symbols." See http://docs.hp.com/en/2212/A-03-37relnotes.html.
> We should enable this in our builds.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-250) std::operator>>(istream&, string&) fails to set failbit after it extracts 0 characters
[
https://issues.apache.org/jira/browse/STDCXX-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov resolved STDCXX-250.
--
Resolution: Fixed
Resolved thus: http://svn.apache.org/viewvc?rev=605577&view=rev
The regression test added thus: http://svn.apache.org/viewvc?rev=605586&view=rev
> std::operator>>(istream&, string&) fails to set failbit after it extracts 0
> characters
> --
>
> Key: STDCXX-250
> URL: https://issues.apache.org/jira/browse/STDCXX-250
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 21. Strings
>Affects Versions: 4.1.2, 4.1.3
> Environment: all
> Reporter: Martin Sebor
>Assignee: Farid Zaripov
>Priority: Minor
> Fix For: 4.2.1
>
> Attachments: istream.cc.diff
>
>
> 21.3.7.9, p3 says about the string extractor: "If the function extracts no
> characters, it calls is.setstate(ios::failbit), which may throw
> ios_base::failure (27.4.4.3)." The test program below shows that in
> unbuffered mode stdcxx fails to do so when an exception is thrown during the
> third call to underflow().
> $ cat v.cpp && make v && ./v
> #include
> #include
> #include
> #include
> int main ()
> {
> struct: std::streambuf {
> int_type underflow () {
> static int i = 0;
> // i == 0: sgect() invoked from sentry ctor
> // i == 1: sgetc() invoked from operator>>()
> // i == 2: sbumpc() invoked from operator>>()
> return 1 < i++ ? throw i : 'x';
> }
> } buf;
> std::istream is (&buf);
> std::string s;
> is >> s;
> std::printf ("state = %c%c%c, string = \"%s\" (length %u)\n",
> is.rdstate () & is.badbit ? 'B' : '-',
> is.rdstate () & is.eofbit ? 'E' : '-',
> is.rdstate () & is.failbit ? 'F' : '-',
> s.c_str (), s.size ());
> assert ("x" == s);
> assert ((is.failbit | is.badbit) == is.rdstate ());
> }
> gcc -c -I/build/sebor/dev/stdlib/include/ansi -D_RWSTDDEBUG -pthreads
> -D_RWSTD_USE_CONFIG -I/build/sebor/dev/stdlib/include
> -I/build/sebor/gcc-4.1.0-15s/include -I/build/sebor/dev/stdlib/../rwtest
> -I/build/sebor/dev/stdlib/../rwtest/include
> -I/build/sebor/dev/stdlib/tests/include -pedantic -nostdinc++ -g -W -Wall
> -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long v.cpp
> gcc v.o -o v -L/build/sebor/gcc-4.1.0-15s/rwtest -lrwtest15s -pthreads
> -L/build/sebor/gcc-4.1.0-15s/lib -lstd15s -lsupc++ -lm
> state = B--, string = "x" (length 1)
> Assertion failed: (is.failbit | is.badbit) == is.rdstate (), file v.cpp, line
> 30
> Abort (core dumped)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-250) std::operator>>(istream&, string&) fails to set failbit after it extracts 0 characters
[
https://issues.apache.org/jira/browse/STDCXX-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov updated STDCXX-250:
-
Component/s: (was: 27. Input/Output)
21. Strings
Component changed to 21.strings (the opertator>>(istream&, string&) is related
to 21.string.io part of the standard).
> std::operator>>(istream&, string&) fails to set failbit after it extracts 0
> characters
> --
>
> Key: STDCXX-250
> URL: https://issues.apache.org/jira/browse/STDCXX-250
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 21. Strings
>Affects Versions: 4.1.2, 4.1.3
> Environment: all
> Reporter: Martin Sebor
>Assignee: Farid Zaripov
>Priority: Minor
> Fix For: 4.2.1
>
> Attachments: istream.cc.diff
>
>
> 21.3.7.9, p3 says about the string extractor: "If the function extracts no
> characters, it calls is.setstate(ios::failbit), which may throw
> ios_base::failure (27.4.4.3)." The test program below shows that in
> unbuffered mode stdcxx fails to do so when an exception is thrown during the
> third call to underflow().
> $ cat v.cpp && make v && ./v
> #include
> #include
> #include
> #include
> int main ()
> {
> struct: std::streambuf {
> int_type underflow () {
> static int i = 0;
> // i == 0: sgect() invoked from sentry ctor
> // i == 1: sgetc() invoked from operator>>()
> // i == 2: sbumpc() invoked from operator>>()
> return 1 < i++ ? throw i : 'x';
> }
> } buf;
> std::istream is (&buf);
> std::string s;
> is >> s;
> std::printf ("state = %c%c%c, string = \"%s\" (length %u)\n",
> is.rdstate () & is.badbit ? 'B' : '-',
> is.rdstate () & is.eofbit ? 'E' : '-',
> is.rdstate () & is.failbit ? 'F' : '-',
> s.c_str (), s.size ());
> assert ("x" == s);
> assert ((is.failbit | is.badbit) == is.rdstate ());
> }
> gcc -c -I/build/sebor/dev/stdlib/include/ansi -D_RWSTDDEBUG -pthreads
> -D_RWSTD_USE_CONFIG -I/build/sebor/dev/stdlib/include
> -I/build/sebor/gcc-4.1.0-15s/include -I/build/sebor/dev/stdlib/../rwtest
> -I/build/sebor/dev/stdlib/../rwtest/include
> -I/build/sebor/dev/stdlib/tests/include -pedantic -nostdinc++ -g -W -Wall
> -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long v.cpp
> gcc v.o -o v -L/build/sebor/gcc-4.1.0-15s/rwtest -lrwtest15s -pthreads
> -L/build/sebor/gcc-4.1.0-15s/lib -lstd15s -lsupc++ -lm
> state = B--, string = "x" (length 1)
> Assertion failed: (is.failbit | is.badbit) == is.rdstate (), file v.cpp, line
> 30
> Abort (core dumped)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-666) [MSVC 8-x64] 21.string.cons.cpp test fails in optimized builds due to bad codegeneration by the compiler
[
https://issues.apache.org/jira/browse/STDCXX-666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov resolved STDCXX-666.
--
Resolution: Fixed
The issue resolved thus resolving the STDCXX-226.
> [MSVC 8-x64] 21.string.cons.cpp test fails in optimized builds due to bad
> codegeneration by the compiler
>
>
> Key: STDCXX-666
> URL: https://issues.apache.org/jira/browse/STDCXX-666
> Project: C++ Standard Library
> Issue Type: Bug
> Components: Tests
>Affects Versions: 4.2.0
> Environment: MSVC 8.0-x64, builds 8{d|s}, 12{d|s}
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
> Fix For: 4.2.1
>
>
> The 21.string.cons.cpp test fails with 16 assertions on 64-bit MSVC in
> optimized builds.
> The reason is the bad codegeneration in __rw_new_capacity() inlined in
> std::basic_string ctors. Because of this bug the __rw_new_capacity(0, const
> std::basic_string<> *) returns value greater that size_max() and ctor throws
> exception.
> The temporary workaround might be definition of the __rw_new_capacity() as
> __declspec (noinline).
> --
> Index: include/string
> ===
> --- include/string(revision 593511)
> +++ include/string(working copy)
> @@ -1528,8 +1528,13 @@
> // more specialized version for basic_string<>; may be further specialized
> // in user code for example on a user-defined allocator
>
> +#if !defined (_WIN64) || !defined (_MSC_VER) || defined
> (__INTEL_COMPILER)
> template inline
> _RWSTD_STRING_SIZE_TYPE
> +#else// _WIN64 && _MSC_VER && !__INTEL_COMPILER
> +template __declspec
> +(noinline) _RWSTD_STRING_SIZE_TYPE
> +#endif // !_WIN64 || !_MSC_VER || __INTEL_COMPILER
> __rw_new_capacity (_RWSTD_STRING_SIZE_TYPE __size,
> const _STD::basic_string<_CharT, _Traits,
> _Allocator>*)
> {
> --
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-226) __rw::__rw_new_capacity() uses floating point math
[ https://issues.apache.org/jira/browse/STDCXX-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov resolved STDCXX-226. -- Resolution: Fixed Resolved thus: http://svn.apache.org/viewvc?rev=605548&view=rev > __rw::__rw_new_capacity() uses floating point math > -- > > Key: STDCXX-226 > URL: https://issues.apache.org/jira/browse/STDCXX-226 > Project: C++ Standard Library > Issue Type: Improvement > Components: 23. Containers >Affects Versions: 4.1.2, 4.1.3, 4.2.0 > Environment: all >Reporter: Martin Sebor >Assignee: Farid Zaripov > Fix For: 4.2.1 > > Attachments: benchmark-stdcxx-226.c, new_capacity.patch > > > Moved from the Rogue Wave bug tracking database: > Created By: sebor @ May 09, 2002 11:15:41 AM > The template __rw_new_capacity() uses floating point arithmetic which may be > less efficient than integer arithmetic on some architectures. Need to change > to integer arithmetic and correctly handle integer overflow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-226) __rw::__rw_new_capacity() uses floating point math
[ https://issues.apache.org/jira/browse/STDCXX-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553368 ] Farid Zaripov commented on STDCXX-226: -- In the committed patch the _RWSTD_NEW_CAPACITY_RATIO and _RWSTD_STRING_CAPACITY_RATIO floating point values replaced to integer (multiplied with _RWSTD_RATIO_DIVIDER == 1000). > __rw::__rw_new_capacity() uses floating point math > -- > > Key: STDCXX-226 > URL: https://issues.apache.org/jira/browse/STDCXX-226 > Project: C++ Standard Library > Issue Type: Improvement > Components: 23. Containers >Affects Versions: 4.1.2, 4.1.3, 4.2.0 > Environment: all >Reporter: Martin Sebor >Assignee: Farid Zaripov > Fix For: 4.2.1 > > Attachments: benchmark-stdcxx-226.c, new_capacity.patch > > > Moved from the Rogue Wave bug tracking database: > Created By: sebor @ May 09, 2002 11:15:41 AM > The template __rw_new_capacity() uses floating point arithmetic which may be > less efficient than integer arithmetic on some architectures. Need to change > to integer arithmetic and correctly handle integer overflow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-585) [gcc 4.2.0/Cygwin] linker errors due to multiple definition of `std::bad_cast::what()'; `std::bad_typeid::what()'; `std::bad_exception::what()'; `std::bad_alloc::what()'
[ https://issues.apache.org/jira/browse/STDCXX-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov resolved STDCXX-585. -- Resolution: Fixed > [gcc 4.2.0/Cygwin] linker errors due to multiple definition of > `std::bad_cast::what()'; `std::bad_typeid::what()'; > `std::bad_exception::what()'; `std::bad_alloc::what()' > - > > Key: STDCXX-585 > URL: https://issues.apache.org/jira/browse/STDCXX-585 > Project: C++ Standard Library > Issue Type: Bug > Components: Configuration >Affects Versions: 4.2.0 > Environment: gcc 4.2.0 / Cygwin > Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Blocker > Fix For: 4.2.1 > > Attachments: BAD_ALLOC_ASSIGNMENT.cpp.diff > > > When building the stdcxx on Cygwin I get errors like: > make: Entering directory `/usr/src/stdcxx/trunk/build/examples' > gcc -c -I/usr/src/stdcxx/trunk/include/ansi -D_RWSTDDEBUG -D_REENTRANT > -mthreads -I/usr/src/stdcxx/trunk/include > -I/usr/src/stdcxx/trunk/build/include > -I/usr/src/stdcxx/trunk/examples/include -pedantic -nostdinc++ -g -W -Wall > -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align > /usr/src/stdcxx/trunk/examples/manual/accumulate.cpp > gcc accumulate.o -o accumulate -mthreads -L/usr/src/stdcxx/trunk/build/lib > -lstd15s -lsupc++ -lcatgets -liconv -lm > /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(tinfo.o): In > function > `_ZNK10__cxxabiv121__vmi_class_type_info12__do_dyncastEiNS_17__class_type_info10__sub_kindEPKS1_PKvS4_S6_RNS1_16__dyncast_resultE': > /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/tinfo.cc:418: > multiple definition of `std::bad_cast::what() const' > /usr/src/stdcxx/trunk/build/lib/libstd15s.a(typeinfo.o):/usr/src/stdcxx/trunk/src/typeinfo.cpp:349: > first defined here > /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(tinfo.o): In > function > `_ZNK10__cxxabiv121__vmi_class_type_info12__do_dyncastEiNS_17__class_type_info10__sub_kindEPKS1_PKvS4_S6_RNS1_16__dyncast_resultE': > /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/tinfo.cc:418: > multiple definition of `std::bad_typeid::what() const' > /usr/src/stdcxx/trunk/build/lib/libstd15s.a(typeinfo.o):/usr/src/stdcxx/trunk/src/typeinfo.cpp:414: > first defined here > /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(new_handler.o): > In function `_ZNSt9bad_allocD2Ev': > /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/new_handler.cc:48: > multiple definition of `std::bad_alloc::what() const' > /usr/src/stdcxx/trunk/build/lib/libstd15s.a(memory.o):/usr/src/stdcxx/trunk/src/memory.cpp:331: > first defined here > /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(eh_exception.o): > In function `_ZNSt13bad_exceptionD2Ev': > /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/eh_exception.cc:38: > multiple definition of `std::bad_exception::what() const' > /usr/src/stdcxx/trunk/build/lib/libstd15s.a(exception.o):/usr/src/stdcxx/trunk/src/exception.cpp:412: > first defined here > collect2: ld returned 1 exit status > make: *** [accumulate] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-459) time_get::date_order() should return actually date order taken from locale
[ https://issues.apache.org/jira/browse/STDCXX-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-459: - Fix Version/s: (was: 4.2.1) 4.3 Scheduled for 4.3. > time_get::date_order() should return actually date order taken from locale > -- > > Key: STDCXX-459 > URL: https://issues.apache.org/jira/browse/STDCXX-459 > Project: C++ Standard Library > Issue Type: Improvement > Components: 22. Localization >Affects Versions: 4.1.2, 4.1.3, 4.1.4 > Environment: All > Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Minor > Fix For: 4.3 > > Attachments: stdcxx-459.patch > > > The current implementation of the time_get::date_order() always returns > no_order. It should return date order used by a locale facet > (http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03734.html). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-459) time_get::date_order() should return actually date order taken from locale
[ https://issues.apache.org/jira/browse/STDCXX-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552871 ] Farid Zaripov commented on STDCXX-459: -- 1. This change is not necessary (and even more, it's incorrect, because __rw_get_timepunct() should be exported if the user instantiates the std::time_get). 2. The __rw_get_dateorder() should also be _RWSTD_EXPORT to be accessible from std::time_get. And this change is not a forward binary compatible. 3. I think yes. The outlining doesn't add's the new symbol in the library. The only what may change - it's a return value from the date_order(). But since the all possible returning values are valid (the user of the library shouldn't rely on the always returned no_order from date_order()) this change is safe. > time_get::date_order() should return actually date order taken from locale > -- > > Key: STDCXX-459 > URL: https://issues.apache.org/jira/browse/STDCXX-459 > Project: C++ Standard Library > Issue Type: Improvement > Components: 22. Localization >Affects Versions: 4.1.2, 4.1.3, 4.1.4 > Environment: All > Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Minor > Fix For: 4.2.1 > > Attachments: stdcxx-459.patch > > > The current implementation of the time_get::date_order() always returns > no_order. It should return date order used by a locale facet > (http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03734.html). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-675) [MSVC] implement autolinking feature
[ https://issues.apache.org/jira/browse/STDCXX-675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552841 ] Farid Zaripov commented on STDCXX-675: -- Yes. This change doesn't affect the exported symbols or anything else. It's only add's the record in object files, compiled with using this change, to link these object files with libstdxx.lib. > [MSVC] implement autolinking feature > > > Key: STDCXX-675 > URL: https://issues.apache.org/jira/browse/STDCXX-675 > Project: C++ Standard Library > Issue Type: Improvement > Components: Configuration >Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0 > Environment: MSVC, ICC/Windows > Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Trivial > Fix For: 4.2.1 > > Attachments: autolink.patch > > > At the moment the users of the library should explicitly specify the used > library name in linker command line. Here might be problems if the user's > project was compiled with config.h for some configuration (let's say 12d) but > linked with library for another configuration (i.e. libstd12s.lib). > The MSVC and ICC/Windows has the posibility to specify the library using > #pragma comment (lib, libname) directive. So #including any header from the > library will leads to linking automatically with the proper library file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-226) __rw::__rw_new_capacity() uses floating point math
[ https://issues.apache.org/jira/browse/STDCXX-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551505 ] Farid Zaripov commented on STDCXX-226: -- In my patch _RWSTD_NEW_CAPACITY_RATIO still double, and it's converted to an integer in __rw_new_capacity: --- const _RWSizeT __ratio = _RWSizeT (_RWSTD_NEW_CAPACITY_RATIO * 1024); --- Since here _RWSTD_NEW_CAPACITY_RATIO and 1024 are constants, the compiler should calculate __ratio in compile time. > __rw::__rw_new_capacity() uses floating point math > -- > > Key: STDCXX-226 > URL: https://issues.apache.org/jira/browse/STDCXX-226 > Project: C++ Standard Library > Issue Type: Improvement > Components: 23. Containers >Affects Versions: 4.1.2, 4.1.3, 4.2.0 > Environment: all >Reporter: Martin Sebor >Assignee: Farid Zaripov > Fix For: 4.2.1 > > Attachments: benchmark-stdcxx-226.c, new_capacity.patch > > > Moved from the Rogue Wave bug tracking database: > Created By: sebor @ May 09, 2002 11:15:41 AM > The template __rw_new_capacity() uses floating point arithmetic which may be > less efficient than integer arithmetic on some architectures. Need to change > to integer arithmetic and correctly handle integer overflow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: mailing list for Jira issues?
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 12, 2007 8:19 PM > To: stdcxx-dev@incubator.apache.org > Subject: Re: mailing list for Jira issues? > > But what the sense to send the response to > [EMAIL PROTECTED] > > and not to [EMAIL PROTECTED] > > I'm not sure what Travis meant by "responses would appear the > same" but I expect [EMAIL PROTECTED] to be a read-only > list akin to [EMAIL PROTECTED] People's comments on > posts sent by Jira to the list will be directed (via > Reply-To) to [EMAIL PROTECTED] > > Does this make sense? Yes. The all discussions on the issues should be either in JIRA comments or in stdcxx-dev mailing list. Farid.
RE: mailing list for Jira issues?
> -Original Message- > From: Travis Vitek [mailto:[EMAIL PROTECTED] > Sent: Monday, December 10, 2007 10:00 PM > To: stdcxx-dev@incubator.apache.org > Subject: RE: mailing list for Jira issues? > > I'm using the MS Outlook and filtering the JIRA messages by the > > "[jira]" > > in subject. But any reply to jira messages with "Re: [jira]" in > > subject are filtered also :( And Outlook dosn't provide the > > possibility to make more flexible rule :( > > > > Farid. > > > > I don't know how the infra group will set this up, but I > wouldn't expect the addition of a new list to fix this > problem for you. All generated messages from jira would come > from the user that modified the case and be sent to the > [EMAIL PROTECTED] list. Any response would appear the > same. This is how it works now. But what the sense to send the response to [EMAIL PROTECTED] and not to [EMAIL PROTECTED] > Also, I believe that Outlook rules allow you to make a rule > handle this situation. You just add an exception to your rule > that checks for the strings "RE:" or "Re:". I forget about the "rule exceptions" and tried to make the rule using the "rule conditions" only. Thanks! :) Farid.
RE: [PATCH] MSVC has non-standard prototype of the wcstok()
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 12, 2007 8:53 AM > To: stdcxx-dev@incubator.apache.org > Subject: Re: [PATCH] MSVC has non-standard prototype of the wcstok() > > Since the configure script performs checking only names > and doesn't > > checking the correct prototype, the _RWSTD_NO_WCSTOK macro is not > > defined in config.h. As a result the 21.cwchar.cpp test asserts on > > "wcstok() not declared". > > But there is a mechanism to check for signatures too, isn't there? > Could we use it to detect this or are you saying even this is > not enough? This mechanism checks the signatures in header files, but incorrect wcstok() will be found in libc. config.h: --- #define _RWSTD_NO_WCSTOK // #define _RWSTD_NO_WCSTOK_IN_LIBC --- Farid.
[jira] Commented: (STDCXX-226) __rw::__rw_new_capacity() uses floating point math
[
https://issues.apache.org/jira/browse/STDCXX-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551006
]
Farid Zaripov commented on STDCXX-226:
--
In my testing the algorithm in My patch is more accurate :)
--
unsigned long f2 (unsigned long x)
{
unsigned long z = (x >> 10) * 1000 + (((x & 0x3ff) * 1000) >> 10);
return z;
}
--
Here instead of "1000" should be "ratio * 1024" == 1,618L * 1024 == 1656.
Also in My algorithm the 1.618 ratio is present explicitly and can be changed
to any other value when it's needed.
> __rw::__rw_new_capacity() uses floating point math
> --
>
> Key: STDCXX-226
> URL: https://issues.apache.org/jira/browse/STDCXX-226
> Project: C++ Standard Library
> Issue Type: Improvement
> Components: 23. Containers
>Affects Versions: 4.1.2, 4.1.3, 4.2.0
> Environment: all
>Reporter: Martin Sebor
>Assignee: Farid Zaripov
> Fix For: 4.2.1
>
> Attachments: benchmark-stdcxx-226.c, new_capacity.patch
>
>
> Moved from the Rogue Wave bug tracking database:
> Created By: sebor @ May 09, 2002 11:15:41 AM
> The template __rw_new_capacity() uses floating point arithmetic which may be
> less efficient than integer arithmetic on some architectures. Need to change
> to integer arithmetic and correctly handle integer overflow.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-226) __rw::__rw_new_capacity() uses floating point math
[ https://issues.apache.org/jira/browse/STDCXX-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-226: - Severity: Inefficiency Patch Info: [Patch Available] Affects Version/s: 4.2.0 Fix Version/s: 4.2.1 > __rw::__rw_new_capacity() uses floating point math > -- > > Key: STDCXX-226 > URL: https://issues.apache.org/jira/browse/STDCXX-226 > Project: C++ Standard Library > Issue Type: Improvement > Components: 23. Containers >Affects Versions: 4.1.2, 4.1.3, 4.2.0 > Environment: all >Reporter: Martin Sebor >Assignee: Farid Zaripov > Fix For: 4.2.1 > > Attachments: new_capacity.patch > > > Moved from the Rogue Wave bug tracking database: > Created By: sebor @ May 09, 2002 11:15:41 AM > The template __rw_new_capacity() uses floating point arithmetic which may be > less efficient than integer arithmetic on some architectures. Need to change > to integer arithmetic and correctly handle integer overflow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: [PATCH] STDCXX-507 (or using __declspec(dllexport/dllimport on gcc/cygwin in shared builds)
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Friday, December 07, 2007 8:56 PM > To: stdcxx-dev@incubator.apache.org > Subject: Re: [PATCH] STDCXX-507 (or using > __declspec(dllexport/dllimport on gcc/cygwin in shared builds) > > Farid Zaripov wrote: > > Today I've verified the patch for STDCXX-507 on gcc 4.2.0 and gcc > > 3.4.4. > > I get really nervous whenever we start to mess around with > the runtime symbols, especially when changing which ones are > exported on Windows and which ones aren't. Doesn't exporting > just members and not the whole class have an impact on things > like RTTI and exceptions? > Have you tested it with the other Windows compilers (Intel > C++ and MSVC)? Yes. The all examples and tests were compiled and runs as usual. > Also, I'm more than a little uncomfortable with hardcoding > __CYGWIN__ all over the place. Isn't there a single file > where we could tweak _RWSTD_NO_XXX_DEFAULT_CTOR et al macros? Ok, we can leave include/exception, include/new and include/typeinfo header files unchanged since in this patch _RWSTD_EXPORT macro is #defined to /*empty*/ if _RWSTD_LIB_SRC macro is not #defined. > Finally, did you consider STDCXX-408 when enabling dllexport? Yes. Unfortunately I haven't access to the HP aCC 3.37 compiler/platform to test how the library builts with the using the dllexport/import directives. The gcc, as I commented in the issue, supports dllexport/dllimport attributes only on Cygwin and Symbian platforms. Farid.
RE: [PATCH] STDCXX-507 (or using __declspec(dllexport/dllimport on gcc/cygwin in shared builds)
> -Original Message- > From: Travis Vitek [mailto:[EMAIL PROTECTED] > Sent: Monday, December 10, 2007 7:25 PM > To: stdcxx-dev@incubator.apache.org > Subject: Re: [PATCH] STDCXX-507 (or using > __declspec(dllexport/dllimport on gcc/cygwin in shared builds) > > >> It seems that the problem is that the Cygwin environment > defines part > >> of the > >> C++ runtime library in the C library. > > > > It does? I don't see any such symbols in the localedef.imports file > > attached to STDCXX-507 (although there are a lot symbols there so I > > could have easily missed them). > > > > Maybe I'm totally off base, but it appears that Farid is > trying to avoid exporting set_unexpected, unexpected, > set_terminate, terminate, uncaught_exception and the > exception types. Aren't all of these things from the support > library? These functions and also dtor() and what() members of the std::exception, std::bad_exception, std::bad_alloc, std::bad_cast, std::bad_typeid are defined in libsupc++.a. > Why would it help us to not export them? The using of the __declspec(dllimport) in declarations in client code appends the __imp__ prefix to the referenced symbol. I.e. for the set_terminate() function the referenced symbol name would be __imp__set_terminate (I'm not including the name mangling just for example). So the user will get a "undefined reference" linker errors. The MSVC doesn't have this problem because the we're using the shared libc in our shared library builds, so the symbol in MSVC libc will be also with __imp__ prefix. But libsupc++ library is present only as static library. But now I see that we can leave the inlude/exception, include/new and include/typeinfo header files unchanged because the gcc/cygwin supports auto-importing feature (it's first searching "xxx" symbol name, then if the symbol is not found the "__imp__xxx" symbol will be searched). We just should define _RWSTD_EXPORT as /*empty*/ if the _RWSTD_LIB_SRC macro is not #defined. Farid.
RE: mailing list for Jira issues?
> -Original Message- > From: Travis Vitek [mailto:[EMAIL PROTECTED] > Sent: Monday, December 10, 2007 7:53 PM > To: stdcxx-dev@incubator.apache.org > Subject: Re: mailing list for Jira issues? > > How does everyone feel about it? > > > > https://issues.apache.org/jira/browse/STDCXX-546 > > > > I have no objections. Either way, I need to look at both sets > of messages regardless of where they come from. So, for me, > moving the Jira messages to a new -issues list doesn't have > any significant impact. > > I guess it might be useful for users with 'dumb' e-mail > clients that don't have proper message filtering. My +1 for the change. I'm using the MS Outlook and filtering the JIRA messages by the "[jira]" in subject. But any reply to jira messages with "Re: [jira]" in subject are filtered also :( And Outlook dosn't provide the possibility to make more flexible rule :( Farid.
RE: [PING] Re: library and build sizes on Windows
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED]
> Sent: Monday, December 10, 2007 9:30 AM
> To: stdcxx-dev@incubator.apache.org
> Subject: RE: [PING] Re: library and build sizes on Windows
>
>
> I've been doing some work on the test result scripts over the
> weekend and noticed a whole bunch of places where we print
> out the date on Windows (I counted 12). I dealt with it by
> trimming all but the first one from the log when processing
> it but we should probably get rid of all the extra dates and
> either replace them with the same output as on UNIX if
> possible (i.e., real, user, ans system times) or just the
> real time. Can this be done on Windows?
I've added printing the real time of the every build step:
http://svn.apache.org/viewvc?rev=602995&view=rev
But batman script also should to be updated to print the timestamp
of the build at the beginning ("### date:"); the duration of the
solution generating step ("### real time (builddir):") after execution
of the configure.bat and total time at the end after cleanup
("### real time (total):"). All these actions are performed outside
the build.wsf script.
As for the kernel and user time spent to the each step: it's hard to
implement because we need to summarize the all times of the each
subprocess. The GetProcessTimes() returns the times only for concrete
process and not returning the times of the children processes, like does
times() on unix.
Farid.
[jira] Commented: (STDCXX-408) make use of __declspec(dll{export,import}) on all platforms
[
https://issues.apache.org/jira/browse/STDCXX-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549772
]
Farid Zaripov commented on STDCXX-408:
--
The gcc implements dllexport/dllimport attributes only on Windows and Symbian
target platforms (i.e. Cygwin)..
> make use of __declspec(dll{export,import}) on all platforms
> ---
>
> Key: STDCXX-408
> URL: https://issues.apache.org/jira/browse/STDCXX-408
> Project: C++ Standard Library
> Issue Type: Improvement
> Components: Build
>Affects Versions: 4.1.3
> Environment: HP aCC 3.37 and beyond, gcc/Linux
>Reporter: Martin Sebor
> Fix For: 4.2.1
>
>
> Starting with HP aCC 3.37 the compiler supports the __declspec(dllexport) and
> __declspec(dllimport) decorators on declarations of symbols with external
> linkage. According to the Release Notes for the compiler, "Support of these
> keywords enhances the performance of shared libraries and relieves the usage
> of HP_DEFINED_EXTERNAL pragmas and +Oextern= list to hide the non-exported
> symbols." See http://docs.hp.com/en/2212/A-03-37relnotes.html.
> We should enable this in our builds.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[PATCH] STDCXX-507 (or using __declspec(dllexport/dllimport on gcc/cygwin in shared builds)
Today I've verified the patch for STDCXX-507 on gcc 4.2.0 and gcc 3.4.4. The patch is here: https://issues.apache.org/jira/secure/attachment/12371246/cygwin.patch ChangeLog: STDCXX-507 * include/rw/_defs.h [__CYGWIN__ && _RWSHARED]: #define _RWSTD_EXPORT macro using __declspec (dllexport) directiive. * include/typeinfo (bad_cast): Don't declare class as _RWSTD_EXPORT. Declare as _RWSTD_EXPORT the only members, that doesn't already present in libc. (bad_typeid): Ditto. * include/exception (exception): Ditto. (bad_exception): Ditto. (set_unexpected): Ditto. (unexpected): Ditto. (set_terminate): Ditto. (terminate): Ditto. (uncaught_exception): Ditto. * include/new (bad_alloc): Ditto. * etc/config/gcc.config [CYGWIN] (SHARED_CPPFLAGS): #define _RWSHARED for shared builds. (LDSOFLAGS): turn on exporting of the all symbols (this feature is disabled by default due to using __declspec(dllexport)). (LDFLAGS): Force ".exe" executable files extension. Without using of the -export-all-symbols linker option the some examples and tests are failed to link due to "undefined reference to the [typeinfo for ...]". Where ... is std::istream, std::ostream, std::wistream, std::wostream, ... I don't know why these typeinfo's are not exported and how to explicitly export them. Also the __rw_atomic_addxx() and __rw_atomic_xcghxx() functions are not exported because they are defined in assembly file (the gcc and ld doesn't have the feature like #pragma comment (linker, "/EXPORT=...") in MSVC). So the -export-all-symbols option is needed to deal with "undefined reference" errors. The -force-exe-suffix option is not related to the issue. It's just forces, that all executable names will end's with ".exe". Farid.
[jira] Updated: (STDCXX-507) [Cygwin] Access violation while loading libstdxxx.dll in dynamic builds
[ https://issues.apache.org/jira/browse/STDCXX-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-507: - Patch Info: [Patch Available] > [Cygwin] Access violation while loading libstdxxx.dll in dynamic builds > --- > > Key: STDCXX-507 > URL: https://issues.apache.org/jira/browse/STDCXX-507 > Project: C++ Standard Library > Issue Type: Bug > Components: Build >Affects Versions: 4.2.0 > Environment: gcc 3.4.4/Cygwin > Reporter: Farid Zaripov >Assignee: Farid Zaripov > Fix For: 4.2.1 > > Attachments: cygwin.patch, localedef.imports > > > Many utilities, examples and tests failed to start due to access violation > while loading libstdxxx.dll. In night builds logs they all finished with > status 5. The reason is access violation while loading libstdxxx.dll. All of > them has many times duplicated imports (see the attached file) and I suppose > that bug in ld utility. > > $ ./localedef || echo $? > 5 > $ strace /usr/src/stdcxx/trunk/build15d/bin/localedef > --- Process 732, exception C005 at 7C919994 > --- Process 732, exception C005 at 7C964ED1 > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-507) [Cygwin] Access violation while loading libstdxxx.dll in dynamic builds
[ https://issues.apache.org/jira/browse/STDCXX-507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549499 ] Farid Zaripov commented on STDCXX-507: -- After the patch the examples and tests are built successfully. But there left some problems when running (exit code == 128): The failed examples: NAME STATUS WARN ASSERTS FAILED PERCNTUSER SYSREAL alg1 1280 0.000 0.015 0.123 complex 1280 0.015 0.015 0.445 complx1280 0.000 0.015 0.126 filebuf 1280 0.000 0.015 0.073 fstream 1280 0.000 0.015 0.089 ifstream 1280 0.000 0.015 0.087 insert_wchar 1280 0.000 0.015 0.077 istream1 1280 0.000 0.000 0.071 istreambuf_iterator 1280 0.000 0.015 0.084 istringstream 1280 0.000 0.015 0.075 istrstream1280 0.000 0.046 0.077 money_get 1280 0.000 0.015 0.061 multiset 1280 0.000 0.046 0.143 num_get 1280 0.000 0.031 0.068 num_put 1280 0.000 0.015 0.122 ostream 1280 0.000 0.015 0.111 setex 1280 0.000 0.046 0.135 spell 1280 0.000 0.015 0.109 stringbuf 1280 0.015 0.046 0.070 strstream 1280 0.015 0.015 0.108 strstreambuf 1280 0.015 0.031 0.079 time_get 1280 0.000 0.015 0.088 time_put 1280 0.000 0.015 0.277 wostream 1280 0.000 0.015 0.106 wstringstream 1280 0.000 0.015 0.090 The failed tests: NAME STATUS WARN ASSERTS FAILED PERCNTUSER SYSREAL 21.string.io 1280 0.000 0.015 0.134 21.string.io.stdcxx-206 1280 0.000 0.000 0.091 22.locale.globals.mt 1280 0.000 0.015 0.090 22.locale.messages1280 0.000 0.015 0.101 22.locale.money.get.mt1280 0.000 0.015 0.104 22.locale.money.get 1280 0.000 0.062 0.102 22.locale.money.put.mt1280 0.000 0.015 0.100 22.locale.money.put 1280 0.000 0.015 0.127 22.locale.moneypunct 1280 0.000 0.031 0.107 22.locale.num.get.mt 1280 0.000 0.015 0.107 22.locale.num.get 1280 0.000 0.015 0.115 22.locale.num.put.mt 1280 0.000 0.031 0.101 22.locale.num.put 1280 0.015 0.031 0.133 22.locale.time.get.mt 1280 0.000 0.015 0.102 22.locale.time.get1280 0.000 0.015 0.104 22.locale.time.put.mt 1280 0.000 0.000 0.127 22.locale.time.put1280 0.000 0.031 0.103 27.filebuf.codecvt1280 0.000 0.031 0.087 27.filebuf.virtuals.stdcxx-5221280 0.000 0.015 0.089 27.istream.fmat.arith 1280 0.000 0.015 0.097 27.istream.manip 1280 0.000 0.015 0.109 27.istream.readsome 1280 0.000 0.015 0.098 27.istream.sentry 1280 0.000 0.015 0.099 27.ostream1280 0.000 0.015 0.105 27
[jira] Commented: (STDCXX-507) [Cygwin] Access violation while loading libstdxxx.dll in dynamic builds
[ https://issues.apache.org/jira/browse/STDCXX-507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549496 ] Farid Zaripov commented on STDCXX-507: -- ChangeLog: STDCXX-507 * include/rw/_defs.h [__CYGWIN__ && _RWSHARED]: #define _RWSTD_EXPORT macro using __declspec (dllexport) directiive. * include/typeinfo (bad_cast): Don't declare class as _RWSTD_EXPORT. Declare as _RWSTD_EXPORT the only members, that doesn't already present in libc. (bad_typeid): Ditto. * include/exception (exception): Ditto. (bad_exception): Ditto. (set_unexpected): Ditto. (unexpected): Ditto. (set_terminate): Ditto. (terminate): Ditto. (uncaught_exception): Ditto. * include/new (bad_alloc): Ditto. * etc/config/gcc.config [CYGWIN] (SHARED_CPPFLAGS): #define _RWSHARED for shared builds. (LDSOFLAGS): turn on exporting of the all symbols (this feature is disabled by default due to using __declspec(dllexport)). (LDFLAGS): Force ".exe" executable files extension. > [Cygwin] Access violation while loading libstdxxx.dll in dynamic builds > --- > > Key: STDCXX-507 > URL: https://issues.apache.org/jira/browse/STDCXX-507 > Project: C++ Standard Library > Issue Type: Bug > Components: Build >Affects Versions: 4.2.0 > Environment: gcc 3.4.4/Cygwin > Reporter: Farid Zaripov >Assignee: Farid Zaripov > Fix For: 4.2.1 > > Attachments: cygwin.patch, localedef.imports > > > Many utilities, examples and tests failed to start due to access violation > while loading libstdxxx.dll. In night builds logs they all finished with > status 5. The reason is access violation while loading libstdxxx.dll. All of > them has many times duplicated imports (see the attached file) and I suppose > that bug in ld utility. > > $ ./localedef || echo $? > 5 > $ strace /usr/src/stdcxx/trunk/build15d/bin/localedef > --- Process 732, exception C005 at 7C919994 > --- Process 732, exception C005 at 7C964ED1 > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-507) [Cygwin] Access violation while loading libstdxxx.dll in dynamic builds
[ https://issues.apache.org/jira/browse/STDCXX-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-507: - Attachment: cygwin.patch The patch is attached. > [Cygwin] Access violation while loading libstdxxx.dll in dynamic builds > --- > > Key: STDCXX-507 > URL: https://issues.apache.org/jira/browse/STDCXX-507 > Project: C++ Standard Library > Issue Type: Bug > Components: Build >Affects Versions: 4.2.0 > Environment: gcc 3.4.4/Cygwin > Reporter: Farid Zaripov >Assignee: Farid Zaripov > Fix For: 4.2.1 > > Attachments: cygwin.patch, localedef.imports > > > Many utilities, examples and tests failed to start due to access violation > while loading libstdxxx.dll. In night builds logs they all finished with > status 5. The reason is access violation while loading libstdxxx.dll. All of > them has many times duplicated imports (see the attached file) and I suppose > that bug in ld utility. > > $ ./localedef || echo $? > 5 > $ strace /usr/src/stdcxx/trunk/build15d/bin/localedef > --- Process 732, exception C005 at 7C919994 > --- Process 732, exception C005 at 7C964ED1 > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-507) [Cygwin] Access violation while loading libstdxxx.dll in dynamic builds
[ https://issues.apache.org/jira/browse/STDCXX-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-507: - Attachment: (was: cygwin.patch) > [Cygwin] Access violation while loading libstdxxx.dll in dynamic builds > --- > > Key: STDCXX-507 > URL: https://issues.apache.org/jira/browse/STDCXX-507 > Project: C++ Standard Library > Issue Type: Bug > Components: Build >Affects Versions: 4.2.0 > Environment: gcc 3.4.4/Cygwin > Reporter: Farid Zaripov >Assignee: Farid Zaripov > Fix For: 4.2.1 > > Attachments: cygwin.patch, localedef.imports > > > Many utilities, examples and tests failed to start due to access violation > while loading libstdxxx.dll. In night builds logs they all finished with > status 5. The reason is access violation while loading libstdxxx.dll. All of > them has many times duplicated imports (see the attached file) and I suppose > that bug in ld utility. > > $ ./localedef || echo $? > 5 > $ strace /usr/src/stdcxx/trunk/build15d/bin/localedef > --- Process 732, exception C005 at 7C919994 > --- Process 732, exception C005 at 7C964ED1 > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-507) [Cygwin] Access violation while loading libstdxxx.dll in dynamic builds
[ https://issues.apache.org/jira/browse/STDCXX-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-507: - Attachment: cygwin.patch > [Cygwin] Access violation while loading libstdxxx.dll in dynamic builds > --- > > Key: STDCXX-507 > URL: https://issues.apache.org/jira/browse/STDCXX-507 > Project: C++ Standard Library > Issue Type: Bug > Components: Build >Affects Versions: 4.2.0 > Environment: gcc 3.4.4/Cygwin > Reporter: Farid Zaripov >Assignee: Farid Zaripov > Fix For: 4.2.1 > > Attachments: cygwin.patch, localedef.imports > > > Many utilities, examples and tests failed to start due to access violation > while loading libstdxxx.dll. In night builds logs they all finished with > status 5. The reason is access violation while loading libstdxxx.dll. All of > them has many times duplicated imports (see the attached file) and I suppose > that bug in ld utility. > > $ ./localedef || echo $? > 5 > $ strace /usr/src/stdcxx/trunk/build15d/bin/localedef > --- Process 732, exception C005 at 7C919994 > --- Process 732, exception C005 at 7C964ED1 > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-666) [MSVC 8-x64] 21.string.cons.cpp test fails in optimized builds due to bad codegeneration by the compiler
[
https://issues.apache.org/jira/browse/STDCXX-666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov reassigned STDCXX-666:
Assignee: Farid Zaripov
> [MSVC 8-x64] 21.string.cons.cpp test fails in optimized builds due to bad
> codegeneration by the compiler
>
>
> Key: STDCXX-666
> URL: https://issues.apache.org/jira/browse/STDCXX-666
> Project: C++ Standard Library
> Issue Type: Bug
> Components: Tests
>Affects Versions: 4.2.0
> Environment: MSVC 8.0-x64, builds 8{d|s}, 12{d|s}
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
> Fix For: 4.2.1
>
>
> The 21.string.cons.cpp test fails with 16 assertions on 64-bit MSVC in
> optimized builds.
> The reason is the bad codegeneration in __rw_new_capacity() inlined in
> std::basic_string ctors. Because of this bug the __rw_new_capacity(0, const
> std::basic_string<> *) returns value greater that size_max() and ctor throws
> exception.
> The temporary workaround might be definition of the __rw_new_capacity() as
> __declspec (noinline).
> --
> Index: include/string
> ===
> --- include/string(revision 593511)
> +++ include/string(working copy)
> @@ -1528,8 +1528,13 @@
> // more specialized version for basic_string<>; may be further specialized
> // in user code for example on a user-defined allocator
>
> +#if !defined (_WIN64) || !defined (_MSC_VER) || defined
> (__INTEL_COMPILER)
> template inline
> _RWSTD_STRING_SIZE_TYPE
> +#else// _WIN64 && _MSC_VER && !__INTEL_COMPILER
> +template __declspec
> +(noinline) _RWSTD_STRING_SIZE_TYPE
> +#endif // !_WIN64 || !_MSC_VER || __INTEL_COMPILER
> __rw_new_capacity (_RWSTD_STRING_SIZE_TYPE __size,
> const _STD::basic_string<_CharT, _Traits,
> _Allocator>*)
> {
> --
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-663) [MSVC] MSVC declares non-standard prototype of the wcstok()
[ https://issues.apache.org/jira/browse/STDCXX-663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov closed STDCXX-663. > [MSVC] MSVC declares non-standard prototype of the wcstok() > --- > > Key: STDCXX-663 > URL: https://issues.apache.org/jira/browse/STDCXX-663 > Project: C++ Standard Library > Issue Type: Bug > Components: External > Environment: MSVC, ICC/Windows > Reporter: Farid Zaripov > Assignee: Farid Zaripov >Priority: Minor > Fix For: 4.2.1 > > Attachments: wcstok.patch > > > The MSVC declares non-standard prototype of the wcstok(): > wchar.h: > --- > _CRTIMP wchar_t * __cdecl wcstok(wchar_t *, const wchar_t *); > --- > Since configuration script doesn't check the correct prototype and checks > only for name, the config.h file contains _RWSTD_NO_WCSTOK macro undefined. > The MSVC 8 and higher declares wcstok_s() which is identical to standard > wcstok(): > wchar.h: > --- > _CRTIMP_ALTERNATIVE __checkReturn wchar_t * __cdecl wcstok_s(__inout_z_opt > wchar_t * _Str, __in_z const wchar_t * _Delim, __deref_inout_z_opt wchar_t ** > _Context); > --- > I think we need to #define _RWSTD_NO_WCSTOK macro in > include/rw/_config_msvcrt.h and add inline wcstok() invoking wcstok_s() in > include /ansi/cwchar. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-663) [MSVC] MSVC declares non-standard prototype of the wcstok()
[ https://issues.apache.org/jira/browse/STDCXX-663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov resolved STDCXX-663. -- Resolution: Fixed Fixed thus: http://svn.apache.org/viewvc?view=rev&revision=597411 Merged in thunk thus: http://svn.apache.org/viewvc?view=rev&revision=597412 > [MSVC] MSVC declares non-standard prototype of the wcstok() > --- > > Key: STDCXX-663 > URL: https://issues.apache.org/jira/browse/STDCXX-663 > Project: C++ Standard Library > Issue Type: Bug > Components: External > Environment: MSVC, ICC/Windows >Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Minor > Fix For: 4.2.1 > > Attachments: wcstok.patch > > > The MSVC declares non-standard prototype of the wcstok(): > wchar.h: > --- > _CRTIMP wchar_t * __cdecl wcstok(wchar_t *, const wchar_t *); > --- > Since configuration script doesn't check the correct prototype and checks > only for name, the config.h file contains _RWSTD_NO_WCSTOK macro undefined. > The MSVC 8 and higher declares wcstok_s() which is identical to standard > wcstok(): > wchar.h: > --- > _CRTIMP_ALTERNATIVE __checkReturn wchar_t * __cdecl wcstok_s(__inout_z_opt > wchar_t * _Str, __in_z const wchar_t * _Delim, __deref_inout_z_opt wchar_t ** > _Context); > --- > I think we need to #define _RWSTD_NO_WCSTOK macro in > include/rw/_config_msvcrt.h and add inline wcstok() invoking wcstok_s() in > include /ansi/cwchar. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: _RWSTD_LIB_SRC macro is not #defined in src/export.cpp
From: Martin Sebor [mailto:[EMAIL PROTECTED] To: stdcxx-dev@incubator.apache.org Subject: Re: _RWSTD_LIB_SRC macro is not #defined in src/export.cpp > The _RWSTD_INSTANTIATE_TEMPLATES part is an implementation detail > of _RWSTD_LIB_SRC. If we were to add another detail like that we'd > have to also remember to update export.cpp. That seems just as > brittle as what we're doing now (i.e., not #defining _RWSTD_LIB_SRC). > > The #define _RWSTD_LIB_SRC in every library src file is needed > for the implementing the autolinking feature on MSVC. > I see. You're adding a #pragma comment to _config.h that expands > when _RWSTD_LIB_SRC is #defined and you need it to expand in all > library sources, correct? No. The #pragma comment directive should be expanded only in user's source files (actually it's enough to expand this directive in only one source file of the user's project, but we can't handle this). At the same time #pragma comment shouldn't expanded in library source files, elsewere the linker will search libstdxx.lib while linking the library itself and will fail with the error "libstdxx.lib not found". The negative effect of the using autolinking feature is the case when user uses the some part of the library, that fully implemented in header files and the user don't have to link its project with stdcxx library, but #pragma comment will force the linker to search and use the specified library. For that case there handled _RWSTD_NO_EXT_AUTOLINK macro. Farid.
Re: _RWSTD_LIB_SRC macro is not #defined in src/export.cpp
From: Martin Sebor [mailto:[EMAIL PROTECTED] To: stdcxx-dev@incubator.apache.org Subject: Re: _RWSTD_LIB_SRC macro is not #defined in src/export.cpp Farid Zaripov wrote: >> I've found that _RWSTD_LIB_SRC macro is not #defined in src/export.cpp >> file. >> >> This is a mistake, or it's required by design? > The file is currently only used when compiling with EDG eccp when > exported templates are enabled. I don't think (but I'm not 100% > sure) we want to #define _RWSTD_LIB_SRC in this case because the > effect is to #define _RWSTD_NO_TEMPLATE_DEFINITIONS. If so, I think it would be more correctly to #define _RWSTD_LIB_SRC and also #define _RWSTD_INSTANTIATE_TEMPLATES. The #define _RWSTD_LIB_SRC in every library src file is needed for the implementing the autolinking feature on MSVC. Farid.
Re: [jira] Resolved: (STDCXX-566) update/generate incubation status file
From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Friday, November 30, 2007 11:30 PM To: stdcxx-dev@incubator.apache.org Subject: RE: [jira] Resolved: (STDCXX-566) update/generate incubation status file >> >> 1. logged into people.apache.org >> 2. svn co http://svn.apache.org/repos/asf/incubator/public/trunk >> incubator >> 3. cd incubator >> 4. updated ./site-author/projects/stdcxx.xml file >> 5. invoked "ant" (script has updated >> ./site-publish/projects/stdcxx.html file) >> 6. commited ./site-author/projects/stdcxx.xml file >> 7. commited ./site-publish/projects/stdcxx.html file >> 8. cd /www/incubator.apache.org >> 9. svn up > This isn't working for me. I updated site-author/projects/stdcxx.xml (and > removed Bloomberg as Lance's affiliation) and checked it in. You shouldn't check it in here. Checking in this is step 6) ;-) > Then I ran the > build.sh script (there is no "ant" as you said in (5)) as shown below but > the site-publish/projects/stdcxx.html file has not been updated. svn status > shows no differences to any files at all. Any idea what I'm doing wrong? Yes. It seems that ant has been uninstalled on people.apache.org since I've made the last site update. I've just tried to remove incubator/site-publish/projects/stdcxx.html. After that build.sh script updated the page: - [EMAIL PROTECTED] ~/incubator]$ rm site-publish/projects/stdcxx.html [EMAIL PROTECTED] ~/incubator]$ ./build.sh Buildfile: build.xml prepare: prepare-error: docs: [anakia] Transforming into: /x1/home/faridz/incubator/site-publish [anakia] Input: projects/stdcxx.xml [anakia] Output: /x1/home/faridz/incubator/site-publish/projects/stdcxx.html BUILD SUCCESSFUL Total time: 2 seconds - I've commited the changes thus: http://svn.apache.org/viewvc?view=rev&revision=55 Farid.
[jira] Updated: (STDCXX-675) [MSVC] implement autolinking feature
[ https://issues.apache.org/jira/browse/STDCXX-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-675: - Patch Info: [Patch Available] > [MSVC] implement autolinking feature > > > Key: STDCXX-675 > URL: https://issues.apache.org/jira/browse/STDCXX-675 > Project: C++ Standard Library > Issue Type: Improvement > Components: Configuration >Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0 > Environment: MSVC, ICC/Windows > Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Trivial > Fix For: 4.2.1 > > Attachments: autolink.patch > > > At the moment the users of the library should explicitly specify the used > library name in linker command line. Here might be problems if the user's > project was compiled with config.h for some configuration (let's say 12d) but > linked with library for another configuration (i.e. libstd12s.lib). > The MSVC and ICC/Windows has the posibility to specify the library using > #pragma comment (lib, libname) directive. So #including any header from the > library will leads to linking automatically with the proper library file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-675) [MSVC] implement autolinking feature
[ https://issues.apache.org/jira/browse/STDCXX-675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547221 ] Farid Zaripov commented on STDCXX-675: -- ChangeLog: STDCXX-675 * include/rw/_autolink.h: New header file to enable autolinking feature. * include/rw/_config-msvcrt.h: #include _autolink.h. * src/export.cpp: Added missing #define _RWSTD_LIB_SRC macro. The _autolink.h file is intended to be #included in _config.h, but since this feature is supported by only MSVC and ICC/Windows, it #included in _config-msvcrt.h. > [MSVC] implement autolinking feature > > > Key: STDCXX-675 > URL: https://issues.apache.org/jira/browse/STDCXX-675 > Project: C++ Standard Library > Issue Type: Improvement > Components: Configuration >Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0 > Environment: MSVC, ICC/Windows > Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Trivial > Fix For: 4.2.1 > > Attachments: autolink.patch > > > At the moment the users of the library should explicitly specify the used > library name in linker command line. Here might be problems if the user's > project was compiled with config.h for some configuration (let's say 12d) but > linked with library for another configuration (i.e. libstd12s.lib). > The MSVC and ICC/Windows has the posibility to specify the library using > #pragma comment (lib, libname) directive. So #including any header from the > library will leads to linking automatically with the proper library file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-675) [MSVC] implement autolinking feature
[ https://issues.apache.org/jira/browse/STDCXX-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-675: - Attachment: autolink.patch > [MSVC] implement autolinking feature > > > Key: STDCXX-675 > URL: https://issues.apache.org/jira/browse/STDCXX-675 > Project: C++ Standard Library > Issue Type: Improvement > Components: Configuration >Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0 > Environment: MSVC, ICC/Windows > Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Trivial > Fix For: 4.2.1 > > Attachments: autolink.patch > > > At the moment the users of the library should explicitly specify the used > library name in linker command line. Here might be problems if the user's > project was compiled with config.h for some configuration (let's say 12d) but > linked with library for another configuration (i.e. libstd12s.lib). > The MSVC and ICC/Windows has the posibility to specify the library using > #pragma comment (lib, libname) directive. So #including any header from the > library will leads to linking automatically with the proper library file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
_RWSTD_LIB_SRC macro is not #defined in src/export.cpp
I've found that _RWSTD_LIB_SRC macro is not #defined in src/export.cpp file. This is a mistake, or it's required by design? Farid.
RE: svn commit: r597425 - in /incubator/stdcxx/branches/4.2.x: include/ansi/cwchar tests/strings/21.cwchar.cpp
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Friday, November 30, 2007 2:51 AM > To: stdcxx-dev@incubator.apache.org > Subject: Re: svn commit: r597425 - in > /incubator/stdcxx/branches/4.2.x: include/ansi/cwchar > tests/strings/21.cwchar.cpp > > > Yes, potentially here might be a problems. > > So maybe we need to rethink the original strategy of > #undefining the macros only when _RWSTD_STRICT_ANSI is > #defined. Or is there a way to prevent the expansion of the > macros in the using declarations? > > Btw., it occurs to me that if they are defined as function > macros (i.e., #define getwc() as opposed to #define getwc, > without the parentheses), mentioning getwc w/o an argument > list as is done in using declarations will not cause them to > be expanded. So the problem only exists for object macros > (i.e., those that aren't defined with parentheses). If the using directives are decorated by #ifndef _RWSTD_NO_funname there would be no problems in case the STDCXX-451 issue resolved. > > BTW in ansi/cctype and ansi/cmath headers the masking macros are > > #undefined unconditionally. > > > > I think first we need to collect information how these macros are > > implemented on different platforms and then decide what > should we do. > > I suppose we should do that. But either way we decide we > should be consistent. So if there already are unconditional > #undefs in several other headers we might as well follow suit > with cwchar (and wchar.h) until we gather more information > and decide to change all the other headers to #undef all the > other macros conditionally. Agreed. So it's safe to #undefine getwc and putwc on MSVC. The gcc on Linux doesn't #define these macros. What about other platforms? Farid.
[jira] Issue Comment Edited: (STDCXX-375) std::getline() declared in , but should be declared in
[
https://issues.apache.org/jira/browse/STDCXX-375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546884
]
farid edited comment on STDCXX-375 at 11/29/07 12:53 PM:
-
I've tried to declare the std::getline() in this testcase.
The following test fails to compile in MSVC with error: error C2027: use of
undefined type 'std::basic_istream<_CharT>' in line 16.
---
#include
#include
namespace std {
template
basic_istream<_CharT, _Traits>&
getline (basic_istream<_CharT, _Traits>&,
basic_string<_CharT, _Traits, _Allocator>&);
}
void test (std::istream& is)
{
std::string str;
std::getline (is, str); /// line 16
}
---
But if I change the test() function to return the is, the test has compiled
without errors.
---
std::istream& test (std::istream& is)
{
std::string str;
return std::getline (is, str);
}
---
was (Author: farid):
I've tried to declare the std::getline() in this testcase.
The following test fails to compile in MSVC with error: error C2027: use of
undefined type 'std::basic_istream<_CharT>' in line 16.
---
#include
#include
namespace std {
template
basic_istream<_CharT, _Traits>&
getline (basic_istream<_CharT, _Traits>&,
basic_string<_CharT, _Traits, _Allocator>&);
}
void test (std::istream& is)
{
std::string str;
std::getline (is, str);
}
---
But if I change the test() function to return the is, the test has compiled
without errors.
---
std::istream& void test (std::istream& is)
{
std::string str;
return std::getline (is, str);
}
---
> std::getline() declared in , but should be declared in
>
>
> Key: STDCXX-375
> URL: https://issues.apache.org/jira/browse/STDCXX-375
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 21. Strings
>Affects Versions: 4.1.3, 4.1.4
> Environment: All
>Reporter: Farid Zaripov
> Fix For: 4.2.1
>
>
> The following code fails to compile with errors:
> test.cpp(7) : error C2039: 'getline' : is not a member of 'std'
> test.cpp(7) : error C3861: 'getline': identifier not found, even with
> argument-dependent lookup
> test.cpp:
> ---
> #include
> #include
> void test (std::istream& is)
> {
> std::string str;
> std::getline (is, str);
> }
> ---
> The addition information here:
> http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200703.mbox/[EMAIL
> PROTECTED]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-375) std::getline() declared in , but should be declared in
[
https://issues.apache.org/jira/browse/STDCXX-375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546884
]
Farid Zaripov commented on STDCXX-375:
--
I've tried to declare the std::getline() in this testcase.
The following test fails to compile in MSVC with error: error C2027: use of
undefined type 'std::basic_istream<_CharT>' in line 16.
---
#include
#include
namespace std {
template
basic_istream<_CharT, _Traits>&
getline (basic_istream<_CharT, _Traits>&,
basic_string<_CharT, _Traits, _Allocator>&);
}
void test (std::istream& is)
{
std::string str;
std::getline (is, str);
}
---
But if I change the test() function to return the is, the test has compiled
without errors.
---
std::istream& void test (std::istream& is)
{
std::string str;
return std::getline (is, str);
}
---
> std::getline() declared in , but should be declared in
>
>
> Key: STDCXX-375
> URL: https://issues.apache.org/jira/browse/STDCXX-375
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 21. Strings
> Affects Versions: 4.1.3, 4.1.4
> Environment: All
>Reporter: Farid Zaripov
> Fix For: 4.2.1
>
>
> The following code fails to compile with errors:
> test.cpp(7) : error C2039: 'getline' : is not a member of 'std'
> test.cpp(7) : error C3861: 'getline': identifier not found, even with
> argument-dependent lookup
> test.cpp:
> ---
> #include
> #include
> void test (std::istream& is)
> {
> std::string str;
> std::getline (is, str);
> }
> ---
> The addition information here:
> http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200703.mbox/[EMAIL
> PROTECTED]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-459) time_get::date_order() should return actually date order taken from locale
[ https://issues.apache.org/jira/browse/STDCXX-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546853 ] Farid Zaripov commented on STDCXX-459: -- ChangeLog: STDCXX-459 * include/loc/_time_get.h (__rw_get_timepunct): Removed unnecessary declaration of the function. (do_date_order): Function outlined and moved from here... * include/loc/_time_get.cc (do_date_order):... to here. Used __rw_get_dateorder() to obtain the dateorder value. (__rw_get_dateorder): Added declaration of the new function. (__rw_get_timepunct): Removed unnecessary _RWSTD_EXPORT attribute. * src/time_get.cpp (__rw_get_dateorder): Added new function to obtain the dateorder value. * src/time_put.cpp (__rw_get_timepunct): Removed unnecessary _RWSTD_EXPORT attribute. > time_get::date_order() should return actually date order taken from locale > -- > > Key: STDCXX-459 > URL: https://issues.apache.org/jira/browse/STDCXX-459 > Project: C++ Standard Library > Issue Type: Improvement > Components: 22. Localization >Affects Versions: 4.1.2, 4.1.3, 4.1.4 > Environment: All > Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Minor > Fix For: 4.2.1 > > Attachments: stdcxx-459.patch > > > The current implementation of the time_get::date_order() always returns > no_order. It should return date order used by a locale facet > (http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03734.html). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-459) time_get::date_order() should return actually date order taken from locale
[ https://issues.apache.org/jira/browse/STDCXX-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-459: - Attachment: (was: stdcxx-459.patch) > time_get::date_order() should return actually date order taken from locale > -- > > Key: STDCXX-459 > URL: https://issues.apache.org/jira/browse/STDCXX-459 > Project: C++ Standard Library > Issue Type: Improvement > Components: 22. Localization >Affects Versions: 4.1.2, 4.1.3, 4.1.4 > Environment: All > Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Minor > Fix For: 4.2.1 > > Attachments: stdcxx-459.patch > > > The current implementation of the time_get::date_order() always returns > no_order. It should return date order used by a locale facet > (http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03734.html). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-459) time_get::date_order() should return actually date order taken from locale
[ https://issues.apache.org/jira/browse/STDCXX-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-459: - Attachment: stdcxx-459.patch The updated patch is attached. > time_get::date_order() should return actually date order taken from locale > -- > > Key: STDCXX-459 > URL: https://issues.apache.org/jira/browse/STDCXX-459 > Project: C++ Standard Library > Issue Type: Improvement > Components: 22. Localization >Affects Versions: 4.1.2, 4.1.3, 4.1.4 > Environment: All > Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Minor > Fix For: 4.2.1 > > Attachments: stdcxx-459.patch, stdcxx-459.patch > > > The current implementation of the time_get::date_order() always returns > no_order. It should return date order used by a locale facet > (http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03734.html). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: [jira] Updated: (STDCXX-459) time_get::date_order() should return actually date order taken from locale
> -Original Message- > From: Travis Vitek [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 29, 2007 7:35 PM > To: stdcxx-dev@incubator.apache.org > Subject: RE: [jira] Updated: (STDCXX-459) > time_get::date_order() should return actually date order > taken from locale > The standard says the following about do_date_order() > > dateorder do_date_order() const; > > 1 Returns: An enumeration value indicating the preferred order > of components for those date formats that are composed of day, > month, and year. 244) Returns no_order if the date format > specified by 'x' contains other variable components (e.g. Julian > day, week number, week day). > > 224) This function is intended as a convenience only, for common >formats, and may return no_order in valid locales. Thank's for the comment. I've forget to look into standard. :( > I think that __rw_get_dateorder() needs to handle unexpected > date format specifiers [such as %j, %U, %V, %w] by returning > no_order. Yes. I think replacing "case '\0':" with "default:" will be enough? > I also think you might also want to handle %h in > there as it is an alias for %b. > > Might there be a compatibility issue here also? If the compiler doesn't optimizes the virtual call of the do_date_order(), the proposed patch, I think, is forward and backward source and binary compatible because the time_get<>::do_date_order() will be defined in the library binary file. There might be a functional incompatibility if the user's code want's the only no_order values, but receive the value other than no_order. Farid.
[jira] Updated: (STDCXX-672) implement C++ 0x Concepts
[ https://issues.apache.org/jira/browse/STDCXX-672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-672: - Description: This is a placeholder to [conditionally] implement C++ 0x Concepts in the library and enable them as compilers start to come online (initially for ConceptGCC: http://www.generic-programming.org/software/ConceptGCC ). Normative info on Concepts can be found here: Proposed Wording for Concepts (Revision 3) http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2421.pdf Concepts for the C++0x Standard Library: Approach http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2036.pdf Concepts for the C++0x Standard Library: Introduction http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2037.pdf Concepts for the C++0x Standard Library: Algorithms http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2040.pdf Concepts for the C++0x Standard Library: Numerics http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2041.pdf Concepts for the C++0x Standard Library: Utilities (Revision 2): http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2322.pdf Concepts for the C++0x Standard Library: Iterators (Revision 2): http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2323.pdf was: This is a placeholder to [conditionally] implement C++ 0x Concepts in the library and enable them as compilers start to come online (initially for ConceptGCC: http://www.generic-programming.org/software/ConceptGCC). Normative info on Concepts can be found here: Proposed Wording for Concepts (Revision 3) http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2421.pdf Concepts for the C++0x Standard Library: Approach http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2036.pdf Concepts for the C++0x Standard Library: Introduction http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2037.pdf Concepts for the C++0x Standard Library: Algorithms http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2040.pdf Concepts for the C++0x Standard Library: Numerics http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2041.pdf Concepts for the C++0x Standard Library: Utilities (Revision 2): http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2322.pdf Concepts for the C++0x Standard Library: Iterators (Revision 2): http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2323.pdf Added space between link and the closing round bracket (otherwise this bracket was appended to the link). > implement C++ 0x Concepts > - > > Key: STDCXX-672 > URL: https://issues.apache.org/jira/browse/STDCXX-672 > Project: C++ Standard Library > Issue Type: New Feature > Components: Configuration >Affects Versions: 4.2.0 >Reporter: Martin Sebor > Fix For: 4.3 > > > This is a placeholder to [conditionally] implement C++ 0x Concepts in the > library and enable them as compilers start to come online (initially for > ConceptGCC: http://www.generic-programming.org/software/ConceptGCC ). > Normative info on Concepts can be found here: > Proposed Wording for Concepts (Revision 3) > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2421.pdf > Concepts for the C++0x Standard Library: Approach > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2036.pdf > Concepts for the C++0x Standard Library: Introduction > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2037.pdf > Concepts for the C++0x Standard Library: Algorithms > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2040.pdf > Concepts for the C++0x Standard Library: Numerics > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2041.pdf > Concepts for the C++0x Standard Library: Utilities (Revision 2): > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2322.pdf > Concepts for the C++0x Standard Library: Iterators (Revision 2): > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2323.pdf -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-675) [MSVC] implement autolinking feature
[MSVC] implement autolinking feature Key: STDCXX-675 URL: https://issues.apache.org/jira/browse/STDCXX-675 Project: C++ Standard Library Issue Type: Improvement Components: Configuration Affects Versions: 4.2.0, 4.1.4, 4.1.3, 4.1.2 Environment: MSVC, ICC/Windows Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Trivial Fix For: 4.2.1 At the moment the users of the library should explicitly specify the used library name in linker command line. Here might be problems if the user's project was compiled with config.h for some configuration (let's say 12d) but linked with library for another configuration (i.e. libstd12s.lib). The MSVC and ICC/Windows has the posibility to specify the library using #pragma comment (lib, libname) directive. So #including any header from the library will leads to linking automatically with the proper library file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-675) [MSVC] implement autolinking feature
[ https://issues.apache.org/jira/browse/STDCXX-675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546826 ] Farid Zaripov commented on STDCXX-675: -- Perhaps the another compilers may has the similar feature. > [MSVC] implement autolinking feature > > > Key: STDCXX-675 > URL: https://issues.apache.org/jira/browse/STDCXX-675 > Project: C++ Standard Library > Issue Type: Improvement > Components: Configuration >Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0 > Environment: MSVC, ICC/Windows > Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Trivial > Fix For: 4.2.1 > > > At the moment the users of the library should explicitly specify the used > library name in linker command line. Here might be problems if the user's > project was compiled with config.h for some configuration (let's say 12d) but > linked with library for another configuration (i.e. libstd12s.lib). > The MSVC and ICC/Windows has the posibility to specify the library using > #pragma comment (lib, libname) directive. So #including any header from the > library will leads to linking automatically with the proper library file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: svn commit: r597425 - in /incubator/stdcxx/branches/4.2.x: include/ansi/cwchar tests/strings/21.cwchar.cpp
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 28, 2007 7:00 PM > To: stdcxx-dev@incubator.apache.org > Subject: Re: svn commit: r597425 - in > /incubator/stdcxx/branches/4.2.x: include/ansi/cwchar > tests/strings/21.cwchar.cpp > > No, I mean when _RWSTD_STRICT_ANSI is not #defined but getwc > and putwc are. Then we might end up with something like this: > >#define getwc() (stdin->__wide_char) >... >using ::getwc; > > expanding to > >using ::(stdin->__wide_char); Yes, potentially here might be a problems. BTW in ansi/cctype and ansi/cmath headers the masking macros are #undefined unconditionally. I think first we need to collect information how these macros are implemented on different platforms and then decide what should we do. In example the MSVC implements getwc() thus fgetwc() (the getwc macro is defined fo fgetwc and getwc() crt function just calls fgetwc()). So we can safely #undefine these macros on MSVC without functional changes or performance penalty (I suppose that in release the getwc() function should be implemented as "jmp _fgetwc"). Farid.
[jira] Commented: (STDCXX-459) time_get::date_order() should return actually date order taken from locale
[ https://issues.apache.org/jira/browse/STDCXX-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546778 ] Farid Zaripov commented on STDCXX-459: -- Another option might be extend the struct __rw_time_t with d_order_off field and determine the dateorder value (or two values for narrow and wide characters) in __rw::__rw_get_timepunct(). > time_get::date_order() should return actually date order taken from locale > -- > > Key: STDCXX-459 > URL: https://issues.apache.org/jira/browse/STDCXX-459 > Project: C++ Standard Library > Issue Type: Improvement > Components: 22. Localization >Affects Versions: 4.1.2, 4.1.3, 4.1.4 > Environment: All > Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Minor > Fix For: 4.2.1 > > Attachments: stdcxx-459.patch > > > The current implementation of the time_get::date_order() always returns > no_order. It should return date order used by a locale facet > (http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03734.html). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-459) time_get::date_order() should return actually date order taken from locale
[ https://issues.apache.org/jira/browse/STDCXX-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-459: - Attachment: stdcxx-459.patch The proposed patch attached. > time_get::date_order() should return actually date order taken from locale > -- > > Key: STDCXX-459 > URL: https://issues.apache.org/jira/browse/STDCXX-459 > Project: C++ Standard Library > Issue Type: Improvement > Components: 22. Localization >Affects Versions: 4.1.2, 4.1.3, 4.1.4 > Environment: All > Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Minor > Fix For: 4.2.1 > > Attachments: stdcxx-459.patch > > > The current implementation of the time_get::date_order() always returns > no_order. It should return date order used by a locale facet > (http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03734.html). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-459) time_get::date_order() should return actually date order taken from locale
[ https://issues.apache.org/jira/browse/STDCXX-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-459: - Patch Info: [Patch Available] > time_get::date_order() should return actually date order taken from locale > -- > > Key: STDCXX-459 > URL: https://issues.apache.org/jira/browse/STDCXX-459 > Project: C++ Standard Library > Issue Type: Improvement > Components: 22. Localization >Affects Versions: 4.1.2, 4.1.3, 4.1.4 > Environment: All > Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Minor > Fix For: 4.2.1 > > Attachments: stdcxx-459.patch > > > The current implementation of the time_get::date_order() always returns > no_order. It should return date order used by a locale facet > (http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03734.html). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-459) time_get::date_order() should return actually date order taken from locale
[ https://issues.apache.org/jira/browse/STDCXX-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov reassigned STDCXX-459: Assignee: Farid Zaripov > time_get::date_order() should return actually date order taken from locale > -- > > Key: STDCXX-459 > URL: https://issues.apache.org/jira/browse/STDCXX-459 > Project: C++ Standard Library > Issue Type: Improvement > Components: 22. Localization >Affects Versions: 4.1.2, 4.1.3, 4.1.4 > Environment: All > Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Minor > Fix For: 4.2.1 > > > The current implementation of the time_get::date_order() always returns > no_order. It should return date order used by a locale facet > (http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03734.html). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-250) std::operator>>(istream&, string&) fails to set failbit after it extracts 0 characters
[
https://issues.apache.org/jira/browse/STDCXX-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546300
]
Farid Zaripov commented on STDCXX-250:
--
Does the term "extracted" means that the gptr() should be shifted by one
position?
> std::operator>>(istream&, string&) fails to set failbit after it extracts 0
> characters
> --
>
> Key: STDCXX-250
> URL: https://issues.apache.org/jira/browse/STDCXX-250
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 27. Input/Output
>Affects Versions: 4.1.2, 4.1.3
> Environment: all
> Reporter: Martin Sebor
>Assignee: Farid Zaripov
>Priority: Minor
> Fix For: 4.2.1
>
> Attachments: istream.cc.diff
>
>
> 21.3.7.9, p3 says about the string extractor: "If the function extracts no
> characters, it calls is.setstate(ios::failbit), which may throw
> ios_base::failure (27.4.4.3)." The test program below shows that in
> unbuffered mode stdcxx fails to do so when an exception is thrown during the
> third call to underflow().
> $ cat v.cpp && make v && ./v
> #include
> #include
> #include
> #include
> int main ()
> {
> struct: std::streambuf {
> int_type underflow () {
> static int i = 0;
> // i == 0: sgect() invoked from sentry ctor
> // i == 1: sgetc() invoked from operator>>()
> // i == 2: sbumpc() invoked from operator>>()
> return 1 < i++ ? throw i : 'x';
> }
> } buf;
> std::istream is (&buf);
> std::string s;
> is >> s;
> std::printf ("state = %c%c%c, string = \"%s\" (length %u)\n",
> is.rdstate () & is.badbit ? 'B' : '-',
> is.rdstate () & is.eofbit ? 'E' : '-',
> is.rdstate () & is.failbit ? 'F' : '-',
> s.c_str (), s.size ());
> assert ("x" == s);
> assert ((is.failbit | is.badbit) == is.rdstate ());
> }
> gcc -c -I/build/sebor/dev/stdlib/include/ansi -D_RWSTDDEBUG -pthreads
> -D_RWSTD_USE_CONFIG -I/build/sebor/dev/stdlib/include
> -I/build/sebor/gcc-4.1.0-15s/include -I/build/sebor/dev/stdlib/../rwtest
> -I/build/sebor/dev/stdlib/../rwtest/include
> -I/build/sebor/dev/stdlib/tests/include -pedantic -nostdinc++ -g -W -Wall
> -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long v.cpp
> gcc v.o -o v -L/build/sebor/gcc-4.1.0-15s/rwtest -lrwtest15s -pthreads
> -L/build/sebor/gcc-4.1.0-15s/lib -lstd15s -lsupc++ -lm
> state = B--, string = "x" (length 1)
> Assertion failed: (is.failbit | is.badbit) == is.rdstate (), file v.cpp, line
> 30
> Abort (core dumped)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
RE: svn commit: r597425 - in /incubator/stdcxx/branches/4.2.x: include/ansi/cwchar tests/strings/21.cwchar.cpp
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 28, 2007 6:21 PM > To: stdcxx-dev@incubator.apache.org > Subject: Re: svn commit: r597425 - in > /incubator/stdcxx/branches/4.2.x: include/ansi/cwchar > tests/strings/21.cwchar.cpp > > [EMAIL PROTECTED] wrote: > > Author: faridz > > Date: Thu Nov 22 07:20:29 2007 > > New Revision: 597425 > > > > URL: http://svn.apache.org/viewvc?rev=597425&view=rev > > If _RWSTD_STRICT_ANSI is not #defined and one or both of getwc > or putwc is shadowed by a macro, aren't the using declarations > for the two functions going to cause problems? Do you meant "_RWSTD_STRICT_ANSI is defined" ? If so, yes, there would be a compiler errors if the compiler CRT doesn't provide getwc() and/or putwc(). MSVC provides both getwc() and putwc() and also #defines getwc and putwc macros. Farid.
[jira] Assigned: (STDCXX-250) std::operator>>(istream&, string&) fails to set failbit after it extracts 0 characters
[
https://issues.apache.org/jira/browse/STDCXX-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov reassigned STDCXX-250:
Assignee: Farid Zaripov
> std::operator>>(istream&, string&) fails to set failbit after it extracts 0
> characters
> --
>
> Key: STDCXX-250
> URL: https://issues.apache.org/jira/browse/STDCXX-250
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 27. Input/Output
>Affects Versions: 4.1.2, 4.1.3
> Environment: all
>Reporter: Martin Sebor
>Assignee: Farid Zaripov
>Priority: Minor
> Fix For: 4.2.1
>
> Attachments: istream.cc.diff
>
>
> 21.3.7.9, p3 says about the string extractor: "If the function extracts no
> characters, it calls is.setstate(ios::failbit), which may throw
> ios_base::failure (27.4.4.3)." The test program below shows that in
> unbuffered mode stdcxx fails to do so when an exception is thrown during the
> third call to underflow().
> $ cat v.cpp && make v && ./v
> #include
> #include
> #include
> #include
> int main ()
> {
> struct: std::streambuf {
> int_type underflow () {
> static int i = 0;
> // i == 0: sgect() invoked from sentry ctor
> // i == 1: sgetc() invoked from operator>>()
> // i == 2: sbumpc() invoked from operator>>()
> return 1 < i++ ? throw i : 'x';
> }
> } buf;
> std::istream is (&buf);
> std::string s;
> is >> s;
> std::printf ("state = %c%c%c, string = \"%s\" (length %u)\n",
> is.rdstate () & is.badbit ? 'B' : '-',
> is.rdstate () & is.eofbit ? 'E' : '-',
> is.rdstate () & is.failbit ? 'F' : '-',
> s.c_str (), s.size ());
> assert ("x" == s);
> assert ((is.failbit | is.badbit) == is.rdstate ());
> }
> gcc -c -I/build/sebor/dev/stdlib/include/ansi -D_RWSTDDEBUG -pthreads
> -D_RWSTD_USE_CONFIG -I/build/sebor/dev/stdlib/include
> -I/build/sebor/gcc-4.1.0-15s/include -I/build/sebor/dev/stdlib/../rwtest
> -I/build/sebor/dev/stdlib/../rwtest/include
> -I/build/sebor/dev/stdlib/tests/include -pedantic -nostdinc++ -g -W -Wall
> -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long v.cpp
> gcc v.o -o v -L/build/sebor/gcc-4.1.0-15s/rwtest -lrwtest15s -pthreads
> -L/build/sebor/gcc-4.1.0-15s/lib -lstd15s -lsupc++ -lm
> state = B--, string = "x" (length 1)
> Assertion failed: (is.failbit | is.badbit) == is.rdstate (), file v.cpp, line
> 30
> Abort (core dumped)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-674) Improve configure script to lookup the dependencies through the all included headers
Improve configure script to lookup the dependencies through the all included headers Key: STDCXX-674 URL: https://issues.apache.org/jira/browse/STDCXX-674 Project: C++ Standard Library Issue Type: Improvement Components: Configuration Affects Versions: 4.2.0, 4.1.4, 4.1.3, 4.1.2 Environment: All Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Minor Fix For: 4.2.x The addition information here: http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg06170.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: [RFC] stdcxx release process, second draft
> Martin Sebor wrote:
> >
> > I've incorporated everyone's feedback and committed an
> updated version
> > with a number of enhancements of my own. Among the most
> important are
> > the new Goals section with suggested frequencies of
> releases, and the
> > integration of the Version Policy (I plan to delete versions.html).
> > Let me know what you think.
> >
> > http://incubator.apache.org/stdcxx/releases.html
> >
I have no objections on this document.
Here the some examples (the only source incompatible changes):
1. Source incompatible changes
1.1. Merging two or more overloaded functions/methods in one using
default parameters:
I.e. replacing void std::vector::resize (size_type) and void
std::vector::resize (size_type, value_type)
with void std::vector::resize (size_type, value_type = value_type()).
1.2. Implementing the additional overloads (extensions) of the standard
functions/methods:
I.e. adding std::ostream& std::ostream::operator<< (std::ostream&,
const wchar*).
1.3. Adding some function/class in global namespace, that may interfere
with user-defined function/class
(i.e without using '__; prefix):
I.e. adding function void print (const char* str) { std::cout <<
str << std::endl; } may conflict with user defined
void print (const char* str) { std::printf ("%s", str); } due to
multiple function definition.
1.4. Adding some public/protected methods not specified by standard,
that may interfere with user-defined
methods in classes, inherited from the library class.
1.5. Adding some macros that may accidentally modify the user code: i.e.
#define new(p) malloc (p).
1.6. Moving some declarations from one header file to another without
#including the second one in the first
may cause "unknown identifier" compiler error.
Farid.
RE: question on the examples for the source/forward/backward incompatible changes
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Saturday, November 24, 2007 8:29 PM > To: stdcxx-dev@incubator.apache.org > Subject: Re: question on the examples for the > source/forward/backward incompatible changes > > This is an interesting example because it doesn't actually > break programs at compile time but rather changes their > runtime behavior, something that typically is associated with > binary compatibility. Why with binary compatibility? From the current document: "Source compatibility also implies functional compatibility, although it does not necessarily imply binary compatibility." In this case if program already compiled this change is binary compatible, because the program don't knows about new overload of the existing function. At the same time this change is not source compatible because it's changes functionality of the program, compiled with the library with new overload function. > Incidentally, we even have an enhancement request for this > new inserter (maybe you've seen it): > http://issues.apache.org/jira/browse/STDCXX-296 > > But there certainly are cases where adding an overload can > break programs by introducing an ambiguity where there > previously was none. > > Martin
RE: [PING] Re: library and build sizes on Windows
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 22, 2007 2:19 AM > To: stdcxx-dev@incubator.apache.org > Subject: [PING] Re: library and build sizes on Windows > > So would be it possible to change the Windows build > infrastructure to spit out the date and time in the same > format as on UNIX? I.e., > > ### date: > Wed Oct 31 09:38:50 UTC 2007 > > Including the "### date:" part. The exact format of the > timestamp itself doesn't have to be exactly the same just as > long as it includes the time as well as the date, and it's > all on the same line. Done: http://svn.apache.org/viewvc?rev=598697&view=rev Farid.
RE: svn commit: r597111 - /incubator/stdcxx/branches/4.2.x/etc/config/src/
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Monday, November 26, 2007 10:29 PM > To: stdcxx-dev@incubator.apache.org > Subject: RE: svn commit: r597111 - > /incubator/stdcxx/branches/4.2.x/etc/config/src/ > For the first level of headers it might be doable. I suspect > a recursive implementation would be more involved. But then > again, maybe not. > Care to prototype it? I can start from windows scripts, and then implement the identical algorithm in unix makefile. Farid.
[ann] Microsoft Visual Studio 2008 released
http://msdn2.microsoft.com/en-us/vstudio/default.aspx"On Monday, Nov. 19, Microsoft announced that Visual Studio 2008 and the .NET Framework 3.5 were released to manufacturing (RTM)." Farid.
RE: Apache C++ Standard Library 4.2.0 released
> -Original Message- > From: Mark Brown [mailto:[EMAIL PROTECTED] > Sent: Friday, November 23, 2007 8:25 PM > To: stdcxx-dev@incubator.apache.org > Subject: Re: Apache C++ Standard Library 4.2.0 released > > > Ok. I'll post the announce to the C++ forum on the Russian > > Development Network (www.rsdn.ru). > > I gather this is it: http://www.rsdn.ru/forum/message/2721871.1.aspx > > > But I'm not sure that translation is needed, because I > sure that the > > all russian-speaking programmers are able to understand this > > announcement (like any other techical documentation). > > Unfortunately, not all English-speaking programmers can read Russian ;-) Use translate.google.com ;-) The result is not perfect, though. :( http://translate.google.com/translate?u=http%3A%2F%2Fwww.rsdn.ru%2Fforum %2Fmessage%2F2721871.flat.aspx&langpair=ru%7Cen&hl=en&ie=UTF8 > Looks like they found the string performance graph interesting. > Was there any useful feedback? Cyberfax says that he compiled it's application using STDCXX and the application works well, but without difference in application performance comparing with STLport. jazzer stated that STLport has the string concatenation using expression templates (http://ubiety.uwaterloo.ca/~tveldhui/papers/Expression-Templates/exprtm pl.html) but I didn't found the using of the expression templated in basic_string from STLport 5.1.4 . Farid.
question on the examples for the source/forward/backward incompatible changes
Whether these examples should be abstract, or based on C++ Standard Library declarations/definitions? Since the source incompatible changes involves changes in function/class mebmers prototype, or changes in global data/class data members declaration, or changing the place of the some declaration (i.e. moving the declaration from one header file to the another), but requirements of the all of this are stated in C++ Standard and, accordingly, any of these changes are impossible. Farid.
[jira] Resolved: (STDCXX-307) std::streambuf::imbue() stores locale when it shouldn't
[
https://issues.apache.org/jira/browse/STDCXX-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov resolved STDCXX-307.
--
Resolution: Fixed
Fixed thus: http://svn.apache.org/viewvc?rev=597665&view=rev
Regression test added thus: http://svn.apache.org/viewvc?rev=597668&view=rev
> std::streambuf::imbue() stores locale when it shouldn't
> ---
>
> Key: STDCXX-307
> URL: https://issues.apache.org/jira/browse/STDCXX-307
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 27. Input/Output
>Affects Versions: 4.1.2, 4.1.3
> Environment: all
>Reporter: Martin Sebor
>Assignee: Farid Zaripov
> Fix For: 4.2.1
>
>
> According to 27.5.2.4.1 [streambuf.virt.locales], p3, the default behavior of
> std::streambuf::imbue() is to do nothing. The program below detects
> whether the function stores the locale passed to it (it's not expected to).
> When compiled against the latest trunk the program abots at runtime
> indicating that the function does, in fact, store the locale, contrary to the
> requirement.
> $ cat z.cpp && make z && ./z
> #include
> #include
> #include
> struct MyFacet: std::locale::facet { static std::locale::id id; };
> std::locale::id MyFacet::id;
> int main ()
> {
> struct MyBuf: std::streambuf {
> void imbue (const std::locale &loc) {
> std::streambuf::imbue (loc);
> }
> } buf;
> const std::locale loc (buf.getloc (), new MyFacet);
> assert (std::has_facet(loc));
> assert (!std::has_facet(buf.getloc ()));
> buf.imbue (loc);
> assert (!std::has_facet(buf.getloc ()));
> }
> gcc -c -I/build/sebor/dev/stdlib/include/ansi -D_RWSTDDEBUG
> -D_RWSTD_USE_CONFIG -I/build/sebor/dev/stdlib/include
> -I/build/sebor/gcc-4.1.0-11s/include
> -I/build/sebor/dev/stdlib/examples/include -pedantic -nostdinc++ -g -W
> -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long z.cpp
> gcc z.o -o z -L/build/sebor/gcc-4.1.0-11s/lib -lstd11s -lsupc++ -lm
> Assertion failed: !std::has_facet(buf.getloc ()), file z.cpp, line 23
> Abort (core dumped)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-307) std::streambuf::imbue() stores locale when it shouldn't
[
https://issues.apache.org/jira/browse/STDCXX-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov reassigned STDCXX-307:
Assignee: Farid Zaripov
> std::streambuf::imbue() stores locale when it shouldn't
> ---
>
> Key: STDCXX-307
> URL: https://issues.apache.org/jira/browse/STDCXX-307
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 27. Input/Output
>Affects Versions: 4.1.2, 4.1.3
> Environment: all
>Reporter: Martin Sebor
>Assignee: Farid Zaripov
> Fix For: 4.2.1
>
>
> According to 27.5.2.4.1 [streambuf.virt.locales], p3, the default behavior of
> std::streambuf::imbue() is to do nothing. The program below detects
> whether the function stores the locale passed to it (it's not expected to).
> When compiled against the latest trunk the program abots at runtime
> indicating that the function does, in fact, store the locale, contrary to the
> requirement.
> $ cat z.cpp && make z && ./z
> #include
> #include
> #include
> struct MyFacet: std::locale::facet { static std::locale::id id; };
> std::locale::id MyFacet::id;
> int main ()
> {
> struct MyBuf: std::streambuf {
> void imbue (const std::locale &loc) {
> std::streambuf::imbue (loc);
> }
> } buf;
> const std::locale loc (buf.getloc (), new MyFacet);
> assert (std::has_facet(loc));
> assert (!std::has_facet(buf.getloc ()));
> buf.imbue (loc);
> assert (!std::has_facet(buf.getloc ()));
> }
> gcc -c -I/build/sebor/dev/stdlib/include/ansi -D_RWSTDDEBUG
> -D_RWSTD_USE_CONFIG -I/build/sebor/dev/stdlib/include
> -I/build/sebor/gcc-4.1.0-11s/include
> -I/build/sebor/dev/stdlib/examples/include -pedantic -nostdinc++ -g -W
> -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long z.cpp
> gcc z.o -o z -L/build/sebor/gcc-4.1.0-11s/lib -lstd11s -lsupc++ -lm
> Assertion failed: !std::has_facet(buf.getloc ()), file z.cpp, line 23
> Abort (core dumped)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-221) std::istream::readsome() sets badbit instead of eofbit on EOF
[ https://issues.apache.org/jira/browse/STDCXX-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545026 ] Farid Zaripov commented on STDCXX-221: -- Can't reproduce. The 27.istream.readsome.cpp test runs without assertions. > std::istream::readsome() sets badbit instead of eofbit on EOF > - > > Key: STDCXX-221 > URL: https://issues.apache.org/jira/browse/STDCXX-221 > Project: C++ Standard Library > Issue Type: Bug > Components: 27. Input/Output >Affects Versions: 4.1.2, 4.1.3 > Environment: all >Reporter: Martin Sebor > Fix For: 4.2.1 > > > Moved from the Rogue Wave bug tracking database (no test case or any detail > beyond what's in the summary provided). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-585) [gcc 4.2.0/Cygwin] linker errors due to multiple definition of `std::bad_cast::what()'; `std::bad_typeid::what()'; `std::bad_exception::what()'; `std::bad_alloc::what()'
[ https://issues.apache.org/jira/browse/STDCXX-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544875 ] Farid Zaripov commented on STDCXX-585: -- ChangeLog: 2007-11-22 Farid Zaripov <[EMAIL PROTECTED]> STDCXX-585 * BAD_ALLOC_ASSIGNMENT.cpp: Don't define ~bad_alloc() when testing the presence of the other members to avoid multiply defined sybmol linker errors. > [gcc 4.2.0/Cygwin] linker errors due to multiple definition of > `std::bad_cast::what()'; `std::bad_typeid::what()'; > `std::bad_exception::what()'; `std::bad_alloc::what()' > - > > Key: STDCXX-585 > URL: https://issues.apache.org/jira/browse/STDCXX-585 > Project: C++ Standard Library > Issue Type: Bug > Components: Configuration >Affects Versions: 4.2.0 > Environment: gcc 4.2.0 / Cygwin > Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Blocker > Fix For: 4.2.1 > > Attachments: BAD_ALLOC_ASSIGNMENT.cpp.diff > > > When building the stdcxx on Cygwin I get errors like: > make: Entering directory `/usr/src/stdcxx/trunk/build/examples' > gcc -c -I/usr/src/stdcxx/trunk/include/ansi -D_RWSTDDEBUG -D_REENTRANT > -mthreads -I/usr/src/stdcxx/trunk/include > -I/usr/src/stdcxx/trunk/build/include > -I/usr/src/stdcxx/trunk/examples/include -pedantic -nostdinc++ -g -W -Wall > -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align > /usr/src/stdcxx/trunk/examples/manual/accumulate.cpp > gcc accumulate.o -o accumulate -mthreads -L/usr/src/stdcxx/trunk/build/lib > -lstd15s -lsupc++ -lcatgets -liconv -lm > /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(tinfo.o): In > function > `_ZNK10__cxxabiv121__vmi_class_type_info12__do_dyncastEiNS_17__class_type_info10__sub_kindEPKS1_PKvS4_S6_RNS1_16__dyncast_resultE': > /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/tinfo.cc:418: > multiple definition of `std::bad_cast::what() const' > /usr/src/stdcxx/trunk/build/lib/libstd15s.a(typeinfo.o):/usr/src/stdcxx/trunk/src/typeinfo.cpp:349: > first defined here > /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(tinfo.o): In > function > `_ZNK10__cxxabiv121__vmi_class_type_info12__do_dyncastEiNS_17__class_type_info10__sub_kindEPKS1_PKvS4_S6_RNS1_16__dyncast_resultE': > /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/tinfo.cc:418: > multiple definition of `std::bad_typeid::what() const' > /usr/src/stdcxx/trunk/build/lib/libstd15s.a(typeinfo.o):/usr/src/stdcxx/trunk/src/typeinfo.cpp:414: > first defined here > /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(new_handler.o): > In function `_ZNSt9bad_allocD2Ev': > /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/new_handler.cc:48: > multiple definition of `std::bad_alloc::what() const' > /usr/src/stdcxx/trunk/build/lib/libstd15s.a(memory.o):/usr/src/stdcxx/trunk/src/memory.cpp:331: > first defined here > /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(eh_exception.o): > In function `_ZNSt13bad_exceptionD2Ev': > /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/eh_exception.cc:38: > multiple definition of `std::bad_exception::what() const' > /usr/src/stdcxx/trunk/build/lib/libstd15s.a(exception.o):/usr/src/stdcxx/trunk/src/exception.cpp:412: > first defined here > collect2: ld returned 1 exit status > make: *** [accumulate] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-585) [gcc 4.2.0/Cygwin] linker errors due to multiple definition of `std::bad_cast::what()'; `std::bad_typeid::what()'; `std::bad_exception::what()'; `std::bad_alloc::what()'
[ https://issues.apache.org/jira/browse/STDCXX-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-585: - Attachment: BAD_ALLOC_ASSIGNMENT.cpp.diff The patch is attached. > [gcc 4.2.0/Cygwin] linker errors due to multiple definition of > `std::bad_cast::what()'; `std::bad_typeid::what()'; > `std::bad_exception::what()'; `std::bad_alloc::what()' > - > > Key: STDCXX-585 > URL: https://issues.apache.org/jira/browse/STDCXX-585 > Project: C++ Standard Library > Issue Type: Bug > Components: Configuration >Affects Versions: 4.2.0 > Environment: gcc 4.2.0 / Cygwin > Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Blocker > Fix For: 4.2.1 > > Attachments: BAD_ALLOC_ASSIGNMENT.cpp.diff > > > When building the stdcxx on Cygwin I get errors like: > make: Entering directory `/usr/src/stdcxx/trunk/build/examples' > gcc -c -I/usr/src/stdcxx/trunk/include/ansi -D_RWSTDDEBUG -D_REENTRANT > -mthreads -I/usr/src/stdcxx/trunk/include > -I/usr/src/stdcxx/trunk/build/include > -I/usr/src/stdcxx/trunk/examples/include -pedantic -nostdinc++ -g -W -Wall > -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align > /usr/src/stdcxx/trunk/examples/manual/accumulate.cpp > gcc accumulate.o -o accumulate -mthreads -L/usr/src/stdcxx/trunk/build/lib > -lstd15s -lsupc++ -lcatgets -liconv -lm > /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(tinfo.o): In > function > `_ZNK10__cxxabiv121__vmi_class_type_info12__do_dyncastEiNS_17__class_type_info10__sub_kindEPKS1_PKvS4_S6_RNS1_16__dyncast_resultE': > /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/tinfo.cc:418: > multiple definition of `std::bad_cast::what() const' > /usr/src/stdcxx/trunk/build/lib/libstd15s.a(typeinfo.o):/usr/src/stdcxx/trunk/src/typeinfo.cpp:349: > first defined here > /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(tinfo.o): In > function > `_ZNK10__cxxabiv121__vmi_class_type_info12__do_dyncastEiNS_17__class_type_info10__sub_kindEPKS1_PKvS4_S6_RNS1_16__dyncast_resultE': > /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/tinfo.cc:418: > multiple definition of `std::bad_typeid::what() const' > /usr/src/stdcxx/trunk/build/lib/libstd15s.a(typeinfo.o):/usr/src/stdcxx/trunk/src/typeinfo.cpp:414: > first defined here > /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(new_handler.o): > In function `_ZNSt9bad_allocD2Ev': > /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/new_handler.cc:48: > multiple definition of `std::bad_alloc::what() const' > /usr/src/stdcxx/trunk/build/lib/libstd15s.a(memory.o):/usr/src/stdcxx/trunk/src/memory.cpp:331: > first defined here > /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(eh_exception.o): > In function `_ZNSt13bad_exceptionD2Ev': > /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/eh_exception.cc:38: > multiple definition of `std::bad_exception::what() const' > /usr/src/stdcxx/trunk/build/lib/libstd15s.a(exception.o):/usr/src/stdcxx/trunk/src/exception.cpp:412: > first defined here > collect2: ld returned 1 exit status > make: *** [accumulate] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-585) [gcc 4.2.0/Cygwin] linker errors due to multiple definition of `std::bad_cast::what()'; `std::bad_typeid::what()'; `std::bad_exception::what()'; `std::bad_alloc::what()'
[ https://issues.apache.org/jira/browse/STDCXX-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-585: - Patch Info: [Patch Available] > [gcc 4.2.0/Cygwin] linker errors due to multiple definition of > `std::bad_cast::what()'; `std::bad_typeid::what()'; > `std::bad_exception::what()'; `std::bad_alloc::what()' > - > > Key: STDCXX-585 > URL: https://issues.apache.org/jira/browse/STDCXX-585 > Project: C++ Standard Library > Issue Type: Bug > Components: Configuration >Affects Versions: 4.2.0 > Environment: gcc 4.2.0 / Cygwin > Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Blocker > Fix For: 4.2.1 > > Attachments: BAD_ALLOC_ASSIGNMENT.cpp.diff > > > When building the stdcxx on Cygwin I get errors like: > make: Entering directory `/usr/src/stdcxx/trunk/build/examples' > gcc -c -I/usr/src/stdcxx/trunk/include/ansi -D_RWSTDDEBUG -D_REENTRANT > -mthreads -I/usr/src/stdcxx/trunk/include > -I/usr/src/stdcxx/trunk/build/include > -I/usr/src/stdcxx/trunk/examples/include -pedantic -nostdinc++ -g -W -Wall > -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align > /usr/src/stdcxx/trunk/examples/manual/accumulate.cpp > gcc accumulate.o -o accumulate -mthreads -L/usr/src/stdcxx/trunk/build/lib > -lstd15s -lsupc++ -lcatgets -liconv -lm > /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(tinfo.o): In > function > `_ZNK10__cxxabiv121__vmi_class_type_info12__do_dyncastEiNS_17__class_type_info10__sub_kindEPKS1_PKvS4_S6_RNS1_16__dyncast_resultE': > /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/tinfo.cc:418: > multiple definition of `std::bad_cast::what() const' > /usr/src/stdcxx/trunk/build/lib/libstd15s.a(typeinfo.o):/usr/src/stdcxx/trunk/src/typeinfo.cpp:349: > first defined here > /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(tinfo.o): In > function > `_ZNK10__cxxabiv121__vmi_class_type_info12__do_dyncastEiNS_17__class_type_info10__sub_kindEPKS1_PKvS4_S6_RNS1_16__dyncast_resultE': > /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/tinfo.cc:418: > multiple definition of `std::bad_typeid::what() const' > /usr/src/stdcxx/trunk/build/lib/libstd15s.a(typeinfo.o):/usr/src/stdcxx/trunk/src/typeinfo.cpp:414: > first defined here > /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(new_handler.o): > In function `_ZNSt9bad_allocD2Ev': > /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/new_handler.cc:48: > multiple definition of `std::bad_alloc::what() const' > /usr/src/stdcxx/trunk/build/lib/libstd15s.a(memory.o):/usr/src/stdcxx/trunk/src/memory.cpp:331: > first defined here > /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(eh_exception.o): > In function `_ZNSt13bad_exceptionD2Ev': > /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/eh_exception.cc:38: > multiple definition of `std::bad_exception::what() const' > /usr/src/stdcxx/trunk/build/lib/libstd15s.a(exception.o):/usr/src/stdcxx/trunk/src/exception.cpp:412: > first defined here > collect2: ld returned 1 exit status > make: *** [accumulate] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-637) [_MSC_VER] 21.cwchar test fails
[ https://issues.apache.org/jira/browse/STDCXX-637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov resolved STDCXX-637. -- Resolution: Fixed Fix Version/s: 4.2.1 > [_MSC_VER] 21.cwchar test fails > --- > > Key: STDCXX-637 > URL: https://issues.apache.org/jira/browse/STDCXX-637 > Project: C++ Standard Library > Issue Type: Bug > Components: Tests >Affects Versions: 4.2.0 > Environment: MSVC, ICC/Windows > Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Minor > Fix For: 4.2.1 > > > The 21.cwchar.cpp test fails with the following assertions: > --- > # ASSERTION (S7) (4 lines): > # TEXT: masking macro getwc unexpectedly defined > # CLAUSE: lib.c.strings > # LINE: 512 > # ASSERTION (S7) (4 lines): > # TEXT: masking macro putwc unexpectedly defined > # CLAUSE: lib.c.strings > # LINE: 512 > # ASSERTION (S7) (4 lines): > # TEXT: std::wcstok() not declared (_RWSTD_NO_WCSTOK = 0, > _RWSTD_NO_WCSTOK_IN_LIBC = 0) > # CLAUSE: lib.c.strings > # LINE: 916 > --- > Also there are another assertions (see below), but I think these assertions > should be avoided when _RWSTD_NO_XXX == 1 && _RWSTD_NO_XXX_IN_LIBC == 1 > --- > # ASSERTION (S7) (4 lines): > # TEXT: std::btowc() not declared (_RWSTD_NO_BTOWC = 1, > _RWSTD_NO_BTOWC_IN_LIBC = 1) > # CLAUSE: lib.c.strings > # LINE: 942 > # ASSERTION (S7) (4 lines): > # TEXT: std::wctob() not declared (_RWSTD_NO_WCTOB = 1, > _RWSTD_NO_WCTOB_IN_LIBC = 1) > # CLAUSE: lib.c.strings > # LINE: 943 > # ASSERTION (S7) (4 lines): > # TEXT: std::mbrlen() not declared (_RWSTD_NO_MBRLEN = 1, > _RWSTD_NO_MBRLEN_IN_LIBC = 1) > # CLAUSE: lib.c.strings > # LINE: 948 > # ASSERTION (S7) (4 lines): > # TEXT: std::mbrtowc() not declared (_RWSTD_NO_MBRTOWC = 1, > _RWSTD_NO_MBRTOWC_IN_LIBC = 1) > # CLAUSE: lib.c.strings > # LINE: 949 > # ASSERTION (S7) (4 lines): > # TEXT: std::wcrtomb() not declared (_RWSTD_NO_WCRTOMB = 1, > _RWSTD_NO_WCRTOMB_IN_LIBC = 1) > # CLAUSE: lib.c.strings > # LINE: 950 > # ASSERTION (S7) (4 lines): > # TEXT: std::mbsrtowcs() not declared (_RWSTD_NO_MBSRTOWCS = 1, > _RWSTD_NO_MBSRTOWCS_IN_LIBC = 1) > # CLAUSE: lib.c.strings > # LINE: 952 > # ASSERTION (S7) (4 lines): > # TEXT: std::wcsrtombs() not declared (_RWSTD_NO_WCSRTOMBS = 1, > _RWSTD_NO_WCSRTOMBS_IN_LIBC = 1) > # CLAUSE: lib.c.strings > # LINE: 953 > --- -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-671) Rename _V3_USE_FACET macro to _RWSTD_USE_FACET
[ https://issues.apache.org/jira/browse/STDCXX-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov resolved STDCXX-671. -- Resolution: Fixed > Rename _V3_USE_FACET macro to _RWSTD_USE_FACET > -- > > Key: STDCXX-671 > URL: https://issues.apache.org/jira/browse/STDCXX-671 > Project: C++ Standard Library > Issue Type: Improvement > Components: 22. Localization >Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0 > Environment: All > Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Trivial > Fix For: 4.2.1 > > > The macro _V3_USE_FACET should be renamed to _RWSTD_USE_FACET since the > deprecated _V3_LOCALE macro were removed in STDCXX-594. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-671) Rename _V3_USE_FACET macro to _RWSTD_USE_FACET
[ https://issues.apache.org/jira/browse/STDCXX-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-671: - Description: The macro _V3_USE_FACET should be renamed to _RWSTD_USE_FACET since the deprecated _V3_LOCALE macro were removed in STDCXX-594. (was: The macro _V3_USE_FACET should be renamed to _RW_USE_FACET since the deprecated _V3_LOCALE macro were removed in STDCXX-594.) Summary: Rename _V3_USE_FACET macro to _RWSTD_USE_FACET (was: Rename _V3_USE_FACET macro to _RW_USE_FACET) _RW_USE_FACET changed to _RWSTD_USE_FACET > Rename _V3_USE_FACET macro to _RWSTD_USE_FACET > -- > > Key: STDCXX-671 > URL: https://issues.apache.org/jira/browse/STDCXX-671 > Project: C++ Standard Library > Issue Type: Improvement > Components: 22. Localization >Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0 > Environment: All > Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Trivial > Fix For: 4.2.1 > > > The macro _V3_USE_FACET should be renamed to _RWSTD_USE_FACET since the > deprecated _V3_LOCALE macro were removed in STDCXX-594. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-671) Rename _V3_USE_FACET macro to _RW_USE_FACET
Rename _V3_USE_FACET macro to _RW_USE_FACET --- Key: STDCXX-671 URL: https://issues.apache.org/jira/browse/STDCXX-671 Project: C++ Standard Library Issue Type: Improvement Components: 22. Localization Affects Versions: 4.2.0, 4.1.4, 4.1.3, 4.1.2 Environment: All Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Trivial Fix For: 4.2.1 The macro _V3_USE_FACET should be renamed to _RW_USE_FACET since the deprecated _V3_LOCALE macro were removed in STDCXX-594. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-637) [_MSC_VER] 21.cwchar test fails
[ https://issues.apache.org/jira/browse/STDCXX-637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov reassigned STDCXX-637: Assignee: Farid Zaripov > [_MSC_VER] 21.cwchar test fails > --- > > Key: STDCXX-637 > URL: https://issues.apache.org/jira/browse/STDCXX-637 > Project: C++ Standard Library > Issue Type: Bug > Components: Tests >Affects Versions: 4.2.0 > Environment: MSVC, ICC/Windows > Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Minor > > The 21.cwchar.cpp test fails with the following assertions: > --- > # ASSERTION (S7) (4 lines): > # TEXT: masking macro getwc unexpectedly defined > # CLAUSE: lib.c.strings > # LINE: 512 > # ASSERTION (S7) (4 lines): > # TEXT: masking macro putwc unexpectedly defined > # CLAUSE: lib.c.strings > # LINE: 512 > # ASSERTION (S7) (4 lines): > # TEXT: std::wcstok() not declared (_RWSTD_NO_WCSTOK = 0, > _RWSTD_NO_WCSTOK_IN_LIBC = 0) > # CLAUSE: lib.c.strings > # LINE: 916 > --- > Also there are another assertions (see below), but I think these assertions > should be avoided when _RWSTD_NO_XXX == 1 && _RWSTD_NO_XXX_IN_LIBC == 1 > --- > # ASSERTION (S7) (4 lines): > # TEXT: std::btowc() not declared (_RWSTD_NO_BTOWC = 1, > _RWSTD_NO_BTOWC_IN_LIBC = 1) > # CLAUSE: lib.c.strings > # LINE: 942 > # ASSERTION (S7) (4 lines): > # TEXT: std::wctob() not declared (_RWSTD_NO_WCTOB = 1, > _RWSTD_NO_WCTOB_IN_LIBC = 1) > # CLAUSE: lib.c.strings > # LINE: 943 > # ASSERTION (S7) (4 lines): > # TEXT: std::mbrlen() not declared (_RWSTD_NO_MBRLEN = 1, > _RWSTD_NO_MBRLEN_IN_LIBC = 1) > # CLAUSE: lib.c.strings > # LINE: 948 > # ASSERTION (S7) (4 lines): > # TEXT: std::mbrtowc() not declared (_RWSTD_NO_MBRTOWC = 1, > _RWSTD_NO_MBRTOWC_IN_LIBC = 1) > # CLAUSE: lib.c.strings > # LINE: 949 > # ASSERTION (S7) (4 lines): > # TEXT: std::wcrtomb() not declared (_RWSTD_NO_WCRTOMB = 1, > _RWSTD_NO_WCRTOMB_IN_LIBC = 1) > # CLAUSE: lib.c.strings > # LINE: 950 > # ASSERTION (S7) (4 lines): > # TEXT: std::mbsrtowcs() not declared (_RWSTD_NO_MBSRTOWCS = 1, > _RWSTD_NO_MBSRTOWCS_IN_LIBC = 1) > # CLAUSE: lib.c.strings > # LINE: 952 > # ASSERTION (S7) (4 lines): > # TEXT: std::wcsrtombs() not declared (_RWSTD_NO_WCSRTOMBS = 1, > _RWSTD_NO_WCSRTOMBS_IN_LIBC = 1) > # CLAUSE: lib.c.strings > # LINE: 953 > --- -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (STDCXX-594) remove _V3_LOCALE macro from headers and sources
[ https://issues.apache.org/jira/browse/STDCXX-594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov resolved STDCXX-594. -- Resolution: Fixed > remove _V3_LOCALE macro from headers and sources > > > Key: STDCXX-594 > URL: https://issues.apache.org/jira/browse/STDCXX-594 > Project: C++ Standard Library > Issue Type: Task > Components: 22. Localization >Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0 > Environment: all >Reporter: Martin Sebor >Assignee: Farid Zaripov >Priority: Minor > Fix For: 4.2.1 > > > The macro _V3_LOCALE that appears in a number headers and sources is unused > and should be removed, > Here's a list of library files where the macro appears. There might be other > occurrences in tests and elsewhere. > $ find ~/stdcxx/include/ ~/stdcxx/src/ -type f | xargs grep -l _V3_LOCALE | > grep -v -e "/.svn/" -e "~" > /nfs/homes/sebor/stdcxx/include/loc/_time_get.cc > /nfs/homes/sebor/stdcxx/include/loc/_convenience.h > /nfs/homes/sebor/stdcxx/include/loc/_locale.h > /nfs/homes/sebor/stdcxx/include/loc/_moneypunct.h > /nfs/homes/sebor/stdcxx/include/loc/_messages.h > /nfs/homes/sebor/stdcxx/include/loc/_numpunct.h > /nfs/homes/sebor/stdcxx/include/loc/_money_put.cc > /nfs/homes/sebor/stdcxx/include/loc/_collate.h > /nfs/homes/sebor/stdcxx/include/loc/_money_get.cc > /nfs/homes/sebor/stdcxx/include/loc/_num_put.cc > /nfs/homes/sebor/stdcxx/include/loc/_codecvt.cc > /nfs/homes/sebor/stdcxx/include/loc/_num_get.cc > /nfs/homes/sebor/stdcxx/include/loc/_moneypunct.cc > /nfs/homes/sebor/stdcxx/include/loc/_messages.cc > /nfs/homes/sebor/stdcxx/include/loc/_numpunct.cc > /nfs/homes/sebor/stdcxx/include/loc/_collate.cc > /nfs/homes/sebor/stdcxx/include/loc/_ctype.cc > /nfs/homes/sebor/stdcxx/include/loc/_ctype.h > /nfs/homes/sebor/stdcxx/include/loc/_codecvt.h > /nfs/homes/sebor/stdcxx/include/loc/_time_put.cc > /nfs/homes/sebor/stdcxx/include/rw/_defs.h > /nfs/homes/sebor/stdcxx/src/ChangeLog -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-594) remove _V3_LOCALE macro from headers and sources
[ https://issues.apache.org/jira/browse/STDCXX-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544562 ] Farid Zaripov commented on STDCXX-594: -- Maybe we should also rename _V3_USE_FACET() macro to i.e. _RW_USE_FACET() (the _STD_USE_FACET() and _USE_FACET() macros are already defined). > remove _V3_LOCALE macro from headers and sources > > > Key: STDCXX-594 > URL: https://issues.apache.org/jira/browse/STDCXX-594 > Project: C++ Standard Library > Issue Type: Task > Components: 22. Localization >Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0 > Environment: all >Reporter: Martin Sebor >Assignee: Farid Zaripov >Priority: Minor > Fix For: 4.2.1 > > > The macro _V3_LOCALE that appears in a number headers and sources is unused > and should be removed, > Here's a list of library files where the macro appears. There might be other > occurrences in tests and elsewhere. > $ find ~/stdcxx/include/ ~/stdcxx/src/ -type f | xargs grep -l _V3_LOCALE | > grep -v -e "/.svn/" -e "~" > /nfs/homes/sebor/stdcxx/include/loc/_time_get.cc > /nfs/homes/sebor/stdcxx/include/loc/_convenience.h > /nfs/homes/sebor/stdcxx/include/loc/_locale.h > /nfs/homes/sebor/stdcxx/include/loc/_moneypunct.h > /nfs/homes/sebor/stdcxx/include/loc/_messages.h > /nfs/homes/sebor/stdcxx/include/loc/_numpunct.h > /nfs/homes/sebor/stdcxx/include/loc/_money_put.cc > /nfs/homes/sebor/stdcxx/include/loc/_collate.h > /nfs/homes/sebor/stdcxx/include/loc/_money_get.cc > /nfs/homes/sebor/stdcxx/include/loc/_num_put.cc > /nfs/homes/sebor/stdcxx/include/loc/_codecvt.cc > /nfs/homes/sebor/stdcxx/include/loc/_num_get.cc > /nfs/homes/sebor/stdcxx/include/loc/_moneypunct.cc > /nfs/homes/sebor/stdcxx/include/loc/_messages.cc > /nfs/homes/sebor/stdcxx/include/loc/_numpunct.cc > /nfs/homes/sebor/stdcxx/include/loc/_collate.cc > /nfs/homes/sebor/stdcxx/include/loc/_ctype.cc > /nfs/homes/sebor/stdcxx/include/loc/_ctype.h > /nfs/homes/sebor/stdcxx/include/loc/_codecvt.h > /nfs/homes/sebor/stdcxx/include/loc/_time_put.cc > /nfs/homes/sebor/stdcxx/include/rw/_defs.h > /nfs/homes/sebor/stdcxx/src/ChangeLog -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-630) 21.string.assign test fails
[ https://issues.apache.org/jira/browse/STDCXX-630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov reassigned STDCXX-630: Assignee: Farid Zaripov > 21.string.assign test fails > --- > > Key: STDCXX-630 > URL: https://issues.apache.org/jira/browse/STDCXX-630 > Project: C++ Standard Library > Issue Type: Bug > Components: Tests >Affects Versions: 4.2.0 > Environment: All > Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Minor > Fix For: 4.2.1 > > > The 21.string.append test fails because of STDCXX-629. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-628) 21.string.append test fails
[ https://issues.apache.org/jira/browse/STDCXX-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov reassigned STDCXX-628: Assignee: Farid Zaripov > 21.string.append test fails > --- > > Key: STDCXX-628 > URL: https://issues.apache.org/jira/browse/STDCXX-628 > Project: C++ Standard Library > Issue Type: Bug > Components: Tests >Affects Versions: 4.2.0 > Environment: All > Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Minor > Fix For: 4.2.1 > > > The 21.string.append test fails because of STDCXX-438. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-633) 21.string.insert test fails
[ https://issues.apache.org/jira/browse/STDCXX-633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov reassigned STDCXX-633: Assignee: Farid Zaripov > 21.string.insert test fails > --- > > Key: STDCXX-633 > URL: https://issues.apache.org/jira/browse/STDCXX-633 > Project: C++ Standard Library > Issue Type: Bug > Components: Tests >Affects Versions: 4.2.0 > Environment: All > Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Minor > Fix For: 4.2.1 > > > The 21.string.append test fails because of STDCXX-632. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-629) std::string::assign (reverse_iterator, reverse_iterator) assigning self incorrect
[
https://issues.apache.org/jira/browse/STDCXX-629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov reassigned STDCXX-629:
Assignee: Farid Zaripov
> std::string::assign (reverse_iterator, reverse_iterator) assigning self
> incorrect
> -
>
> Key: STDCXX-629
> URL: https://issues.apache.org/jira/browse/STDCXX-629
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 21. Strings
>Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0
> Environment: All
>Reporter: Farid Zaripov
>Assignee: Farid Zaripov
>Priority: Minor
> Fix For: 4.2.1
>
>
> The 21.string.assign.cpp test has been failing a number of assertions for
> self-referential test cases that exercise the ability to assign a substring
> of a string into itself using the assign(InputIterator, InputIterator) member
> template specialization for InputIterator being an actual reverse_iterator.
> The program below reproduces the problem in a small isolated test case.
> #include
> #include
> int main ()
> {
> std::string s ("abc");
> s.assign (s.rbegin () + 1, s.rend ());
> assert ("ba" == s);
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
