Re: svn commit: r667636 - /stdcxx/branches/4.3.x/include/rw/_forward.h
On Jun 23, 2008, at 9:31 PM, Martin Sebor wrote: Travis Vitek wrote: Martin Sebor wrote: [...] I gave a number of arguments against Doxygen comments in stdcxx headers: 1) existing code doesn't use it and converting the raw HTML docs to Doxygen is an enormous task that none of us has the time to take on; Doxygenating new code without doing the same for the existing code is inconsistent and won't help us produce end-user documentation for the finished product Since we aren't providing any html documentation for any c++0x code at this time, maybe we should stop using html documentation? :P So the options are-- a) not document the c++0x code at all b) write up documentation for all new code in html to be consistent with what is used currently c) move all existing documentation over to doxygen before a single doxygen comment is added to the new code Assuming we want to have C++ 0x fully documented in 5.0 or shortly thereafter which of (b) and (c) do you think is viable? I don't think any of those choice are viable _in the near term_ but if I had to choose? C. If only to get a better idea of how much work we're really talking about. But I don't think doing that right now is really necessary. I think we all agree, there's too much C++0x work to be done in the near term that virtually prohibits migrating the old HTML docs right now. But that doesn't mean we should not be writing new documentation. ... I know that at Rogue Wave we have an xslt that transforms from doxygen generated xml files to html documentation, so unless using doxygen is totally ruled out, that can be used to bridge between the old html pages and generated ones. Yes, but the transformation isn't fully automated and according to Marc requires quite a bit of human intervention. It's clear that we don't have the bandwidth to take this on and still make our target date. I agree... to a degree. We don't have the bandwidth at present but it is not at all clear (to me at least) how much work this migration will really require. ... For starters, what prevents me from browsing all new Doxygen docs is that there is no generated HTML documentation. I and everyone else would have to install Doxygen and compile the HTML docs ourselves to get the benefit. I don't think there's anything that prevents us from copying and redistributing our own documentation. You only need Doxygen installed if you need to regenerate the docs for some reason. And because the docs aren't being generated and the generated HTML looked they're likely to contain all kinds of formatting problems. I've generated them. And yes, there are formatting problems. ... Doxygen doesn't have to document everything that it sees. There are many ways to control what will be documented. You can tell it to only generate documentation for things that have doxygen style comments or you can mark things as internal so the documentation can be conditionally disabled. I've seen the libstdc++ documentation (see below) and talked to the project's maintainers. My understanding is that they're not completely happy with it for some of the same reasons I've raised here and are considering (or maybe even working on) migrating away from Doxygen to some other tool/format. A better tool/format than Doxygen? Wow. I'd be interested in reading that thread of discussion! Link? BTW, I'm still trying to figure out what it is that you are proposing exactly. :D Brad.
Re: svn commit: r667636 - /stdcxx/branches/4.3.x/include/rw/_forward.h
Eric Lemings wrote: On Jun 23, 2008, at 9:31 PM, Martin Sebor wrote: Travis Vitek wrote: Martin Sebor wrote: [...] I gave a number of arguments against Doxygen comments in stdcxx headers: 1) existing code doesn't use it and converting the raw HTML docs to Doxygen is an enormous task that none of us has the time to take on; Doxygenating new code without doing the same for the existing code is inconsistent and won't help us produce end-user documentation for the finished product Since we aren't providing any html documentation for any c++0x code at this time, maybe we should stop using html documentation? :P So the options are-- a) not document the c++0x code at all b) write up documentation for all new code in html to be consistent with what is used currently c) move all existing documentation over to doxygen before a single doxygen comment is added to the new code Assuming we want to have C++ 0x fully documented in 5.0 or shortly thereafter which of (b) and (c) do you think is viable? I don't think any of those choice are viable _in the near term_ but if I had to choose? C. If only to get a better idea of how much work we're really talking about. [...] BTW, I'm still trying to figure out what it is that you are proposing exactly. :D We have an established (albeit undocumented) process and infrastructure for documenting code and publishing the documentation. The onus is on you and Travis to come up with a proposal if you want to change how things are done. So far you've decided on your own, despite my objections and without establishing consensus, to start adding Doxygen style comments to new headers, without reconciling the differences between the existing process and your new one, and without providing a clear path to such a reconciliation in the foreseeable future. Unless these issues are satisfactorily resolved and until there is a viable plan for producing a adequate replacement for the existing class reference on a reasonable schedule I have to insist that the Doxygen comments be removed from the newly added headers. Martin
Re: problem with Apache standard library
pendiala jaipal wrote: Hi all, I built Apache Standard Library (stdcxx-4.2.1) on HPUX with acc 3.80 on 11.23PA platform. when i create binary using libstd.sl it is giving errors. I followed these steps: aCC /home/jaipal/stdcxx-4.2.1/build/include -mt -c -o t.o ex.cpp aCC /home/jaipal/stdcxx-4.2.1/build/lib -mt t.o ./libstd.sl -o prog You're missing some options on your command line. The most important one is probably -AA (unless 3.80 changed the default from -Ap to -AA). You can see the command line options we use when building our tests and examples with stdcxx in our nightly build logs, for example in this LP64 build: http://stdcxx.apache.org/builds/4.2.x/logs/hpux-11.23-pa-acc-3.73-12D-670084-log.gz.txt compile: -AA -mt +O2 +DD64 +w +W392,655,684,818,819,849 link: -AA -mt +nostl +DD64 -Wl,+s An easy way to check that things work as they should is to compile, link, and run one of the example programs provided with the library: $ cd $BUILDDIR/examples gmake accumulate ./accumulate where BUILDDIR is the root of the directory where you chose to build stdcxx ($TOPDIR/build by default, with TOPDIR being the root of the stdcxx source tree where you expanded the tarball). Martin it is giving error as : /usr/ccs/bin/ld: /home/jaipal/Stdcxx/stdcxx-4.2.1.good/build/lib: Not a valid object file (invalid system id) if i run aCC mt t.o ./libstd.sl -o prog the prog binary is creating. when i run the binary it is giving error as : aCC runtime: Error 215 from shl_findsym ( home/jaipal/stdcxx-4.2.1/build/lib/libstd.sl ,_shlInit)' signal 11 Can you please help me on this issue and also can you tell me how to test this apache standard library . Thanks in Advance, Jaipal Reddy P.
RE: svn commit: r667636 - /stdcxx/branches/4.3.x/include/rw/_forward.h
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2008 6:55 AM To: dev@stdcxx.apache.org Subject: Re: svn commit: r667636 - /stdcxx/branches/4.3.x/include/rw/_forward.h Eric Lemings wrote: ... BTW, I'm still trying to figure out what it is that you are proposing exactly. :D We have an established (albeit undocumented) process and infrastructure for documenting code and publishing the documentation. The onus is on you and Travis to come up with a proposal if you want to change how things are done. I thought I did. To repeat...for the record, write new documentation using Doxygen comments now. Migrate the old HTML docs later. So far you've decided on your own, despite my objections and without establishing consensus, to start adding Doxygen style comments to new headers, without reconciling the differences between the existing process and your new one, and without providing a clear path to such a reconciliation in the foreseeable future. Hmm. Let me see if I can summarize your objections: 1. You don't like Doxygen. I think that's pretty evident. :) Nothing wrong with that. I think it's the best damn doc tool on the market...but that's just me. But if you know of a better tool and/or format, we're all ears. 2. We shouldn't write any documentation comments because it's not conventional. Convention isn't really the right: this is becoming more like dogma. Travis and I both realize what this means -- breaking with this convention -- moving forward. It's not easy writing docs and code at the same time, and the new code will look different from the older code (for a period of time at least), but it is the right thing to do we believe. Unless these issues are satisfactorily resolved and until there is a viable plan for producing a adequate replacement for the existing class reference on a reasonable schedule I have to insist that the Doxygen comments be removed from the newly added headers. And then what? Hope that the documentation magically appears? I'd be glad to remove it...if you have a better plan, solution, proposal... something in mind. But just removing the documentation comments is not a clear path to such reconciliation in the foreseeable future either. It's the absolute last thing we should be contemplating in fact. Brad.
Re: svn commit: r667636 - /stdcxx/branches/4.3.x/include/rw/_forward.h
Eric Lemings wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2008 6:55 AM To: dev@stdcxx.apache.org Subject: Re: svn commit: r667636 - /stdcxx/branches/4.3.x/include/rw/_forward.h Eric Lemings wrote: ... BTW, I'm still trying to figure out what it is that you are proposing exactly. :D We have an established (albeit undocumented) process and infrastructure for documenting code and publishing the documentation. The onus is on you and Travis to come up with a proposal if you want to change how things are done. I thought I did. To repeat...for the record, write new documentation using Doxygen comments now. Migrate the old HTML docs later. Sorry. One sentence doesn't make a proposal, certainly not one this vague. So far you've decided on your own, despite my objections and without establishing consensus, to start adding Doxygen style comments to new headers, without reconciling the differences between the existing process and your new one, and without providing a clear path to such a reconciliation in the foreseeable future. Hmm. Let me see if I can summarize your objections: 1. You don't like Doxygen. I think that's pretty evident. :) Not at all. You completely misinterpreted what I said. Nothing wrong with that. I think it's the best damn doc tool on the market...but that's just me. But if you know of a better tool and/or format, we're all ears. 2. We shouldn't write any documentation comments because it's not conventional. Nope. Again, you're missing my point. I'm saying changes to process should be made only with a solid plan in place and with consensus. Convention isn't really the right: this is becoming more like dogma. Travis and I both realize what this means -- breaking with this convention -- moving forward. It's not easy writing docs and code at the same time, and the new code will look different from the older code (for a period of time at least), but it is the right thing to do we believe. I disagree. Unless these issues are satisfactorily resolved and until there is a viable plan for producing a adequate replacement for the existing class reference on a reasonable schedule I have to insist that the Doxygen comments be removed from the newly added headers. And then what? Hope that the documentation magically appears? I'd be glad to remove it...if you have a better plan, solution, proposal... something in mind. The current process is to maintain the existing docs in HTML, using the existing infrastructure to publish the docs on the site. You want to change it? Fine. Propose in detail how and when this will change will take place and when we can expect it to be done. But just removing the documentation comments is not a clear path to such reconciliation in the foreseeable future either. It's the absolute last thing we should be contemplating in fact.
Re: tests/utilities/20.meta.help.cpp
Martin Sebor wrote:
Travis Vitek wrote:
[...]
IMO, the class should have an explicit requirement on the first
template argument. If there isn't one I would propose adding
paragraph 2 with the text:
-2- The template parameter T shall have an integral type (3.9.1).
integral_constantT::value shall be a integral constant
expression (5.19).
With concepts, we would change the definition of the class like
this (I think):
template IntegralConstantExpressionType T, T v
Actually, I don't think this is quite sufficient. T is more
constrained than that. If there were an OR in Concepts it
would be:
template IntegralConstantExpressionType T, T v
requires IntegralTypeT || EnumerationTypeT
struct integral_constant;
I've written up an issue/proposal to fix this without using
concepts that I plan to send to the list shortly unless you
see a better way of dealing with it. Here's the proposal:
Add a new paragraph to [meta.help] with the following
requirement:
-2- The template parameter T shall have an integral type
(3.9.1) or be an enumeration (3.9.2).
integral_constantT::value shall be an integral
constant expression (5.19).
In addition, declare the value data member of the template
constexpr:
template class T, T v
struct integral_constant {
typedef T value_type;
typedef integral_constantvalue_type, v type;
static constexpr value_type value = v;
};
struct integral_constant {
// ...
};
Strangely, this isn't in N2625:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2625.pdf
Incidentally, it also seems to me that value should be declared
constexpr (both in our implementation and in the spec).
Travis
Re: svn commit: r668347 - /stdcxx/branches/4.3.x/tests/utilities/20.meta.rel.cpp
[EMAIL PROTECTED] wrote: Author: vitek Date: Mon Jun 16 16:35:21 2008 New Revision: 668347 URL: http://svn.apache.org/viewvc?rev=668347view=rev Log: 2008-06-16 Travis Vitek [EMAIL PROTECTED] [...] @@ -346,7 +332,7 @@ TEST (std::is_convertible, int (), int ()(char), false); TEST (std::is_convertible, int*, void*, true); -TEST (std::is_convertible, int (*)(), void*, true); +TEST (std::is_convertible, int (*)(), void*, false); Should the convertibility of functions with different language linkages, and that of member function pointers, be exercised as well? Martin
RE: svn commit: r668347 - /stdcxx/branches/4.3.x/tests/utilities/20.meta.rel.cpp
Martin Sebor wrote: [EMAIL PROTECTED] wrote: Author: vitek Date: Mon Jun 16 16:35:21 2008 New Revision: 668347 URL: http://svn.apache.org/viewvc?rev=668347view=rev Log: 2008-06-16 Travis Vitek [EMAIL PROTECTED] [...] @@ -346,7 +332,7 @@ TEST (std::is_convertible, int (), int ()(char), false); TEST (std::is_convertible, int*, void*, true); -TEST (std::is_convertible, int (*)(), void*, true); +TEST (std::is_convertible, int (*)(), void*, false); Should the convertibility of functions with different language linkages, and that of member function pointers, be exercised as well? Absolutely. Will enhance test. Martin
Re: HP aCC 3.63 compilation error in 21.string.append.stdcxx-438.cpp
Travis Vitek wrote: Martin Sebor wrote: The test fails to compile with HP aCC 3.63. The error messages point to the patch for the issue: http://svn.apache.org/viewvc?view=revrevision=629550 Actually, I think it was me that caused the problem, in the following change: http://svn.apache.org/viewvc?view=revrevision=669747 The fix was for STDCXX-170 and friends, but break on every compiler when the Iterator::operator*() returns a temporary (which is legal). That's what I thought was your objection to Farid's patch. Am I to understand that the code somehow detects whether operator*() returns a rvalue or lvalue and the branch with the cast is only supposed to be entered for lvalues? (I'm still uncomfortable with the cast and would like to understand why it's safe). It looks like I'd need to do a special case when the iterator type is pointer. I don't see any way to legally check for no overlap without that, so the only option I can see then is to always make the copy and fix it with an overload selection trick (which would only be appropriate for 4.3.x). I think it should be fine to optimize just the common case (const_pointer) and leave the rest unoptimized (i.e., make a copy). Or can you think of another common use that should be optimized as well? Travis Looking at the patch I don't see how the reinterpret_cast to const_reference can possibly be correct, and I'm not sure we satisfactorily resolved the same question the first time it was raised back in March: http://markmail.org/message/eijfmt3wxhg25bvs Farid? Thanks Martin
Re: svn commit: r671294 - in /stdcxx/branches/4.3.x/include: rw/_meta_arr.h rw/_meta_cat.h rw/_meta_comp.h rw/_meta_cv.h rw/_meta_other.h rw/_meta_prop.h rw/_meta_ptr.h rw/_meta_ref.h rw/_meta_rel.h r
[EMAIL PROTECTED] wrote:
Author: vitek
Date: Tue Jun 24 11:55:30 2008
New Revision: 671294
URL: http://svn.apache.org/viewvc?rev=671294view=rev
Log:
2008-06-24 Travis Vitek [EMAIL PROTECTED]
STDCXX-916
* include/type_traits: Remove doxygen comments, leaving C++
comments where appropriate.
[...]
Modified: stdcxx/branches/4.3.x/include/rw/_meta_arr.h
URL:
http://svn.apache.org/viewvc/stdcxx/branches/4.3.x/include/rw/_meta_arr.h?rev=671294r1=671293r2=671294view=diff
==
--- stdcxx/branches/4.3.x/include/rw/_meta_arr.h (original)
+++ stdcxx/branches/4.3.x/include/rw/_meta_arr.h Tue Jun 24 11:55:30 2008
@@ -34,32 +34,18 @@
_RWSTD_NAMESPACE (__rw) {
-/**
- * TransformationTrait strips one dimension from an array type, leaving
- * other types as-is. The primary template is for non-array types.
- */
Many of these seem like useful comments. Are you sure you meant
to delete them?
template class _TypeT
struct __rw_remove_extent
{
typedef _TypeT type;
};
[...]
-/**
- * This template prevents the partial specialization below from
- * being instantiated on types for which it would fail or give
- * invalid results. i.e. it avoids creating references to void or
- * arrays with unknown length and for returning bad results for
- * references to functions.
- *
- * All void, array and reference types are not functions.
- */
This one especially, for example, but others below as well.
template class _TypeT, bool =__rw_is_void_TypeT::value
|| __rw_is_array_TypeT::value
|| __rw_is_lvalue_reference_TypeT::value
@@ -266,13 +219,6 @@
enum { _C_value = 0 };
};
Martin
question about aligned_storage
While looking at the hoops we jump through to implement aligned_storage I recalled the gcc __attribute__ (aligned (N)). Is there any to use it to simplify the implementation for gcc? See http://tinyurl.com/5kmvdy for reference. Martin
RE: Some internal aliases for __rw_integral_constant?
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Tuesday, June 24, 2008 5:11 PM
To: dev@stdcxx.apache.org
Subject: Re: Some internal aliases for __rw_integral_constant?
Eric Lemings wrote:
Propose adding the following defs (or something similar) to
rw/_meta_help.h primarily for our own convenience:
template bool _Bool
class __rw_bool_const: public __rw_integral_constantbool,
_Bool {};
I was going to suggest the same thing this morning when I noticed
how pervasive __rw_integral_constantbool, _Bool seems to be in
traits definitions (I count 41 occurrences) and thinking that it
would make them less verbose. (With a different spelling of _Bool
to avoid potential clashes with the C99 name.)
Good point.
I didn't because the only beneficiaries of the change would be us
(a fairly small notational convenience) and I wasn't sure the cost
in terms of the added complexity and compilation time was worth it.
I contemplated suggesting a macro for the same purpose instead but
decided against it on the assumption that it probably wouldn't be
very popular ;-) But now that the cat's out of the bag and you're
asking about alternatives let me throw it out there:
#define _RWSTD_BOOL_CONST(B) _RW::__rw_integral_constantbool, B
Usage:
_RW::__rw_bool_constbool, false
vs
_RWSTD_BOOL_CONST (false)
Looks good to me. I'll just add _RWSTD_BOOL_CONST for now.
Brad.
RE: HP aCC 3.63 compilation error in 21.string.append.stdcxx-438.cpp
Martin Sebor wrote: Travis Vitek wrote: Martin Sebor wrote: The test fails to compile with HP aCC 3.63. The error messages point to the patch for the issue: http://svn.apache.org/viewvc?view=revrevision=629550 Actually, I think it was me that caused the problem, in the following change: http://svn.apache.org/viewvc?view=revrevision=669747 The fix was for STDCXX-170 and friends, but break on every compiler when the Iterator::operator*() returns a temporary (which is legal). That's what I thought was your objection to Farid's patch. Yes, it was. Unfortunately I forgot about this issue part way through making my patch. Am I to understand that the code somehow detects whether operator*() returns a rvalue or lvalue and the branch with the cast is only supposed to be entered for lvalues? Sort of. The code checks that the _InputIter is a pointer. If it is, then we know it is safe to use the pointer to check for overlap. (I'm still uncomfortable with the cast and would like to understand why it's safe). It seems that the cast itself is legal because expr.static.cast says An expression e can be explicitly converted to a type T using static_cast of the form static_castT(e) if the declaration T t(e); is well-formed, for some invented temporary variable t. The declaration const_reference t(*__first); is legal if *__first is convertible to value_type, which is required, so everything seems okay here, right? The problem with the original testcase was that the cast can end up giving us a pointer to a temporary if *__first doesn't return a reference, which can result in invalid results. The testcase I provided showed this. My fix eliminated the cast (which caused breakage), but verifies that __first is actually a raw pointer type before trying to get a reference out of it. So I think that we may be able to combine the two patches to come up with a usable fix. If we avoid doing the cast until we know that __first is a pointer, then we can be sure that the cast is giving us reliable results. If __first is not a pointer, then all bets are off and we have to fall back to making a copy. It looks like I'd need to do a special case when the iterator type is pointer. I don't see any way to legally check for no overlap without that, so the only option I can see then is to always make the copy and fix it with an overload selection trick (which would only be appropriate for 4.3.x). I think it should be fine to optimize just the common case (const_pointer) and leave the rest unoptimized (i.e., make a copy). Or can you think of another common use that should be optimized as well? I think all cv-qualified pointer types could be optimized in this way. Travis Looking at the patch I don't see how the reinterpret_cast to const_reference can possibly be correct, and I'm not sure we satisfactorily resolved the same question the first time it was raised back in March: http://markmail.org/message/eijfmt3wxhg25bvs Farid? Thanks Martin
RE: question about aligned_storage
Martin Sebor wrote: While looking at the hoops we jump through to implement aligned_storage I recalled the gcc __attribute__ (aligned (N)). Is there any to use it to simplify the implementation for gcc? We already do. Have a look at the definition of the macro _RWSTD_TT_ALIGNED_POD(). I might be able to eliminate __rw_aligned_storage_impl if I wanted to do a partial specialization of __rw_aligned_storage on the _Align non-type template parameter and I could also eliminate __rw_default_alignment, but that is about as much as I think I could reduce it. See http://tinyurl.com/5kmvdy for reference. Martin
Re: question about aligned_storage
Travis Vitek wrote: Martin Sebor wrote: While looking at the hoops we jump through to implement aligned_storage I recalled the gcc __attribute__ (aligned (N)). Is there any to use it to simplify the implementation for gcc? We already do. You're a step (or a few) ahead of me, as usual... :) Have a look at the definition of the macro _RWSTD_TT_ALIGNED_POD(). You mean the one in rw/_gcc-config.h on the 103 character long line? (You almost got away with it ;-) I might be able to eliminate __rw_aligned_storage_impl if I wanted to do a partial specialization of __rw_aligned_storage on the _Align non-type template parameter and I could also eliminate __rw_default_alignment, but that is about as much as I think I could reduce it. I'm probably missing something but is aligned_storage only specified for alignment of powers of 2? (It looks to me as though those are the only alignments we support.) Martin See http://tinyurl.com/5kmvdy for reference. Martin
