Binary var issue


#1

when you write a value-tree stream, and there is a 0-size MemoryBlock in it, you get an assertion when reading the stream

fix in juce_Variant.cpp:

 case varMarker_Binary:
            {
				  MemoryBlock mb (numBytes - 1);
				  if (numBytes>1)   // new!!!!!!!
				  {
				  	const int numRead = input.read (mb.getData(), numBytes - 1);
				  	mb.setSize (numRead);
				  };
	            return var (mb);
            }

#2

Good one, thanks!


#3

It would be neat to have a “MemoryBlock var::toMemoryBlock()” function and it would be better!!! to remove getBinaryData()

why?

If you first look to this example, it looks alright, and it often works right
but in this case the compiler creates a temporary var() object because of “getProperty()” , which will be immediately deleted after the operator= operation. (And its Memoryblock too!)
The (funny) thing is, that it still sometimes work, because the part of heap-memory isn’t overwritten yet, when its used.

MemoryBlock* mb=request.getProperty(message::propParametersID,0).getBinaryData(); if (mb!=0) { // Do someting with *mb };


#4

Well… yes, but the same principle has always applied to the toArray() method too. I always use it like this:

[code]const var localCopy (foo.getProperty (“blah”));

if (const MemoryBlock* mb = localCopy.getBinaryData())
{

}
[/code]

I guess I could add something that returns a MemoryBlock by value, but it’d involve a whole unnecessary copy operation which could be expensive when you’re dealing with potentially large blocks of data.

I guess the ideal solution would be to have it return a temporary object which retains the original var and also acts as a memory block.


#5

I thought about a while, and come to the conclusion that there is no ideal solution.
But the current behavior is dangerous, because it sometimes work even if its wrong.

Things that could be done

  • use a function like “releaseBinaryData()” , but this would make it more confusing.
  • making HeapMemory reference-counted, but this would create overhead.
  • ValueTree::getPropertyBinarySource() …
    (the main mistake people have, that getProperty() doesn’t give a value reference to the “var()” Object inside the ValueTree, instead it creates a own temporary var(), so maybe we should make, if you want to get the BinaryData without copy, to make it only accessible via ValueTree or a Value-Reference)