Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: stdcxx-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of msebor@gmail.com designates
 72.14.214.232 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=received:message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender;
        b=vRcUfKbaobHNWG/TPsC9HMI2uXPeKoF/83ezsC1E3PDWjpdeKVjRWAn3yHBYisgmDlE7uMmrachOwrDLNfHMti+YzAcqxtJhad7kcRpVpZAmY4ONQLgs5jeXAcWQuLu/E2gQr2mCqpbyguauDGg4QVxWNoRCtZxrGjAJDcrBQPA=
Message-ID: <474CF5A9.30208@roguewave.com>
Date: Tue, 27 Nov 2007 21:59:21 -0700
From: Martin Sebor <sebor@roguewave.com>
Organization: Rogue Wave Software, Inc.
User-Agent: Thunderbird 2.0.0.9 (X11/20071031)
MIME-Version: 1.0
To: stdcxx-dev@incubator.apache.org
Subject: Re: [RFC] stdcxx release process, second draft
References: <472951EF.6070105@roguewave.com> <13719498.post@talk.nabble.com>
 <13849210.post@talk.nabble.com>
 <7BDB2168BEAEF14C98F1901FD2DE643801482FB0@epmsa009.minsk.epam.com>
In-Reply-To: 
 <7BDB2168BEAEF14C98F1901FD2DE643801482FB0@epmsa009.minsk.epam.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Martin Sebor <msebor@gmail.com>

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.
>