Skip to content

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
    • Help
    • Support
    • Submit feedback
    • Contribute to GitLab
  • Sign in
bob
bob
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 3
    • Issues 3
    • List
    • Boards
    • Labels
    • Milestones
  • Merge Requests 0
    • Merge Requests 0
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • bob
  • bobbob
  • Issues
  • #42

Closed
Open
Opened Mar 28, 2012 by André Anjos@andre.anjos💬
  • Report abuse
  • New issue
Report abuse New issue

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
v1.1
Milestone
v1.1
Assign milestone
Time tracking
None
Due date
None
1
Labels
C++ Issues
Assign labels
  • View project labels
Reference: bob/bob#42