By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,898 Members | 2,022 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,898 IT Pros & Developers. It's quick & easy.

std::vector range check

P: n/a
mk
I will have 2 build types of my program: debug and release. In debug
build I want std::vector indexing operation (operator[] or at()) to do
a range-check. In release build I don't want it.

What is the easiest way to achieve that?

I currently have couple solutions, each one with drawbacks:

1. each time I change a build, search-and-replace in whole code
vector::operator[] with at() or vice-versa (this is not really a
solution of course)

2. derive a class from std::vector and override operator[] to do what
I need based on DEBUG macro.

This has a drawback of using non-standard class name (e.g. Vector)
that can potentially confuse future maintainers of the program.
Additionally, operator[] is not virtual, so overriding it is not
entirely safe, as the old one can be invoked accidentally under some
circumstances.

cheers,
Marcin Kalicinski
Jul 23 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
"mk" <ka****@poczta.onet.pl> wrote in message
news:4d**************************@posting.google.c om
I will have 2 build types of my program: debug and release. In debug
build I want std::vector indexing operation (operator[] or at()) to do
a range-check. In release build I don't want it.

What is the easiest way to achieve that?

I currently have couple solutions, each one with drawbacks:

1. each time I change a build, search-and-replace in whole code
vector::operator[] with at() or vice-versa (this is not really a
solution of course)

2. derive a class from std::vector and override operator[] to do what
I need based on DEBUG macro.

This has a drawback of using non-standard class name (e.g. Vector)
that can potentially confuse future maintainers of the program.
Additionally, operator[] is not virtual, so overriding it is not
entirely safe, as the old one can be invoked accidentally under some
circumstances.

cheers,
Marcin Kalicinski

How about:

#ifdef _DEBUG
#define at(x) at(x)
#else
#define at(x) operator[](x)
#endif
--
John Carson
Jul 23 '05 #2

P: n/a
"mk" <ka****@poczta.onet.pl> wrote in message
news:4d**************************@posting.google.c om...
:I will have 2 build types of my program: debug and release. In debug
: build I want std::vector indexing operation (operator[] or at()) to do
: a range-check. In release build I don't want it.
:
: What is the easiest way to achieve that?
Use a non-member function that does what you want.
Something like [just typing on-the-fly]:
template<class C>
C::reference at(C& container, C::size_type index)
{
#ifdef NDEBUG
return container[index];
#else
return container.at(index);
#endif
}
// and a const version as well...

: I currently have couple solutions, each one with drawbacks:
:
: 1. each time I change a build, search-and-replace in whole code
: vector::operator[] with at() or vice-versa (this is not really a
: solution of course)
Not a reasonable option.

: 2. derive a class from std::vector and override operator[] to do what
: I need based on DEBUG macro.
Not a good idea either. Only create a new class when you have
new data members or new invariants to enforce.

Regards,
Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
Jul 23 '05 #3

P: n/a
>I will have 2 build types of my program: debug and release. In debug
build I want std::vector indexing operation (operator[] or at()) to do
a range-check. In release build I don't want it.

What is the easiest way to achieve that?


Preprocessor Macros are frowned on as a whole but I use the following for
vector and deque:

#if defined(_DEBUG)
#define AT(x) at(x)
#else
#define AT(x) operator[](x)
#endif

and then have something like

std::vector<int> v;
// later
int i = v.AT(0);

You can still use [] if you know you have checked the size() (or .at() if
not)

Stephen Howe
Jul 23 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.