Home » Developing U++ » U++ Developers corner » ASSERT when using ValueMap
Re: ASSERT when using ValueMap [message #47691 is a reply to message #47690] |
Tue, 07 March 2017 12:10 |
|
mirek
Messages: 13980 Registered: November 2005
|
Ultimate Member |
|
|
NilaT wrote on Tue, 07 March 2017 11:54cbpporterLong story short, Value/ValueMap is not debug-able. Period.
mirek it is simply the fact that Value code is immensely complicated. Really, absolutely totally fucked hard.
This may be the most accurate description about U++ ever made!
Well, I believe not the whole U++. Just this piece of code.
Quote:
but it's not documented.
To be fair, there is shitload of related documentation and examples:
http://www.ultimatepp.org/src$Core$Value$en-us.html
even reading the first couple of senteces would save you a lot of troubles.
http://www.ultimatepp.org/srcdoc$Core$Tutorial$en-us.html
chapter 4 explains everything related to Value.
http://www.ultimatepp.org/reference$JSON$en-us.html
here is how to work with JSON...
I would sort of say that there is perception that documentation is completely missing which was true 5 years ago. Nowadays, there definitely are areas that need improvement, but it is not THAT bad.
Quote:
Ok, anyway... Thanks for fixing it, I don't know what RawToValue exactly does, so I use it everywhere. As I understand it, Value is some kind of container which can hold almost anything. But to do so, you have to "convert" it, and that's what RawToValue does... At least that's my belief.
Well, when type is aware about Value (or Value about type, which is the case of some basic types like 'int'), you do not need any explicit conversions. You are only supposed to use RawToValue for types when implicit conversion does not work.
Quote:
One thing I'm still curious about... What the heck is this assert:
ptr()->GetType() >= 255 || !svo[ptr()->GetType()]
and what does it have in common with
This assert basically checked that you are not using RawToValue for "SVO optimized types". Which I agree is borderline - it might happen this is needed in some template code, so I have changed the rule (I mean, you can now use RawToValue even for types that are alredy supported on higher level).
Quote:
inline _Uint4_t _Fetch_add_seq_cst_4(volatile _Uint4_t *_Tgt, _Uint4_t _Value)
{ /* add _Value to *_Tgt atomically with
sequentially consistent memory order */
return (_INTRIN_SEQ_CST(_InterlockedExchangeAdd)((volatile long *)_Tgt, _Value));
}
Thanks
Now hard to say about this, but this is probably related to reference counting of one form of internal Value storage. Very likely things got messed up and Value destructor thought it has to release reference count while internal storage was NOT reference counted.
[Updated on: Tue, 07 March 2017 12:15] Report message to a moderator
|
|
|
|
|
ASSERT when using ValueMap
By: NilaT on Tue, 21 February 2017 16:23
|
|
|
Re: ASSERT when using ValueMap
By: NilaT on Wed, 22 February 2017 11:56
|
|
|
Re: ASSERT when using ValueMap
By: NilaT on Mon, 27 February 2017 16:17
|
|
|
Re: ASSERT when using ValueMap
|
|
|
Re: ASSERT when using ValueMap
|
|
|
Re: ASSERT when using ValueMap
By: NilaT on Fri, 03 March 2017 09:29
|
|
|
Re: ASSERT when using ValueMap
By: mirek on Tue, 07 March 2017 00:43
|
|
|
Re: ASSERT when using ValueMap
By: mirek on Tue, 07 March 2017 00:58
|
|
|
Re: ASSERT when using ValueMap
|
|
|
Re: ASSERT when using ValueMap
By: mirek on Tue, 07 March 2017 11:29
|
|
|
Re: ASSERT when using ValueMap
By: mirek on Tue, 07 March 2017 11:42
|
|
|
Re: ASSERT when using ValueMap
|
|
|
Re: ASSERT when using ValueMap
By: mirek on Tue, 07 March 2017 13:47
|
|
|
Re: ASSERT when using ValueMap
By: NilaT on Tue, 07 March 2017 14:54
|
|
|
Re: ASSERT when using ValueMap
By: mirek on Tue, 07 March 2017 15:00
|
|
|
Re: ASSERT when using ValueMap
By: NilaT on Tue, 07 March 2017 11:54
|
|
|
Re: ASSERT when using ValueMap
By: mirek on Tue, 07 March 2017 12:10
|
|
|
Re: ASSERT when using ValueMap
By: NilaT on Tue, 07 March 2017 15:49
|
Goto Forum:
Current Time: Mon May 13 21:04:06 CEST 2024
Total time taken to generate the page: 0.02854 seconds
|