search for: _has_iterator_debugging

...Wendling wrote: > On Dec 30, 2008, at 4:51 PM, srs wrote: > > >> 2. There seems to be an issue in ScheduleDAGSDNodes.h when in debug >> mode. The problem is the evaluation of "&SUnits[0];" which ASSERT's in >> VC++'s vector[] implementation (when _HAS_ITERATOR_DEBUGGING is on). >> >> As a work-around, I commented out the debug code (see "patch" below.) >> >> What would the proper solution be? The idiom appears to be allowed by >> the C++03 standard, but at least VC++ 2008 Express Edition with >> _HAS_ITERATOR_DEBUGGING...

...2008, at 4:51 PM, srs wrote: >> >> >>> 2. There seems to be an issue in ScheduleDAGSDNodes.h when in debug >>> mode. The problem is the evaluation of "&SUnits[0];" which >>> ASSERT's in >>> VC++'s vector[] implementation (when _HAS_ITERATOR_DEBUGGING is on). >>> >>> As a work-around, I commented out the debug code (see "patch" >>> below.) >>> >>> What would the proper solution be? The idiom appears to be allowed >>> by >>> the C++03 standard, but at least VC++ 2008 Exp...

...tion). I would have thought that linking with LLVMJIT.lib should suffice... a VC++ linker issue? 2. There seems to be an issue in ScheduleDAGSDNodes.h when in debug mode. The problem is the evaluation of "&SUnits[0];" which ASSERT's in VC++'s vector[] implementation (when _HAS_ITERATOR_DEBUGGING is on). As a work-around, I commented out the debug code (see "patch" below.) What would the proper solution be? The idiom appears to be allowed by the C++03 standard, but at least VC++ 2008 Express Edition with _HAS_ITERATOR_DEBUGGING fails. Best regards, Stein Roger Index: includ...

On Dec 30, 2008, at 4:51 PM, srs wrote: > 2. There seems to be an issue in ScheduleDAGSDNodes.h when in debug > mode. The problem is the evaluation of "&SUnits[0];" which ASSERT's in > VC++'s vector[] implementation (when _HAS_ITERATOR_DEBUGGING is on). > > As a work-around, I commented out the debug code (see "patch" below.) > > What would the proper solution be? The idiom appears to be allowed by > the C++03 standard, but at least VC++ 2008 Express Edition with > _HAS_ITERATOR_DEBUGGING fails. > What is the...

...gt;>> >>> >>>> 2. There seems to be an issue in ScheduleDAGSDNodes.h when in debug >>>> mode. The problem is the evaluation of "&SUnits[0];" which >>>> ASSERT's in >>>> VC++'s vector[] implementation (when _HAS_ITERATOR_DEBUGGING is on). >>>> >>>> As a work-around, I commented out the debug code (see "patch" >>>> below.) >>>> >>>> What would the proper solution be? The idiom appears to be allowed >>>> by >>>> the C++03 standard...

...information. :) For note, this is my usual line I add to the end of my preprocessor definitions in *every* single project I ever open now (thanks to some very bad memories associated with not having them). ;_CRT_NONSTDC_NO_DEPRECATE;_CRT_SECURE_NO_DEPRECATE;_SECURE_SCL=0;_SCL_SECURE_NO_DEPRECATE;_HAS_ITERATOR_DEBUGGING=0 Most of those will be obvious, but as stated, both _SECURE_SCL and _HAS_ITERATOR_DEBUGGING (especially this last one, you can 'sometimes' get by with linking on just _SECURE_SCL, but not with _HAS_ITERATOR_DEBUGGING for some forsaken reason) will cause very nasty and horrible crashes if...

"Cory Nelson" <phrosty at gmail.com> writes: > On Mon, Nov 24, 2008 at 8:18 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: >> OvermindDL1 <overminddl1 at gmail.com> writes: >>> As long as instructions are supplied on how to pass in user defined >>> macros to the build system. I have to turn off a lot of the extra >>> safety crap that

...gt;> built no other configurations beyond debug). > > Your INCLUDE and LIB environment variables contains lots of stuff that > may be interfering with the build. Please try after removing all > third-party libraries from those variables. > > You can try removing _SECURE_SCL and _HAS_ITERATOR_DEBUGGING from the > defines too. You define them to 0, which may be not a good idea, as that > produces different results depending on how you test the variable (with > #ifdef or with #if). I finally got some time to where I could delve into things. First, let me say it had nothing to do with my...

I did some looking up on that const thing. Apparently that const is 'supposed' to be there, but it is not strictly required. However there is a bug in VS2k3 (VS7) through VS2k8 (VS9) (no clue if it has been fixed yet) that requires it to be there when the functor is being called through a const qualified interface, such as through stl containers. They state that a bug report has been