Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • bob bob
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 3
    • Issues 3
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • bobbob
  • bobbob
  • Issues
  • #42
Closed
Open
Issue created Mar 28, 2012 by André Anjos@andre.anjos💬Owner

No range check of std::vector in DEBUG mode

Created by: siebenkopf

In the current version of Bob, there is no range check on the std::vector::operator [] and no sanity checks for std::...iterator's. Unfortunately, the proposed method for GnuCC, i.e., adding the compiler flag "-D_GLIBCXX_DEBUG" interferes with:

  • some functionalities of Boost, like the boost::program_options
  • also Boost.Python seems to be affected
  • the -DBZ_DEBUG flag to enable range checking in blitz::Arrays also seems to affect this (not sure) by adding C++ linking errors.

The proposed solutions on the internet suggest to compile boost (and blitz) with the -D_GLIBCXX_DEBUG. Unfortunately, this would require to ship the compiled versions of boost (and blitz) with Bob.

A workaround for at least the indexing check would be to used the std:: vector::at(i) function instead, which does the range checking. Unfortunately, the range check is not disabled in release mode. This could be solved by: #ifndef DEBUG #define at(x) operator #endif (another solution I found in the net), but this of course would influence ALL at() functions...

Another workaround (which we had in our old software system) is to use our own derived class from the std::vector that actually does the range check (only in debug mode) and calls the operator::[] of the std::vector. Unfortunately, this is very ugly since it requires to re-write (at least) all constructors of the std::vector.

Assignee
Assign to
Time tracking