You have typically 3 choices to solve an allocation problem like that.
1) allocate a chunk of memory and return it, with the caller becoming
responsible for the free later. (like Daniel Said)
2) changing the function signature so that the caller has to pass to the
function a pointer to the memory chunk that will be used to store the
results (usually this is the best option of the three as it means the
caller becomes responsible for all memory management).
3) return a struct with the data inside.
On Thu, Sep 21, 2017 at 5:00 PM, Mario Meissner <mr.rash....@gmail.com>
wrote:
> 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
>
>
--
Vasco Alexandre da Silva Costa
PhD in Computer Engineering (Computer Graphics)
Instituto Superior Técnico/University of Lisbon, Portugal
------------------------------------------------------------------------------
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
