Activity for STLplus C++ library collection
-
Andy Rushton committed [r701] on SVN stlplus3
tidied up C++ to HTML generator
-
tidied up C++ to HTML generator
-
tidied up C++ to HTML generator
-
should have been a bash script all along
-
minor typo
-
factored HTML generation function
-
Tidy up comments, remove reference to CVS directory
-
"test" command not necessarily in /bin/sh so just omit that
-
added build dependency on shared_library_test which should have been there all along
-
Retested on updated compilers
-
updated colourised headers
-
corrected the title of the monolithic stlplus3.hpp header
-
Tidy up and simlify the tables of platforms
-
Reran all the tests on nearly all the platforms
-
minor edits
-
added linking rules for all BSD variants
-
Added windows 11
-
updated colourised headers
-
updated all my test systems, did porting builds on all
-
Summary: Generated new IDE files for Visual Studio 2022
-
added library dependency on maths library on Linux
-
re-enabled deprecated warnings as they seem less common
-
Tested on a new gcc version
-
Oh, interesting, thanks for investigating this further, I've just learned something. It shows I'm a bit out of date (probably quite a lot) as I don't use C++ much anymore. At the time STLplus was developed you could not convert between iterator types, so this feature has been added more recently, though I've done a quick search but I haven't been able to find out when. It is now true that an iterator implicitly converts to a const_iterator in the STL, but STLplus does not do this. I approve in that...
-
EML posted a comment on discussion STLplus Development and Bugs
Hi Andy - I'm no expert on the STL, but this code does produce the expected (to me, anyway) output of 42, 43, 42: #include <vector> #include <iostream> int main() { std::vector<int> foo; std::vector<int>::const_iterator iter1; // a const_iterator can be used to traverse a non-const object: foo.push_back(42); foo.push_back(43); for(iter1 = foo.begin(); iter1 != foo.end(); ++iter1) std::cout << *iter1 << '\n'; // can assign an iterator to a const_iterator directly: std::vector<int>::iterator iter2...
-
You've misunderstood the use of iterator and const_iterator. The STLplus library copies the same conventions as the STL in its use of iterators. You use an iterator to traverse a data structure which is non-const and so modifiable, but a const_iterator when the data structure is const and so non-modifiable. In this instance, you have declared an ntree<foo> which is non-const so therefore you use an iterator to traverse it. The most common place where you use const_iterator is in a function that is...
-
You've misunderstood the use of iterator and const_iterator. The STLplus library copies the same conventions as the STL in its use of iterators. You use an iterator to traverse a data structure which is non-const and so modifiable, but a const_iterator when the data structure is const and so non-modifiable. In this instance, you have declared an ntree<foo> which is non-const so therefore you use an iterator to traverse it. The most common place where you use const_iterator is in a function that is...
-
This code doesn't compile, despite 'root' being overloaded to return both an iterator and a const_iterator: ntree<foo>bar; ntree<foo>::iterator iter = bar.root(); // Ok ntree<foo>::const_iterator iter = bar.root(); // not Ok Similarly, a conversion from an iterator to a const_iterator doesn't compile: ntree<foo>::iterator iter1 = bar.root(); ntree<foo>::const_iterator iter2 = iter1; Any ideas? Thanks.
-
I have discovered a problem with the Cygwin build of gcc which means that static builds don't link. This is not a problem with STLplus, it is a problem with the implementation of the STL library supplied with gcc. The symptom is a linker error, multiple definitions of a standard exception: /usr/src/debug/gcc-10.2.0-1/libstdc++-v3/src/c++11/cow-stdexcept.cc:63: multiple definition of `std::logic_error::logic_error(std::logic_error const&)'; ../../portability/CYGWIN-x86_64-debug/libportability.a(inf.o):/usr/lib/gcc/x86_64-pc-cygwin/10/include/c++/stdexcept:134:...
-
I have discovered a problem with the Cygwin build of gcc which means that static builds don't link. This is not a problem with STLplus, it is a problem with the implementation of the STL library supplied with gcc. The symptom is a linker error, multiple definitions of a standard exception: /usr/src/debug/gcc-10.2.0-1/libstdc++-v3/src/c++11/cow-stdexcept.cc:63: multiple definition of `std::logic_error::logic_error(std::logic_error const&)'; ../../portability/CYGWIN-x86_64-debug/libportability.a(inf.o):/usr/lib/gcc/x86_64-pc-cygwin/10/include/c++/stdexcept:134:...
-
Sorry for the delay, I didn't get a notification of this post (weird). I have no intention of supporting unique_ptr in any of the STLplus data structures. Using a unique_ptr in any data structure (not just STLplus but also STL) does not make sense because any read operation accessing the data will cause an assignment of the pointer type, leaving the pointer in the data structure null. It seems to me that any work round for this 'problem' is an admission that you have used the wrong pointer type.
-
updated with results from gcc v10
-
John Lagerquist modified a comment on discussion STLplus Development and Bugs
Are there any thoughts on adding support to allow using std::unique_ptr for node and edge data? ie digraph<std::unique_ptr<foo>>, std::unique_ptr<bar>>
-
Are there any thoughts on adding support to allow using std::unique_ptr for node and edge data? ie digraph<std::unique_ptr<foo>>, std::unique_ptr<bar>></bar></std::unique_ptr<foo>
-
Summary: Quick build test after apgrades to compilers, gcc v9 build
-
Evgeny Pokhilko posted a comment on discussion STLplus Development and Bugs
Hi Andy, I have made a simple tool for testing the modified functions: https://sourceforge.net/p/stlplus-testing/code/ci/master/tree/ There is a bash script called start.sh that will invoke the functions and make some preparations. This is work in progress. I will probably improve the tool going forward and run it on more platforms myself. This is a start. BTW I made my best not to change the behaviour and underlying code for all platforms except Windows. So a code review and more testing on Windows...
-
Andy Rushton posted a comment on discussion STLplus Development and Bugs
Hi, I did understand your point, I was saying that I would have solved the problem a similar way. However, a proof of concept would not be suitable for the stlplus library which is a mature project now. So any software that goes into it should be production quality. Also, it would need to have a test program that works on all platforms to confirm the portability requirements have been met. I will have another look at this in a few weeks when I have time to see if the proof of concept could be included...
-
Hi Andi, Sorry I was a bit unclear in my message. It was late at night when I wrote it. Replying to your paragraphs in order: I actually went ahead and made proof of concept changes in file_system.cpp (see the link in my message above). My code does exactly what you recommend. It retains the interface and converts from UTF-8 to UTF-16 and back. I made the listed functions work with UTF-16. Please look at them. more concrete line number link to is_folder: https://github.com/evpo/EncryptPad/blob/93f524e3ff9556067491697aef34a201474945cf/deps/stlplus/portability/file_system.cpp#L527...
-
Hi Evgeny, this is how I would do it - the interface must be the same on all platforms and the sensible choice is UTF8-encoding to use a std::string interface. Therefore, on Windows it would be necessary to convert to and from the native UTF16 encoding of Windows. What I'm not sure about is if everything internally would still work, because paths are dissected on the assumption that the string contains one-byte characters. There is no allowance for multi-byte sequences and it isn't completely clear...
-
Hello Andy, file_system.hpp: folder_exists, folder_create, folder_home, install_path I consider using the listed functions on Windows for names that require UTF16. Here is an example of such name in a different context: https://github.com/evpo/EncryptPad/issues/44 Operating with these names can be done on Linux because we can use std::string for storing UTF8, which Linux supports. However, on Windows they are UTF16 that needs std::wstring. The conversion from UTF8 to UTF16 and back can be done on...
-
adjusting the linker options for building static images, need to be more precise with mingw-w64 under MSYS2
-
updating version after a release
-
increment version after release
-
long-obsolete sample shared libraries, now use shared_library_test
-
STLplus 3.15 released
-
Extra information about exception specifications
-
STLplus C++ library collection released /stlplus3/3.15/stlplus3-03-15.zip
-
-
Release tag stlplus3-03-15
-
-
-
Release tag makefiles-01-11
-
reorganise code so default compiler flags are now in platform.mak, reformat manual to new style
-
Fixed copyright
-
added changes for v3.15
-
just fixed indentation
-
updated to latest Win10 build
-
Retested on all platforms that I have access to
-
Slight changes to the links to Creative Commons
-
updated to match code
-
I was curious about why the standards committee would do this, so I did a bit more research. The rationale for this change is here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0174r1.html#2.1 It seems to make sense, the committee have recognised that typedefs are not inherited quite how you expect them to be, so using inheritance of std::iterator to define iterator traits doesn't work. The STL has worked round this for years. Presumably the problem is shown when using iterators in algorithms...
-
reworked iterators to fit with C++17 recommendations for specifying traits
-
obsolee header shoud have been deleted ages ago
-
Hi, thanks for alerting me to this. It seems a perverse decision by the standards committee, since it seems obvious to me that the best way to achieve this goal is inheritance. Saying "never required ... to derive" is fair enough, I knew that and early versions of the library didn't inherit from iterator, I added the inheritance later because of other changes. So now saying "not allowed to derive" is a crazy jump to make. I suspect it is to either work round compiler problems or to accommodate a...
-
Andreas Schniertshauer posted a comment on discussion STLplus Development and Bugs
The std::iterator class template (used as a base class to provide typedefs) is deprecated in C++17. (The <iterator> header is NOT deprecated.) The C++ Standard has never required user-defined iterators to derive from std::iterator. To fix this warning, stop deriving from std::iterator and start providing publicly accessible typedefs named iterator_category, value_type, difference_type, pointer, and reference. Note that value_type is required to be non-const, even for constant iterators. You can define...
-
Summary: Minor edit
-
Summary: Updated license to show equivalence with Creative Commons v4
-
Summary: Remove messages directory from release package
-
Summary: Tidied up documentation, brought up to date with recent
-
old subdirectory re-added by conversion from CVS to SVN, re-deleted it
-
Summary: Modified code samples to work better with a small screen -
-
Summary: Rewritten to describe the use of SVN instead of CVS
-
removed WINxx include dos.h - getting warnings this is obsolete and turns out it isn't used anymore
-
update of Visual Studio
-
Summary: Resolved confusing documentation which had two sections named
-
Summary: Include JavaScript files in package - these colourise source copies
-
Fixed markup error
-
Summary: Fix styling of h1 to be part of content
-
Summary: Fixed markup error
-
Updated porting testing dates and compiler versions
-
improved layout of lists, added a bit of highlight colour
-
removed all indentation from HTML code - this causes problems with e.g. empbedded code
-
improved layout of lists, added a bit of highlight colour
-
removed all indentation from HTML code - this causes problems with e.g. empbedded code
-
fixed viewport for better support of mobiles and small screens
-
fixed viewport for better support of mobiles and small screens
-
removing throw specifications from the code examples in the manual to match the code
-
Summary: Clarified change to throw specifications, retrospectively
-
Summary: Reword of theme and standardisation of headers and titles
-
rework of theme and standardisation of title/headings
-
Summary: Updated docs to state that clang is a viable alternative compiler
-
Summary: Updating to match source code
-
Summary: Minor edits to comments
-
Summary: Conversion to SVN has brought back in these obsolete files
-
reintroduced throw specifications on exceptions derived from system exceptions for backwards compatibility
-
added recognition of clang compiler
-
updated README with advice on accessing the SVN source
-
deleted accidentally added Visual Studio sln file
-
updated global ignores to ignore temporary and intermediate files
-
updated global ignores to ignore build folders
1 >
