Maya and Standard Library arrays article [updated - again - with a part 3/3]

#1

Was sort of undecided whether to post or not as we normally don’t like self promotion of websites, but it’s not like I can post this in the 3D gallery or I make a single cent out of my once-a-year updated websites, or this forum is likely to pull million hit impressions :wink:

Some ramblings and recipes for Standard containers in Maya
http://www.thejaco.com/wp/convert-maya-arrays-stl-containers/

Will probably post more in the following weeks; easiest way to keep up to date with what I do there is usually to follow me on Twitter as @ThE_JacO

#2

Thanks for sharing, interesting article.

#3

Part two introducing the Maya version of a practical application is up
http://www.thejaco.com/wp/maya-stl-deep-connected-vertices/

#4

ThE_JacO,

thank you very much for the incredible expenditure of time you invest in sharing your knowledge with the community. Since Rob obviously is gone, I don`t know anyone with such a huge knowledge and such detailed explanations.

topic change:
funnily, a STL problem (visual studio) made me nuts the last days. And just 30 minutes ago, I finally found the reason after a real long search…
For reasons I cannot remember, some month ago I had to set the iterator-debugging to zero in one of my projects.

_HAS_ITERATOR_DEBUGGING = 0

Last week, for my plugin I created a class with another nested class. The nested class had as a member variable the object of a third class. Then, the parent class created as a member variable a vector with the nested class.
That result was that the vector was initially not empty but had a huge size. Any attempt to change the size or access its data made Maya freeze.
Only after deletion of the preprocessor definition the vector behaved normally again.
I have no idea if thats a stl bug, but now its clear thats not a good idea to fool around with _HAS_ITERATOR_DEBUGGING …

#5

Thanks for the compliment. When I have time to kill I genuinely enjoy writing, so I don’t mind occasionally posting an article or an involve post here and there.

On the other note:
Compilers and library implementations have bugs, issues, limitations and idiosyncrasies like any other software.
I.E. for years now the standard library coming with visual studio has a flawed chrono implementation that make the high frequency clock pointless as it doesn’t use the appropriate system facilities, rendering it non-precise, possibly non-steady, and with an incredibly uncertain overhead, basically everything an HF clock shouldn’t be :slight_smile:
Thankfully it will be fixed in VS2015 (already is in the tech preview I think).

In your case iterator debugging, like quite a few other VC specific variables, is proprietary to VC.
I also bumped into a related issue with boost some time ago that came down to an actual bug in VC10. It was a while ago, but from a quick search I think it was this:
https://connect.microsoft.com/VisualStudio/feedback/details/640602/vs2010-debugger-watching-std-string-with-iterator-debug-level-0-does-not-work

Also remember that there is a considerable difference between debug and release modes, debug has a lot of added symbols and guards, and it’s possible to see odd behaviours in release that didn’t even error in debug (especially with race conditions), and, a lot more rarely, the other way around.
If your software works with a debugging flag on, but not with the same off, I would be seriously concerned and would look further into it. It’s possible one of the debug guards such a range check is the only thing standing between you and some killer undefined behavior causing your bug. Have you actually tried turning it off and running it in debug mode? VS’s debugger, for all the evils of MS, is actually pretty damn good.

You can find bug reports on msdn.
While it’s usually safe to assume you are doing something wrong rather than the compiler when you’re not an extremely knowledgeable expert of the platform (I make that assumption myself, especially on Windows), if something is really non-sensical and persistent for a long time DO start looking for bugs in the API or the compiler. Some times they do happen, and some are pretty big. I have wasted hours to days some times because of obscure bugs that ended up being in Maya or in VC. Less so on GCC.

#6

Not sure I understand you correctly.
So, what I did was to run the plugin solely in debug mode with

_HAS_ITERATOR_DEBUGGING=0

At the beginning of my search for the error, visual studio pointed me to the vectors resize function (which I called in the plugin and was sure this actually cannot be the reason for the error…), but now it notoriously points me to the end of the function in which I call the vectors resize, so I cannot replicate that.
BTW,

_ITERATOR_DEBUG_LEVEL=0

is the successor of

_HAS_ITERATOR_DEBUGGING=0

and its usage results also in the same error.

#7

I might be getting confused…
If you run in debug mode with iterator debugging off you have issues with the vector allocator (which might be buggy but somewhat plausible behaviour as far bugs go), but what happens to the same code in release mode? And does the same code work in either or both release or debug mode if you remove the flag?

As for my question I was asking if you had tried running your plugin (assuming it’s one) with the debugger active and attached to Maya and see what you get in the stack and in watch if you have a breakpoint around where you suspect the issue arises, and a watch on that vector.

It’s also possible VC simply craps itself in debug mode if only that debugging feature is turned off in isolation, I usually simply let all the flags on and abuse breakpoints when I use the debugger.

#8

Yes.

_HAS_ITERATOR_DEBUGGING=0

is ignored in release mode. But as the compilation under release mode takes more than hour I never checked that (the relevant node runs fine when in debug mode and its under permanent development, so testing release mode was never an option until it will be really final).
I tested it yesterday and there is no issue with that preprocessor definition in release mode.

Release is obviously always fine and debug only works with the flag turned on.
When the flag is removed, the compiler automatically assumes:

_HAS_ITERATOR_DEBUGGING=1

Yes, I did that. The debugger stops when the vector asks itself for its current size:

size_type size() const _NOEXCEPT
{	// return length of sequence
return (this->_Mylast - this->_Myfirst);
}

And when it was my code that asked for the vectors size, I got answers like : 83473629485734 or similar values

#9

Seems like either a legit bug then, which you scour MSDN for or report if you can’t find it, or an interaction between flags missing or behaving oddly.

#10

It was raining, I was bored, I wrote part 3
http://www.thejaco.com/wp/maya-stl-connected-vertices-done-right/

Mildly useful this time.