By flag you mean that I should indicate with that variable whether an
intersection occurred or not?
Also, should I just return it without a pointer, without allocating it on
the heap? I assume this is what you wanted me to do because you suggested
my function head to be:
struct intersection_t intersection(point_t p0 ....
I thought this is not possible because it would be destroyed once the
function call ends. But apparently it doesn't:
https://stackoverflow.com/questions/22957175/how-does-function-actually-return-struct-variable-in-c
The VS compiler seems to complain when I try to assign the returned struct
to another variable though.
As far as svn printing Japanese comments, that is due to the fact that some
of my locale settings in my OS are set to Japanese (not the language). No
clue why svn decided to use Japanese comments now though. I hope it isn't
too annoying ^^'
Thank you for the quick feedback! Very much appreciated.
Mario.
On 21 September 2017 at 17:16, Daniel Roßberg <danielmrossb...@gmail.com>
wrote:
> Hi Mario,
>
> Hmm, it looks like you haven't really understood what I wrote you. You
> use the struct but allocate it with BU_GET() on the heap and don't use its
> intersect flag. But what is really bad is that you don't free it if it
> won't be used any more.
>
> BTW, do you have a Chinese OS version? Your diff files contain Chinese
> comments.
>
>
> Regards,
> Daniel
>
>
> 2017-09-21 14:13 GMT+02:00 Mario Meissner <mr.rash....@gmail.com>:
>
>> Hi Daniel.
>>
>> Thank you for your response. Negative values may have been only due to
>> using the wrong formatting tag while printing values. I have cleaned up
>> some unused variables and fixed the intersection by using your suggestion.
>>
>> Mass is 0 in the total_weight variable, as if the code wasn't really
>> adding up my segment_density values correctly. I might have deleted some
>> important code related to the storing or reading of the values. I will
>> double check on that now.
>> Attached goes current version of my code.
>>
>> Mario.
>>
>> On 21 September 2017 at 13:03, Daniel Roßberg <danielmrossb...@gmail.com>
>> wrote:
>>
>>> Hi Mario,
>>>
>>> I have been trying to track down the reason why some densities are
>>>> negative. A few questions I have ended up asking myself:
>>>>
>>>> - Is it possible for MAGNITUDE() to return a negative number? It would
>>>> make no sense to me, but I suspect it's happening.
>>>>
>>>
>>> No, MAGNITUDE() is the square root of a (necessarily) positive value.
>>> You can safely assume it to be not negative.
>>>
>>> - In my little function intersection I noticed that I am returning a
>>>> pointer to a local variable, that could be destroyed in any moment after
>>>> the call ends. Instead of that, I want to return a safe variable. How do I
>>>> do that in this case?
>>>>
>>>> I don't understand why it doesn't let me return directly the variable
>>>> point_t. It's a pointer, because it's an array, right? As it didn't let me
>>>> return the point, I decided to return a pointer to the point instead,
>>>> however as I mentioned this is not safe, so I have to change it now. Any
>>>> explanation on why I can't return the point, and what I should do to make
>>>> it safe?
>>>>
>>>
>>> Well, there is a standard solution for this kind of issue: Putting the
>>> data on the heap, e.g.
>>> point_t *intersect = (point_t *) bu_malloc(sizeof(point_t),
>>> "intersection");
>>> with the disadvantage that the caller has explicitly to free the memory
>>> with bu_free().
>>>
>>> It's true that C functions can't return arrays (because of historic
>>> reason). But, returning an array wouldn't help you here as you are using
>>> the function's return as a flag for intersection too. On the other hand,
>>> structs can be returned:
>>> struct intersection_t {
>>> int intersect;
>>> point_t intersection_point;
>>> };
>>>
>>> struct intersection_t intersection(point_t p0, point_t p1, point_t
>>> p_co, vect_t p_no) {
>>> ....
>>> should work.
>>>
>>>
>>>> Finally, I think I could need some help regarding the negative values
>>>> issue, at least once I'm sure the two points above aren't the cause.
>>>>
>>>
>>> Feel free to ask ;)
>>>
>>>
>>> Regards,
>>> Daniel
>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> BRL-CAD Developer mailing list
>>> brlcad-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>>>
>>>
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> BRL-CAD Developer mailing list
>> brlcad-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>>
>>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
