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.
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=598697view=rev 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: [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: svn commit: r597111 - /incubator/stdcxx/branches/4.2.x/etc/config/src/
Farid Zaripov wrote: -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. On second thought, this seems like a fairly low priority enhancement in comparison to some of the other features we've been talking about or have scheduled (such as the test suite cleanup and the expected failures/unexpected passes extension). I suggest to open a Jira for it and decide on the priority WRT the rest of our tasks. Martin
[jira] Commented: (STDCXX-336) allow multiple config.h files in the same installation directory
[ https://issues.apache.org/jira/browse/STDCXX-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546110 ] Martin Sebor commented on STDCXX-336: - Not sure renaming the generated $BUILDDIR/include/config.h to include the name (and possibly version) of the compiler along with the build type would be a forward compatible change... allow multiple config.h files in the same installation directory Key: STDCXX-336 URL: https://issues.apache.org/jira/browse/STDCXX-336 Project: C++ Standard Library Issue Type: Improvement Components: Configuration Affects Versions: 4.1.2, 4.1.3, 4.1.4 Environment: all Reporter: Andrew Black Priority: Critical Fix For: 4.2.1 A useful enhancement could be the ability to install multiple versions of the standard library into the same location. While there is nothing in the makefiles that would prevent such an installation, a problem arises with the config.h file in the include sub directory of the install directory. Only one config.h file can reside in this location at a time, and different versions (such as those generated when characterizations are run with different compilers) may differ. One problem that needs to be considered in implementing (or deciding not to implement) this request is the situation where a config.h file hasn't been generated for a particular os/compiler/buildtype/buildtag. Another problem to consider is when you have the same os/buildtype/buildtag, but different compilers, and one or both compilers support features that the other doesn't. -- 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
So here's a question: do we think STDCXX-336 doable for 4.2.1?
Martin
Farid Zaripov wrote:
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.
[jira] Closed: (STDCXX-623) add cumulative times to the output of the exec utility
[ https://issues.apache.org/jira/browse/STDCXX-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor closed STDCXX-623. --- Resolution: Fixed Assignee: Martin Sebor Done with http://svn.apache.org/viewvc?view=revrevision=594730. Merged to 4.2.x with http://svn.apache.org/viewvc?view=revrevision=598869. Closing. add cumulative times to the output of the exec utility -- Key: STDCXX-623 URL: https://issues.apache.org/jira/browse/STDCXX-623 Project: C++ Standard Library Issue Type: New Feature Components: Utilities Affects Versions: 4.2.0 Reporter: Martin Sebor Assignee: Martin Sebor Fix For: 4.2.1 As discussed in the post below, it would be useful to know the cumulative amount of time (user, system, and wall clock) used up by the programs run by the exec utility. http://www.nabble.com/Intel-C%2B%2B-9.1-Win-XP-build-timeouts-tf4699975.html This affects version 4.2.0 (there's no exec utility in previous releases) and can be easily implemented in 4.2.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-443) [IBM XLC++] should avoid using -qinline or -Q in C++ code
[ https://issues.apache.org/jira/browse/STDCXX-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor reassigned STDCXX-443: --- Assignee: Travis Vitek [IBM XLC++] should avoid using -qinline or -Q in C++ code - Key: STDCXX-443 URL: https://issues.apache.org/jira/browse/STDCXX-443 Project: C++ Standard Library Issue Type: Improvement Components: Configuration Affects Versions: 4.1.3 Environment: IBM VisualAge C++ 6.0, 7.0, and XLC++ 8.0 Reporter: Martin Sebor Assignee: Travis Vitek Fix For: 4.2.1 Quoting from the XLC++ 8.0 Compiler Reference, page 249 (-Q option): To maximize inlining: * for C programs, specify optimization (-O) and also specify the appropriate -Q options for the C language. * for C++ programs, specify optimization (-O) but do not specify the -Q option. We should review whether our use of -Q in optimized builds is called for. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-240) #define _RWSTD_NO_EXCEPTIONS when exceptions are disabled via command line option
[ https://issues.apache.org/jira/browse/STDCXX-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-240: Priority: Minor (was: Major) Summary: #define _RWSTD_NO_EXCEPTIONS when exceptions are disabled via command line option (was: [HP aCC] #define _RWSTD_NO_EXCEPTIONS when __HPACC_NOEH is on) gcc #defines the macro __EXCEPTIONS when C++ exceptions are enabled. The macro is #undefined when -fno-exceptions is used on the command line. See: http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html When using gcc we should key in on this macro, similarly to checking __HPACC_NOEH when using HP aCC. It's likely that other compilers have similar macros that we might want to treat similarly. Making this a general enhancement (as opposed to one specific to just HP aCC) but bumping down Priority to Minor. #define _RWSTD_NO_EXCEPTIONS when exceptions are disabled via command line option - Key: STDCXX-240 URL: https://issues.apache.org/jira/browse/STDCXX-240 Project: C++ Standard Library Issue Type: Improvement Components: Build Affects Versions: 4.1.2, 4.1.3, 4.1.4 Reporter: Martin Sebor Assignee: Travis Vitek Priority: Minor Fix For: 4.2.1 Moved from the Rogue Wave bug tracking database: Class/File: stdcomp.h Fix Priority: Can Fix Long Description: *** Dec 1 1999 6:03PM *** sebor *** A request for enhancement. Subject: define RWSTD_NO_EXCEPTIONS when __HPACC_NOEH is Date: Wed, 01 Dec 1999 17:11:36 -0800 From: Chichiang Wan [EMAIL PROTECTED] Organization: California Language Labs To: oemsupport [EMAIL PROTECTED] CC: [EMAIL PROTECTED], wanc_at_hp [EMAIL PROTECTED] aCC has an option +noeh. When it is provided, __HPACC_NOEH will be defined. It would be nice for users to need to only use +noeh. For that, RWSTD_NO_EXCEPTIONS needs to be defined conditionally. = $ cat test.C #include string $ aCC +noeh -c test.C Error 46: /opt/aCC/include/memory, line 493 # Exception handling is not enabled (do not use the +noeh flag to aCC). RWSTD_THROW_NO_MSG(tmp == 0, bad_alloc); -- Chichiang Modified By: sebor @ May 29, 2000 10:28:25 PM We should do this AND test it -- not just on aCC but in general with all compilers that support this feature. -- 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
]
Martin Sebor updated STDCXX-408:
Severity: Inefficiency
Environment: HP aCC 3.37 and beyond, gcc/Linux (was: HP aCC 3.37 and
beyond)
Summary: make use of __declspec(dll{export,import}) on all platforms
(was: [HP aCC 3.37] use __declspec(dll{export,import}))
gcc also implements the __declspec(dll{im,ex}port) feature as an alternative to
__attribute__((dll{ex,im}port):
http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Function-Attributes.html
We might as well implement this enhancement across all platforms.
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.
[jira] Updated: (STDCXX-646) [MSVC] rw_putenv() limitations
[ https://issues.apache.org/jira/browse/STDCXX-646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-646: Summary: [MSVC] rw_putenv() limitations (was: [MSVC] rw_putenv() have a limitations) Corrected bad grammar in Summary. [MSVC] rw_putenv() limitations -- Key: STDCXX-646 URL: https://issues.apache.org/jira/browse/STDCXX-646 Project: C++ Standard Library Issue Type: Bug Components: Test Driver Affects Versions: 4.2.0 Environment: MSVC, ICC/Windows Reporter: Farid Zaripov Fix For: 4.2.1 In 0.printf.cpp test the rw_putenv() is used to define variable to null and to undefine variable. --- 1.rw_putenv (NULL=); // define to null (empty string) 2.rw_putenv (UNSET); // undefine if defined --- But on MSVC putenv() could not define variable to null, so: 1. rw_putenv (NULL=); undefines the NULL variable instead defining it to null; 2. rw_putenv (UNSET); does nothing instead of undefining variable -- 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:
So here's a question: do we think STDCXX-336 doable for 4.2.1?
Also, what's your take on STDCXX-242 and STDCXX-343? I think there
might be others where it's not completely clear (at least to me)
what is forward compatible and what's not.
Martin
Farid Zaripov wrote:
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.
[jira] Assigned: (STDCXX-605) [IBM XLC++] errors compiling dynatype.cpp
[ https://issues.apache.org/jira/browse/STDCXX-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor reassigned STDCXX-605: --- Assignee: Travis Vitek [IBM XLC++] errors compiling dynatype.cpp - Key: STDCXX-605 URL: https://issues.apache.org/jira/browse/STDCXX-605 Project: C++ Standard Library Issue Type: Bug Components: Examples Affects Versions: 4.2.0 Environment: XLC++ 6.0 through 9.0/AIX 5.3 Reporter: Martin Sebor Assignee: Travis Vitek Fix For: 4.2.1 The dynatype.cpp example program fails to compile with IBM XLC++ 9.0 on AIX with ethe following errors: xlCcore_r -c -I$(TOPDIR)/include/ansi-I$(TOPDIR)/include -I$(BUILDDIR)/include -I$(TOPDIR)/examples/include -O -Q -qtemplateregistry=dynatype.ti $(TOPDIR)/examples/tutorial/dynatype.cpp $(TOPDIR)/examples/tutorial/dynatype.cpp, line 203.27: 1540-0216 (S) An expression of type dynatype cannot be converted to type int. $(TOPDIR)/examples/tutorial/dynatype.cpp, line 209.30: 1540-0216 (S) An expression of type dynatype cannot be converted to type double. $(TOPDIR)/examples/tutorial/dynatype.cpp, line 215.30: 1540-0216 (S) An expression of type dynatype cannot be converted to type double. $(TOPDIR)/examples/tutorial/dynatype.cpp, line 222.35: 1540-0216 (S) An expression of type dynatype cannot be converted to type const char *. $(TOPDIR)/examples/tutorial/dynatype.cpp, line 228.35: 1540-0216 (S) An expression of type dynatype cannot be converted to type const char *. $(TOPDIR)/examples/tutorial/dynatype.cpp, line 238.28: 1540-0216 (S) An expression of type dynatype cannot be converted to type char. gmake: *** [dynatype.o] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-563) split up rw/_mutex.h
[ https://issues.apache.org/jira/browse/STDCXX-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546124 ] Martin Sebor commented on STDCXX-563: - A few things to consider: 1. The long term goal should be to eliminate the dependency of our headers on any particular implementation of the thread library and abstract everything under a common (stdcxx-only) interface. 2. Another long term goal should be to eliminate the binary incompatibility between reentrant (thread-safe) and ordinary builds. 3. In the meantime, does it make sense to introduce platform-specific subdirectories into the include directory (along the same lines as what we have under src/) or should we follow the _config.h approach taken in rev 382600 (i.e., append a suffix to the basename of the _mutex.h header)? split up rw/_mutex.h Key: STDCXX-563 URL: https://issues.apache.org/jira/browse/STDCXX-563 Project: C++ Standard Library Issue Type: Improvement Components: Build Affects Versions: 4.2.0 Reporter: Martin Sebor Fix For: 4.2.1 The internal header rw/_mutex.h has become too big and hard to maintain. It would be an improvement to split it up into multiple headers, one for each supported implementation of threads, along the lines of what was done with the rw/_config.h header in http://svn.apache.org/viewvc?view=revrevision=382600. This is too big to do for 4.2 but simple enough that it could go in 4.2.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
