[Bug c++/106434] [12/13 Regression] Spurious -Wnull-dereference when using std::unique_copy() since r12-5187-g1ae8edf5f73ca5c3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106434 --- Comment #2 from Josh Marshall --- How involved should I be on this?
[Bug libstdc++/86188] Enhancement to std::merge, constexpr check of iterator types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86188 --- Comment #2 from Josh Marshall --- That looks similar enough. But I think the Bidirectional iterator tag in the case of sorting is expressive enough and for std::merge, either forward iterator tags or output iterator tags would express the desired characteristics suitably. If someone can't create an iterator without those needed tags but can create an iterator with the required characteristics I would be very surprised.
[Bug libstdc++/86188] New: Enhancement to std::merge, constexpr check of iterator types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86188 Bug ID: 86188 Summary: Enhancement to std::merge, constexpr check of iterator types Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: joshua.r.marshall.1991 at gmail dot com Target Milestone: --- Before I go in an submitting patches all willy-nilly, I've been poking at std::merge and I think I see that it could catch some programming bugs better with constexpr std::iterator_traits::iterator_category == <>. This looks simple, but there may also be a reason it hasn't been done.
[Bug libstdc++/86015] Better handling of iterator distances
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86015 --- Comment #15 from Josh Marshall --- That is bizarre. Then did I stumble upon the vestiges of elements of the standard which were partially removed prior to 2003? This may be open for awhile. I'll start on a proposal for 2020. I'll also have to get my hands on a proper standard.
[Bug libstdc++/86015] Better handling of iterator distances
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86015 --- Comment #12 from Josh Marshall --- I can now say why this bothers me from a design perspective. If the requirement you are giving is correct, then the distance_type template parameter must always be signed and always describe the distance between any two points in memory and therefore must be of the base type ssize_t. But if it must always resolve to this one specific type, it doesn't make sense to have it as a template parameterization. But having the more flexible definition and usage can start to allow for user applications to do instrumentation and crazy stuff like grid support through the stdlib one day. It wouldn't make sense to add the extra complexity to always use ssize_t, and so it doesn't make sense that difference_type must be a signed integer only. It doesn't fit with any source I've found, it doesn't explain the added complexity in the template, and it reduces flexibility and generalizability.
[Bug libstdc++/86015] Better handling of iterator distances
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86015 --- Comment #11 from Josh Marshall --- Then please give me a concrete reference.
[Bug libstdc++/86015] Better handling of iterator distances
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86015 --- Comment #9 from Josh Marshall --- Confirmed in 8.1.1 Also, looking over the following documents: https://en.cppreference.com/w/cpp/types/ptrdiff_t https://en.cppreference.com/w/cpp/iterator/iterator http://en.cppreference.com/w/cpp/iterator/advance http://en.cppreference.com/w/cpp/iterator/distance https://en.cppreference.com/w/cpp/concept/Iterator https://en.cppreference.com/w/cpp/iterator/iterator_traits All of these do not require difference_type (typename _Distance in glibc) to be convertible to an integer, and imply implicit conversion from an integer. From this reading, I need to change this from an enhancement to a bug. I also need to put in a request for a clarification to the standard on this, because it wasn't very apparent. Unfortunately, this involves the bigger change to glibc. Functions like __lg() will have to be re-written.
[Bug libstdc++/86015] Better handling of iterator distances
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86015 --- Comment #8 from Josh Marshall --- If this code is to work, given that this is the only way to track in detail use of various stdlib internals, one of two things need to change. Either all assignments to _Distance need to be explicitly wrapped and the constructor from a scalar make explicit with implicit conversion to an int, or implicit conversion from int without conversion to int and all uses of _Distance do not explicitly require a scalar but a set of operators which can be applied to a scalar be implemented by _Distance. I can quickly submit a patch for the first one, but I'm not sure it is the right approach. I'm going to ask this in the C++ standards forum tomorrow and maybe they'll have insight about changing the nature of std::ptrdiff_t.
[Bug libstdc++/86015] Better handling of iterator distances
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86015 --- Comment #7 from Josh Marshall --- I got the licensing cleared up over the weekend, and so I can actually reference the code in question for this. https://github.com/anadon/Sort-Comparisons-and-Performance-metrics The only way to track use of operations on iterator distances effectively would be for a change like this to go through. If deemed appropriate, I might ask about this change to the C++ standard since it won't break any existing code and adds flexibility.
[Bug libstdc++/86015] Better handling of iterator distances
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86015 --- Comment #6 from Josh Marshall --- There is a kind of legacy manual specification, and a reason for that was for tracking usage. What I'm working on is adapted from David Musser's 1997 code which was using proposed and developmental stdlib code. So this functionality was intended at one point, and there is some limited use in the greater functionality.
[Bug libstdc++/86015] Better handling of iterator distances
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86015 --- Comment #4 from Josh Marshall --- These changes may make the stdlib implementation more robust, but there may be an argument to stick to the more strict standard or tweak the standard. Could you link to the standard doc you're pulling from? I'm not expert enough to really figure if this report should be marked invalid or not.
[Bug c++/86015] Better handling of iterator distances
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86015 --- Comment #2 from Josh Marshall --- There are also lines close by which call std::distance() which need to be similarly wrapped.
[Bug c++/86015] Better handling of iterator distances
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86015 --- Comment #1 from Josh Marshall --- It looks like wrappings would be applicable at the following lines: 296, 297, 2438, 2439, 2494, 2495 using https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/stl_algo.h as reference.
[Bug c++/86015] New: Better handling of iterator distances
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86015 Bug ID: 86015 Summary: Better handling of iterator distances Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: joshua.r.marshall.1991 at gmail dot com Target Milestone: --- I'm writing containers for containers to track usage and operations for performance metrics. I've found it impossible to allow implicit conversion from integer types to a distance object without introducing conflicting resolutions for all basic math operations. It occasionally leads to errors like the following: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0/../../../../include/c++/7.3.0/bits/stl_algo.h:2495:17: error: no viable conversion from 'int' to 'distance_counter<__gnu_cxx::__normal_iterator > >, long>' _Distance __len22 = 0; In this instance, I think the best way to handle this is to change stl_algo.h:2495: _Distance __len22 = 0; to stl_algo.h:2495: _Distance __len22 = _Distance(0); Am I just doing something dumb, or is this reasonable?
[Bug c++/85763] Feature request: Add a suggestion when compilation fails dues to ambiguous templated friend function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85763 Josh Marshall changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID
[Bug c++/85763] Feature request: Add a suggestion when compilation fails dues to ambiguous templated friend function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85763 --- Comment #2 from Josh Marshall --- Created attachment 44143 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44143=edit Example file I got to making an example, but it seems that this is no longer a problem. I'm going to close this one out as invalid.
[Bug c++/85763] New: Feature request: Add a suggestion when compilation fails dues to ambiguous templated friend function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85763
Bug ID: 85763
Summary: Feature request: Add a suggestion when compilation
fails dues to ambiguous templated friend function
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: joshua.r.marshall.1991 at gmail dot com
Target Milestone: ---
For friend functions with template parameters, it would be nice to have the
structure relation of typename'd values in a template declaration used for
function matching rather than what appears to be a more string literal
comparison or to throw a warning and suggestion when this is detected. For
example, have the following functions match or throw a warning:
> class my_class{
> public:
> template
> friend void func(_T val);
> };
>
> template
> void func(T val)
> {
> ...
> }
It shows up as an ambiguous function definition, but one which seems very
help-able.
