stlport-devel — STLport developers and contributors mail list

[Stlport-devel] STLport support for std::uncaught_exception

[Jeffrey W. <nol...@gm...>]

Hi everyone,

Crypto++ has the following in its configuration file. It is used to
test for the availability of std::uncaught_exception.

#if (defined(_MSC_VER) && _MSC_VER <= 1300) || defined(__MWERKS__) ||
defined(_STLPORT_VERSION)
# define CRYPTOPP_DISABLE_UNCAUGHT_EXCEPTION
#endif

I suspect the part related ot STL port is outdated and wrong. It was
likely put in place in the late 1990s.

What should be used to test for availability of
std::uncaught_exception that works dating back to circa 2000?

Thanks in advance.

Jeff

[Stlport-devel] Getting error STLport-5.2.1/stlport/using/ios:5: error: _STLP_NEW_IO_NAMESPACE has not been declared

[Suresh <skj...@ho...>]

Hello, i'm getting following error when tyring to compile my code on Linux.

STLport-5.2.1/stlport/using/ios:5: error: _STLP_NEW_IO_NAMESPACE has not been declared

I have compile STLport-5.2.1 using make -f Makefile

-----------------------
 from /development/WLS/STL/STLport-5.2.1/stlport/streambuf.h:30,
                 from /development/WLS/STL/STLport-5.2.1/stlport/iostream.h:27,
                 from /users/mdhanork/p4work/NEW/WAF_7_4_maint_branch/WAF/wls/src/gadellippt.cxx:32:
/development/WLS/STL/STLport-5.2.1/stlport/using/ios:5: error: âstlp_std::iosâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/using/ios:6: error: âstlp_std::streamoffâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/using/ios:7: error: âstlp_std::streamsizeâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/using/ios:9: error: âstlp_std::ios_baseâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/using/ios:10: error: âstlp_std::basic_iosâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/using/ios:13: error: âstlp_std::boolalphaâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/using/ios:14: error: âstlp_std::noboolalphaâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/using/ios:15: error: âstlp_std::showbaseâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/using/ios:16: error: âstlp_std::noshowbaseâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/using/ios:17: error: âstlp_std::showpointâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/using/ios:18: error: âstlp_std::noshowpointâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/using/ios:19: error: âstlp_std::showposâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/using/ios:20: error: âstlp_std::noshowposâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/using/ios:21: error: âstlp_std::skipwsâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/using/ios:22: error: âstlp_std::noskipwsâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/using/ios:23: error: âstlp_std::uppercaseâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/using/ios:24: error: âstlp_std::nouppercaseâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/using/ios:27: error: âstlp_std::internalâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/using/ios:28: error: âstlp_std::leftâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/using/ios:29: error: âstlp_std::rightâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/using/ios:32: error: âstlp_std::decâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/using/ios:33: error: âstlp_std::hexâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/using/ios:34: error: âstlp_std::octâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/using/ios:37: error: âstlp_std::fixedâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/using/ios:38: error: âstlp_std::scientificâ has not been declared
In file included from /development/WLS/STL/STLport-5.2.1/stlport/iostream.h:27,
                 from /users/mdhanork/p4work/NEW/WAF_7_4_maint_branch/WAF/wls/src/gadellippt.cxx:32:
/development/WLS/STL/STLport-5.2.1/stlport/streambuf.h:36: error: âstlp_std::basic_streambufâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/streambuf.h:37: error: âstlp_std::streambufâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/streambuf.h:39: error: âstlp_std::wstreambufâ has not been declared
In file included from /development/WLS/STL/STLport-5.2.1/stlport/ostream.h:29,
                 from /development/WLS/STL/STLport-5.2.1/stlport/iostream.h:28,
                 from /users/mdhanork/p4work/NEW/WAF_7_4_maint_branch/WAF/wls/src/gadellippt.cxx:32:
/development/WLS/STL/STLport-5.2.1/stlport/using/ostream:1: error: âstlp_std::basic_ostreamâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/using/ostream:2: error: âstlp_std::ostreamâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/using/ostream:5: error: âstlp_std::wostreamâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/using/ostream:8: error: âstlp_std::endlâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/using/ostream:9: error: âstlp_std::endsâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/using/ostream:10: error: âstlp_std::flushâ has not been declared
In file included from /development/WLS/STL/STLport-5.2.1/stlport/iostream.h:29,
                 from /users/mdhanork/p4work/NEW/WAF_7_4_maint_branch/WAF/wls/src/gadellippt.cxx:32:
/development/WLS/STL/STLport-5.2.1/stlport/istream.h:32: error: âstlp_std::basic_istreamâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/istream.h:33: error: âstlp_std::basic_iostreamâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/istream.h:34: error: âstlp_std::istreamâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/istream.h:35: error: âstlp_std::iostreamâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/istream.h:36: error: âstlp_std::iosâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/istream.h:38: error: âstlp_std::wistreamâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/istream.h:39: error: âstlp_std::wiostreamâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/istream.h:41: error: âstlp_std::wsâ has not been declared
In file included from /users/mdhanork/p4work/NEW/WAF_7_4_maint_branch/WAF/wls/src/gadellippt.cxx:32:
/development/WLS/STL/STLport-5.2.1/stlport/iostream.h:36: error: âstlp_std::cinâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/iostream.h:37: error: âstlp_std::coutâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/iostream.h:38: error: âstlp_std::clogâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/iostream.h:39: error: âstlp_std::cerrâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/iostream.h:40: error: âstlp_std::iostreamâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/iostream.h:42: error: âstlp_std::wcinâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/iostream.h:43: error: âstlp_std::wcoutâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/iostream.h:44: error: âstlp_std::wclogâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/iostream.h:45: error: âstlp_std::wcerrâ has not been declared
/development/WLS/STL/STLport-5.2.1/stlport/iostream.h:53: error: expected class-name before â{â token
/development/WLS/STL/STLport-5.2.1/stlport/iostream.h:58: error: declaration of âoperator=â as non-function
/development/WLS/STL/STLport-5.2.1/stlport/iostream.h:58: error: expected â;â before â(â token
/development/WLS/STL/STLport-5.2.1/stlport/iostream.h:62: error: expected â;â before âistream_withassignâ
/development/WLS/STL/STLport-5.2.1/stlport/iostream.h:62: error: declaration of âoperator=â as non-function
/development/WLS/STL/STLport-5.2.1/stlport/iostream.h:62: error: expected â;â before â(â token
/development/WLS/STL/STLport-5.2.1/stlport/iostream.h:66: error: expected â;â before â}â token
/development/WLS/STL/STLport-5.2.1/stlport/iostream.h: In constructor âistream_withassign::istream_withassign()â:
/development/WLS/STL/STLport-5.2.1/stlport/iostream.h:55: error: class âistream_withassignâ does not have any field named âistreamâ
/development/WLS/STL/STLport-5.2.1/stlport/iostream.h:55: error: âstreambufâ was not declared in this scope
/development/WLS/STL/STLport-5.2.1/stlport/iostream.h:55: error: expected primary-expression before â)â token
/development/WLS/STL/STLport-5.2.1/stlport/iostream.h: At global scope:
/development/WLS/STL/STLport-5.2.1/stlport/iostream.h:68: error: expected class-name before â{â token
/development/WLS/STL/STLport-5.2.1/stlport/iostream.h:73: error: declaration of âoperator=â as non-function
/development/WLS/STL/STLport-5.2.1/stlport/iostream.h:73: error: expected â;â before â(â token
/development/WLS/STL/STLport-5.2.1/stlport/iostream.h:77: error: expected â;â before âostream_withassignâ

Can any one help me regarding this to solve this problem.
Thanks
Suresh
 		 	   		  

[Stlport-devel] STLPort and Atmel IDE

[Ron O. <ro...@ya...>]

 Has anyone gotten this working in the Atmel Studio environment?

Re: [Stlport-devel] C++11, release, roadmap?

[Petr O. <pt...@vo...>]

Good day,

On Mon, 30 Sep 2013 19:06:33 +0900
"Yanchenko, Maxim" <Max...@gs...> wrote:

> Hi,
> 
> In my project, I'd like to move to C++11 but the currently used STLPort 5.2 doesn't allow me to
> do this. Hence the questions:
> 
> 
> 1)      Is STLPort alive?

Hm. How the health of GS after last crisis? Is it still alive?

> It looks like the last commit was in 2012, unless SF is wrong.

In public repositories---yes, Dec 29 2012.

> (The following questions assume the answer is "Yes")
> 
> 2)      What is its current C++11 status?

Under development.

> 
> 3)      Is it production-ready? (if yes, why not make an official release?)

You ask incorrect question. For incorrect question the answer may be arbitrary.

In the development model that many projects use now the term 'release'
has a little sense.

Major 'release' possible when full C++-11 standard will be implemented
(at least implemented). I have some progress in this direction.
There are a lot of work remains. But now I spend a little time
to this project. Do you want to be involved?

> 
> 4)      Which parts of the C++11 Standard Library are implemented?

Check master first. In not published development --- implemented smart pointers
and some work about tuples (under constructiuon).
Disclimer: I don't worry about Windows at all.

> 
> 5)      Is there any roadmap for STLPort available?

1. Accept 1500 lines of wonderful code from you.
2. Make STLport 7.0 with full support of C++-11.

With best regards,

--

  - Petr

[Stlport-devel] C++11, release, roadmap?

[Yanchenko, M. <Max...@gs...>]

Hi,

In my project, I'd like to move to C++11 but the currently used STLPort 5.2 doesn't allow me to do this. Hence the questions:


1)      Is STLPort alive? It looks like the last commit was in 2012, unless SF is wrong.
(The following questions assume the answer is "Yes")

2)      What is its current C++11 status?

3)      Is it production-ready? (if yes, why not make an official release?)

4)      Which parts of the C++11 Standard Library are implemented?

5)      Is there any roadmap for STLPort available?

Thanks,
Maxim

[Stlport-devel] Error while building: ptrdiff_t is not defined

[Lam, D. D. <dl...@in...>]

I'm getting this error while trying to run make:
stl/_iterator_base.h, line 56: Error: ptrdiff_t is not defined.

I believe ptrdiff_t is defined in cstddef and cstddef should be included:
33 #ifndef _STLP_CSTDDEF
34 # include <cstddef>
35 #endif

However, for some reason it's not. And I couldn't figure out why. Any suggestions?

I'm building on Solaris Sparc 64 bits and the version I'm building is 4.5.3.

Thank you!

[Stlport-devel] ***_#@(+)*^++.!)___)*#_$_+-_*_

[dream n. <dre...@gm...>]

http://azienda-casalino.com/mxyrcwuz/jhuzqyywfu

Re: [Stlport-devel] [stlport-bugs] Fwd: Issues with the stlport library

[Petr O. <pt...@vo...>]

Good day,

On Mon, 3 Jun 2013 18:08:39 +0800
Chenyang <du...@gm...> wrote:

> Hi Ptr,
> 1. For long long type issue.
> Below additional check with yellow background can be added into function
> __get_integer() to fix the *long long* type corner case.


It would be better if you send _normal_ patch (patchset) against 
STLport-5.2 (right?) branch.

With best regards,

--

  - ptr

Re: [Stlport-devel] [stlport-bugs] Fwd: Issues with the stlport library

[Chenyang <du...@gm...>]

Hi Ptr,
1. For long long type issue.
Below additional check with yellow background can be added into function
__get_integer() to fix the *long long* type corner case.

Refer to file: stlport/stlport/stl/_num_get.c:118

if ((-__result == (numeric_limits<_Integer>::min)()) && !__is_negative)
    __ovflow = true;

if (__is_group && __group_sizes_end != __group_sizes) {
    
*__group_sizes_end++ = __current_group_size;
}

2. For short issue.
It can be fixed by such a simple way.
We found a short version *get() *lies at stlport/stlport/stl/_num_get.h#70.
But it was disabled by macro _STLP_FIX_LIBRARY_ISSUES.
Can you give us any hints why they have been omitted as we found nothing
from the commit/upgrade logs?

69#*if* *defined* (_STLP_FIX_LIBRARY_ISSUES)
70  _InputIter get(_InputIter __ii, _InputIter __end, ios_base& __str,
71                 ios_base::iostate& __err, *short*& __val) *const*
72  { *return* do_get(__ii, __end, __str, __err, __val); }
73
74  _InputIter get(_InputIter __ii, _InputIter __end, ios_base& __str,
75                 ios_base::iostate
<http://sourcebrowser.tl.intel.com:8080/source/s?defs=iostate&project=ABSP_R4_JB_main>&
__err, *int*& __val) *const*
76  { *return* do_get(__ii, __end, __str, __err, __val); }
77#*endif*



Thanks.

On Mon, Jun 3, 2013 at 5:19 PM, Chenyang <du...@gm...> wrote:

> This issue were seen on Android.
> Many libs and apps will depend on STLPort.
> We want to know whether it will be fixed in future release.
> Currently, we have a patch to fix the issue with *long long* type.
> But for *short* type, huge revision may be needed.
>
>
>
> On Mon, Jun 3, 2013 at 2:02 PM, Petr Ovtchenkov <pt...@vo...> wrote:
>
>> On Fri, 31 May 2013 09:54:06 +0800
>> Chenyang <du...@gm...> wrote:
>>
>> > ...
>> > An issue with the stlport library has been found. The string conversion
>> to
>> > long long or short does not have the expected behavior.
>> >
>>
>> The operations related to numbers representation isn't perfect in STLport.
>>
>> The facility of 'small simple fixes' was exhausted in this area.
>>
>> The key point is incorporation of a library with implementation of
>> abitrary (well, may be not abitrary..., but 'enough') precision
>> rational arithmetic.
>>
>> Possible ways are:
>>
>>   - implement such library within STLport project
>>
>>   - use well-designed library (GMP/MPFR/etc.)
>>
>>   - us not well-known library (what?)
>>
>> In any case, numeric representation code require deep revision.
>>
>> --
>>
>>   - ptr
>>
>>
>> ------------------------------------------------------------------------------
>> Get 100% visibility into Java/.NET code with AppDynamics Lite
>> It's a free troubleshooting tool designed for production
>> Get down to code-level detail for bottlenecks, with <2% overhead.
>> Download for free and get started troubleshooting in minutes.
>> http://p.sf.net/sfu/appdyn_d2d_ap2
>> _______________________________________________
>> stlport-bugs mailing list
>> stl...@li...
>> https://lists.sourceforge.net/lists/listinfo/stlport-bugs
>>
>
>
>
> --
> Chenyang
>



-- 
Chenyang

Re: [Stlport-devel] [stlport-bugs] Fwd: Issues with the stlport library

[Chenyang <du...@gm...>]

This issue were seen on Android.
Many libs and apps will depend on STLPort.
We want to know whether it will be fixed in future release.
Currently, we have a patch to fix the issue with *long long* type.
But for *short* type, huge revision may be needed.



On Mon, Jun 3, 2013 at 2:02 PM, Petr Ovtchenkov <pt...@vo...> wrote:

> On Fri, 31 May 2013 09:54:06 +0800
> Chenyang <du...@gm...> wrote:
>
> > ...
> > An issue with the stlport library has been found. The string conversion
> to
> > long long or short does not have the expected behavior.
> >
>
> The operations related to numbers representation isn't perfect in STLport.
>
> The facility of 'small simple fixes' was exhausted in this area.
>
> The key point is incorporation of a library with implementation of
> abitrary (well, may be not abitrary..., but 'enough') precision
> rational arithmetic.
>
> Possible ways are:
>
>   - implement such library within STLport project
>
>   - use well-designed library (GMP/MPFR/etc.)
>
>   - us not well-known library (what?)
>
> In any case, numeric representation code require deep revision.
>
> --
>
>   - ptr
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> _______________________________________________
> stlport-bugs mailing list
> stl...@li...
> https://lists.sourceforge.net/lists/listinfo/stlport-bugs
>



-- 
Chenyang

Re: [Stlport-devel] [stlport-bugs] Fwd: Issues with the stlport library

[Petr O. <pt...@vo...>]

On Fri, 31 May 2013 09:54:06 +0800
Chenyang <du...@gm...> wrote:

> ...
> An issue with the stlport library has been found. The string conversion to
> long long or short does not have the expected behavior.
> 

The operations related to numbers representation isn't perfect in STLport.

The facility of 'small simple fixes' was exhausted in this area.

The key point is incorporation of a library with implementation of
abitrary (well, may be not abitrary..., but 'enough') precision
rational arithmetic.

Possible ways are:

  - implement such library within STLport project

  - use well-designed library (GMP/MPFR/etc.)

  - us not well-known library (what?)

In any case, numeric representation code require deep revision.

--

  - ptr

[Stlport-devel] Issues with the stlport library

[Chenyang <du...@gm...>]

Hi Guys,

An issue with the stlport library has been found. The string conversion to
long long or short does not have the expected behavior.

Below are two simple example programs:

Simple 1, issue related to short:
---------------------------------------------------------------------------------

The patch works fine for long long long/int but not for short.

#include <iostream>
#include <limits>
#include <sstream>
#include <string>

using namespace std;

int main(int argc, char **argv)
{
    cout << "This is the upper bound of short " <<
std::numeric_limits<short>::max() << endl;

    cout << "Now if I try to convert le above value +1 which is 32768" << endl;
    std::stringstream ss("32768");

    short result;
    ss >> result;

    cout << "It should fail..." << endl;

    if (ss.eof() && !ss.fail() && !ss.bad())
        cout << "  but it does not..." << result << endl;

    if (result == std::numeric_limits<short>::min())
        cout << "    And result is now min." << endl;

    return 0;
}

gives :
This is the upper bound of short 32767
Now if I try to convert le above value +1 which is 32768
It should fail...
  but it does not...-32768
    And result is now min.


Simple 2, issue related to long long:
---------------------------------------------------------------------------------

#include <iostream>
#include <limits>
#include <sstream>
#include <string>

using namespace std;

int main(int argc, char **argv)
{
    cout << "This is the upper bound of long long " <<
std::numeric_limits<long long>::max() << endl;

    cout << "Now if I try to convert the above value +1 which is
9223372036854775808" << endl;
    std::stringstream ss("9223372036854775808");

    long long result;
    ss >> result;

    cout << "It should fail..." << endl;

    if (ss.eof() && !ss.fail() && !ss.bad())
        cout << "  but it does not..." << result << endl;

    if (result == std::numeric_limits<long long>::min())
        cout << "    And result is now min." << endl;

    return 0;
}

If you compile this and run it on the board, you get the following output:

This is the upper bound of long long 9223372036854775807
Now if I try to convert the above value +1 which is 9223372036854775808
It should fail...
  but it does not...-9223372036854775808
    And result is now min.

This behaviour is wrong as the conversion ss>> result should fail.

You may test this on your linux machine, the result is correct.

You may also notice that I have some similar issue with long (instead
of long long)

Note that if you try to convert the max value +2, the conversion fails
(looks like a off by one somewhere).



-- 
Chenyang

Re: [Stlport-devel] delete item when iterating collection

[Petr O. <pt...@vo...>]

On Fri, 18 Nov 2011 04:24:43 +0000
Спиридонов Александр <spi...@ma...> wrote:

> No, I didn't take risk accessing old iterators after erase().
> In this thread, I wanted to ask, is there a generic rule: which containers do not invalidate
> iterators after erase (like map), and which do (like vector)

commit a90826947f9ef4aec1be8f90571ac00e298e01c1
Author: Petr Ovtchenkov <pt...@vo...>
Date:   Mon May 24 20:02:54 2010 +0400

    Unordered containers: shouldn't rehash on erase
    
    <snip>
    The insert members shall not affect the validity of references
    to container elements, but may invalidate all iterators
    to the container. The erase members shall invalidate only
    iterators and references to the erased elements.
    </snip>
    
    Rationale: if we would rehash on erase, we can't use
    remove_if() for unordered containers.
    
    Let's try to reduce amount of buckets on resize/rehash.

commit aea2f0b5d69bf808138bce6a29a8dc5993a0b832
Author: Petr Ovtchenkov <pt...@vo...>
Date:   Fri May 21 13:27:03 2010 +0400

    Fix tests: unordered containers are fine
    
    <snip>
    The elements of an unordered associative container
    are organized into buckets. Keys with the same hash
    code appear in the same bucket. The number of buckets
    is automatically increased as elements are added
    to an unordered associative container, so that
    the average number of elements per bucket is kept below
    a bound. Rehashing invalidates iterators, changes
    ordering between elements, and changes which buckets
    elements appear in, but does not invalidate pointers
    or references to elements. For unordered_multiset
    and unordered_multimap, rehashing preserves the relative
    ordering of equivalent elements.
    </snip>

commit 8a1d2cc87e0fd2a14ecabf5cb4ea8a41a0f8e59f
Author: Petr Ovtchenkov <pt...@vo...>
Date:   Fri May 21 10:48:11 2010 +0400

    Unit tests, demonstrate bug in unordered containers
    
    Traverse through unordered container (hash_map and
    unordered_map checked) with erasing elements don't
    erase all elements, but should.



commit b57ec7c58537972e43cbc07d4cd567026ba56e85
Author: Alexander Solganik <sol...@gm...>
Date:   Tue Jun 14 23:50:15 2011 +0300

    Unordered containers: shouldn't rehash on erase
    
    <snip>
    The insert members shall not affect the validity of references
    to container elements, but may invalidate all iterators
    to the container. The erase members shall invalidate only
    iterators and references to the erased elements.
    </snip>
    
    Rationale: if we would rehash on erase, we can't use
    remove_if() for unordered containers.
    
    Let's try to reduce amount of buckets on resize/rehash.


> 
> 
> -----Original Message-----
> From: Petr Ovtchenkov [mailto:pt...@vo...] 
> Sent: Friday, November 18, 2011 8:12 AM
> To: stl...@li...
> Subject: Re: [Stlport-devel] delete item when iterating collection
> 
> I suspect you mean issue
> http://sourceforge.net/tracker/?func=detail&aid=3004998&group_id=146814&atid=766244
> 
> Commit b57ec7c585 in STLport-5.2 branch. In mainstream it was much before, see 8a1d2cc8,
> aea2f0b5d, 90826947.
> 

Re: [Stlport-devel] delete item when iterating collection

[Petr O. <pt...@vo...>]

On Thu, 17 Nov 2011 19:07:38 +0000
Спиридонов Александр <spi...@ma...> wrote:

> Consider this example:
> 
> typedef unordered_map<int,User*> Map;
> 
> #ifdef _STLPORT_VERSION
> re:
> #endif
>         for (Map::iterator i = users.begin(); i != users.end();) {
>                 if (i->second->isDisconnected ()) {
> #ifdef _STLPORT_VERSION
>                         users.erase(i);
>                         goto re;
> #else
>                         i = users.erase(i);
> #endif
>                 } else {
>                         ++i;
>                 }
>         }
> 
> MSVC STL is more effective, then STLport.
> Is there a better solution?

I suspect you mean issue
http://sourceforge.net/tracker/?func=detail&aid=3004998&group_id=146814&atid=766244

Commit b57ec7c585 in STLport-5.2 branch. In mainstream it was much before,
see 8a1d2cc8, aea2f0b5d, 90826947.


--

  - ptr

Re: [Stlport-devel] delete item when iterating collection

[Nigel S. <nst...@nv...>]

> Is there a better solution?

Yes:

typedef unordered_map<int,User*>  Map;

for (Map::iterator i = users.begin(); i != users.end();) {
   if (i->second->isDisconnected ()) {
     Map::iterator j = i;
     ++i;
     users.erase(j);
   } else {
     ++i;
   }

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

[Stlport-devel] delete item when iterating collection

[Спиридонов А. <spi...@ma...>]

Consider this example:

typedef unordered_map<int,User*> Map;

#ifdef _STLPORT_VERSION
re:
#endif
        for (Map::iterator i = users.begin(); i != users.end();) {
                if (i->second->isDisconnected ()) {
#ifdef _STLPORT_VERSION
                        users.erase(i);
                        goto re;
#else
                        i = users.erase(i);
#endif
                } else {
                        ++i;
                }
        }

MSVC STL is more effective, then STLport.
Is there a better solution?

Re: [Stlport-devel] [patch] support uncaught_exception with Intel compiler on Windows

[Petr O. <pt...@vo...>]

On Tue, 15 Nov 2011 11:52:56 -0500
Daniel Faken wrote:

> Hello,
> 
>    Due to the way it was implemented (in the 'Fix _STLP_MSVC definition' 
> patch by dums on 2006-03-16), uncaught_exception() is disabled when 
> compiling with ICL.
> 
>    Attached is a simple patch (for stlport 5.2.1) to reenable it.
>    This is only needed on MSWindows (intel compiler on linux uses 
> config/_icc.h instead of config/_msvc.h).
> 

Committed in STLport-5.2 branch.

--

   - ptr

[Stlport-devel] [patch] support uncaught_exception with Intel compiler on Windows

[Daniel F. <df...@co...>]

Hello,

   Due to the way it was implemented (in the 'Fix _STLP_MSVC definition' 
patch by dums on 2006-03-16), uncaught_exception() is disabled when 
compiling with ICL.

   Attached is a simple patch (for stlport 5.2.1) to reenable it.
   This is only needed on MSWindows (intel compiler on linux uses 
config/_icc.h instead of config/_msvc.h).

thanks,
Daniel Faken
Coventor Inc.

Re: [Stlport-devel] ARM toolchain support for STLport-5.2

[Nigel S. <nst...@nv...>]

>> On this occasion I would like to ask, do you have any concrete plans for
>> 5.2.x line? You've mentioned before that it might be still be alive.
>
> 5.2 line open for patches/platform support within standard 2003.

Wojciech,

I expect 5.2 to be around for a while, one way or another.
In a multi-platform context, making the leap to C++0x
is going to be a lot of (as yet unscheduled) work.

- Nigel

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

Re: [Stlport-devel] ARM toolchain support for STLport-5.2

[Petr O. <pt...@vo...>]

On Wed, 9 Mar 2011 11:26:38 -0000
"Wojciech Meyer" <Woj...@ar...> wrote:

> ...
> On this occasion I would like to ask, do you have any concrete plans for
> 5.2.x line? You've mentioned before that it might be still be alive.
> 

5.2 line open for patches/platform support within standard 2003.

I don't expect that as C++0x constructions will appear here as significant
architecture changes.

--

Bests,

  - Petr

Re: [Stlport-devel] ARM toolchain support for STLport-5.2

[Wojciech M. <Woj...@ar...>]

> Done.

Thanks. Now it works.

On this occasion I would like to ask, do you have any concrete plans for
5.2.x
line? You've mentioned before that it might be still be alive.

Thanks,
Wojciech

Re: [Stlport-devel] ARM toolchain support for STLport-5.2

[Petr O. <pt...@vo...>]

On Wed, 9 Mar 2011 10:20:22 -0000
"Wojciech Meyer" <Woj...@ar...> wrote:

> 
> ...
> I pulled latest changes and noticed that one armcc.mak build file is
> missing (probably got missed somewhere when I was preparing the patch),
> sorry about this. Please apply the attached patch to fix this single
> problem. After this, I was able to build STLport and run the unit tests
> with the ARM toolchain. Apologises for any inconvenience.
> 

Done.

--

Bests,

   - Petr

Re: [Stlport-devel] ARM toolchain support for STLport-5.2

[Wojciech M. <Woj...@ar...>]

> In STLport-5.2 branch, 773d1982. I made little change only in commit
notes.
> Thanks for you contribution!

Thanks for being able to contribute to STLport!

I pulled latest changes and noticed that one armcc.mak build file is
missing (probably got missed somewhere when I was preparing the patch),
sorry about this. Please apply the attached patch to fix this single
problem. After this, I was able to build STLport and run the unit tests
with the ARM toolchain. Apologises for any inconvenience.

Thanks,
Wojciech

Re: [Stlport-devel] ARM toolchain support for STLport-5.2

[Petr O. <pt...@vo...>]

On Tue, 8 Mar 2011 14:10:09 -0000
"Wojciech Meyer" <Woj...@ar...> wrote:

> ...
> Please see the corrected commit notes and let me know if you are happy with
> it.
> 

In STLport-5.2 branch, 773d1982. I made little change only in commit notes.
Thanks for you contribution!

--

Bests,

  - Petr

Re: [Stlport-devel] ARM toolchain support for STLport-5.2

[Wojciech M. <Woj...@ar...>]

Hi Petr,

> Why you comment this (build/test/unit/armcc.mak):

> +#-include ${SRCROOT}/Makefiles/gmake/config.mak

> ?

This has been fixed!

> I don't see stl/config/_armgcc.h, but see

> +#  elif defined ( __ARMCC_VERSION) && defined(_GNU_SOURCE)
> +#    include <stl/config/_armgcc.h>
> +#  elif defined ( __ARMCC_VERSION) 
> +#    include <stl/config/_armcc.h>

This as well.

> Patch should contain 'commit notes', i.e. description of this commit
> (see 'git log' under STLport-5.2 branch, for example).

Please see the corrected commit notes and let me know if you are happy with
it.

Thanks!
Wojciech