Skip to content

Conversation

@ahmedcharles
Copy link
Contributor

concept_def.hpp and concept_undef.hpp need to be matched when used.

jewillco and others added 30 commits October 20, 2011 21:32
[SVN r75863]
…_graph; changed name of member to prevent future use

[SVN r76049]
jewillco and others added 22 commits September 12, 2013 15:14
…n-partial-specialization compilers; enabled C++11 unordered containers when they are present; refs #8962

[SVN r86137]
Process #ifdef...#endif blocks.

[SVN r86243]
Process #ifndef...#endif conditions.

[SVN r86244]
Process #ifndef...#else...#endif blocks.

[SVN r86245]
… on callback usage to match current documentation); removed special-casing of empty graphs; added patch from #9246 for correct return values; did not make change to documentation suggested there since I chose to have the callback called even for empty graphs; fixes #9246

[SVN r86336]
…ap directories and namespaces; this fixes circular dependencies between these two libraries (assuming boost/property_map/parallel is treated as a separate library)

[SVN r86381]
@ahmedcharles
Copy link
Contributor Author

I should've submitted this against the develop branch, sorry.

concept_def.hpp and concept_undef.hpp need to be matched when used.
@ahmedcharles
Copy link
Contributor Author

Closing in favor of the request against develop.

@ahmedcharles ahmedcharles deleted the patch-1 branch February 8, 2017 11:10
felix-salfelder referenced this pull request in felix-salfelder/graph Feb 28, 2017
removing an element from a stack does not always work, since the
predecessor of a stack element is not (always) stored. this patch
merges the array head into next, so a top element in a stack can point
to the head of the stack it is in.

remarks:
- i am guessing the intended use (see test below), as it works like that
  for elements deeper down in a stack
- the fix abuses pointers/iterators and infers offsets from address
  differences. (yes it's a bit ugly.)
- memory needs and complexity are unaffected, size_type is probably big
  enough.

test case. B is a bucketsorter operating on a vector V.

 V[0]=0;
 V[1]=1;
 B.push(0);
 B.push(1);

// now, stacks 0 and 1 are singletons.
// try to move 0 to stack #1, should result in
// head_1->0->1->end, but calls remove first, then

 V[0]=1;
 B.update(0); // <- BOOM

// the update calls remove, it "removes" 0 from stack #V[0]=1.
// it's not there yet (!).
// instead 1 (top of bucket #1) must die.
// the result is head_1->0->end, and wrong.
felix-salfelder referenced this pull request in felix-salfelder/graph Aug 31, 2018
removing an element from a stack does not always work, since the
predecessor of a stack element is not (always) stored. this patch
merges the array head into next, so a top element in a stack can point
to the head of the stack it is in.

remarks:
- i am guessing the intended use (see test below), as it works like that
  for elements deeper down in a stack
- the fix abuses pointers/iterators and infers offsets from address
  differences. (yes it's a bit ugly.)
- memory needs and complexity are unaffected, size_type is probably big
  enough.

test case. B is a bucketsorter operating on a vector V.

 V[0]=0;
 V[1]=1;
 B.push(0);
 B.push(1);

// now, stacks 0 and 1 are singletons.
// try to move 0 to stack #1, should result in
// head_1->0->1->end, but calls remove first, then

 V[0]=1;
 B.update(0); // <- BOOM

// the update calls remove, it "removes" 0 from stack #V[0]=1.
// it's not there yet (!).
// instead 1 (top of bucket #1) must die.
// the result is head_1->0->end, and wrong.
jzmaddock pushed a commit that referenced this pull request Oct 12, 2018
Creating first batch merge to bring in well formed bugfixing pull requests.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants