<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Double pointer usage &amp;quot;freeze&amp;quot;</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/26813/double-pointer-usage-freeze</link><description> 
Hello! 

 
Iam currently working on a project with the XC2785X-104F
Controller, uVision 4 and Keil C166 Compiler. 
Within my code i have to work with matrices and several matrix
calculations. Therefor iam working with double pointers, structs and
2</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: Double pointer usage "freeze"</title><link>https://community.arm.com/thread/152930?ContentTypeID=1</link><pubDate>Thu, 17 Feb 2011 23:51:33 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:8da659c8-f99c-401b-bd01-5afcb46ad3aa</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
I&amp;#39;m not agreeing on this one. I normally don&amp;#39;t want the base
implementation to just have raw void* pointers that always have to be
assigned to a pointer of a different type even for performing
base-class functionality. I normally prefer the base class to have
pointers GenericNode *prev,*next so the implementation can do all
generic operations directly without an assign or type cast.&lt;/p&gt;

&lt;p&gt;
So in the end, a type cast will then be needed first when
upgrading from the base class element type into the specific type,
assuming that the abstract data type is uniform, only containing
objects of one single type.&lt;/p&gt;

&lt;p&gt;
It&amp;#39;s important to note that abstract container objects can
sometimes be implemented with the assumption that all inserted
objects contains any links needed. While it is also possible to
create abstract container objects that instead allocate own memory to
store links. The second alternative allows you to create a list of
int and can work quite well with void* pointers but instead needs own
memory allocations for each inserted object. The advantage is of
course that a single object can be inserted into many lists. But the
costs of such an implementation can be quite high. The list doesn&amp;#39;t
know the number of elements that may be added, so it can&amp;#39;t just
statically allocate these helper structures.&lt;/p&gt;

&lt;p&gt;
Most of the time, I prefer abstract containers that assumes that
inserted objects shares a common property, so they may look
like:&lt;/p&gt;

&lt;pre&gt;
typedef struct {
    struct GenericNodeInfo links;
    MySpecificData xxx;
} MySpecificNode;
&lt;/pre&gt;

&lt;p&gt;
I normally fix type safety by something like:&lt;/p&gt;

&lt;pre&gt;
threadlist_add(Thread* t) {
    list_add(threads,(GenericNode*)t);
}
&lt;/pre&gt;

&lt;p&gt;
and the base class can directly work on the element:&lt;/p&gt;

&lt;pre&gt;
void list_add(GenericList* list,GenericNode *node) {
    if (!node || !list) {
        // naughty!
        return FALSE;
    }
    if (node-&amp;gt;prev || node-&amp;gt;next) {
        if (!list_unlink(node)) {
            // node seems to already be in a list - but not in our list...
            return FALSE;
        }
    }
    node-&amp;gt;prev = list-&amp;gt;tail;
    node-&amp;gt;next = NULL;
    list-&amp;gt;tail = node;
    if (!list-&amp;gt;head) list-&amp;gt;head = node;
    return TRUE;
}
&lt;/pre&gt;

&lt;p&gt;
Sometimes, I may extend the above by having the GenericNode object
store a value in it representing type, and the container class store
the same type. So an insert can complain if a list of &amp;quot;thread&amp;quot; gets
an object that isn&amp;#39;t of type &amp;quot;thread&amp;quot;. Most of the time, this can be
done by consuming a single byte (or smaller) since there seldom is a
large number of types involved.&lt;/p&gt;

&lt;p&gt;
But there is no own value in writing code without pointer type
casts. The important thing is to reduce the risks of a normally
educated developer from goofing up. Someone who really do want to do
stupid things will always manage anyway.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Double pointer usage "freeze"</title><link>https://community.arm.com/thread/152161?ContentTypeID=1</link><pubDate>Thu, 17 Feb 2011 15:47:37 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:7d787178-fda8-40ad-aab2-57d1b8f9d5d7</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;When implementing abstract data types in C, you normally end up
with a void or &amp;quot;base class&amp;quot; pointer that have to be cast to the
correct type before being used.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
You rather rarely &lt;b&gt;have&lt;/b&gt; to. It&amp;#39;s generally both clearer and
safer to avoid the cast and just assign that (void*) to a variable of
the proper type instead.&lt;/p&gt;

&lt;p&gt;
It&amp;#39;s clearer because the new pointer variable will have to be
created just once, instead of performing the same pointer cast
multiple times.&lt;/p&gt;

&lt;p&gt;
It&amp;#39;s safer because a cast all but &lt;b&gt;forces&lt;/b&gt; the compiler to
accept whatever type you put in there, since you used the ultimate
means of telling it you know exactly what you&amp;#39;re doing. So even if
that cast can&amp;#39;t work at all, e.g. because it breaks const
correctness, the compiler may still obey it. The compiler would
refuse the same type change if you did it implicitly, on assignment.
Any pointer conversion that the compiler wouldn&amp;#39;t do implicitly,
without asking, is usually ill-advised or unsafe if forced by a
cast.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Double pointer usage "freeze"</title><link>https://community.arm.com/thread/158009?ContentTypeID=1</link><pubDate>Thu, 17 Feb 2011 06:00:12 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:bd3a948b-9ab5-4b83-b024-45fda90bfaf3</guid><dc:creator>&amp;#178;erik malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
Someone see a criticism and get migthy upset, stamp the little
feet in the floor and cries.&lt;/p&gt;

&lt;p&gt;
If you can not handle criticisms, stay away from organized jobs
where regular code reviews are the rule.&lt;br /&gt;
At my first such job I learned a lot and my code became far more
&amp;#39;natural&amp;#39; and thus more mainatainable.&lt;/p&gt;

&lt;p&gt;
Above (paraphrasing) there is a defensive statement &amp;quot;my code has
been maintained by others&amp;quot; SO WHAT. I have maintained much code
written by others the diffrence is not whether it was possible, but
how much effort it took.&lt;/p&gt;

&lt;p&gt;
Erik&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Double pointer usage "freeze"</title><link>https://community.arm.com/thread/157958?ContentTypeID=1</link><pubDate>Thu, 17 Feb 2011 03:41:55 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:5e15aeaf-3d4a-49d5-b628-533d48bbc719</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
He also wrote: &amp;quot;Next you&amp;#39;re putting entirely too many casts into
that code.&amp;quot; and not &amp;quot;You have casts in that code.&amp;quot;&lt;/p&gt;

&lt;p&gt;
No claim that zero casts are the only allowed count.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Double pointer usage "freeze"</title><link>https://community.arm.com/thread/157921?ContentTypeID=1</link><pubDate>Thu, 17 Feb 2011 03:02:51 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:91ab1c7c-00e6-43c2-b9d9-8727d797545f</guid><dc:creator>bad memories</dc:creator><description>&lt;p&gt;&lt;p&gt;
I&amp;#39;ll keep all further &lt;b&gt;&lt;i&gt;approximation&lt;/i&gt;&lt;/b&gt; of the writer&amp;#39;s
personal traits to myself!&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Double pointer usage "freeze"</title><link>https://community.arm.com/thread/152938?ContentTypeID=1</link><pubDate>Thu, 17 Feb 2011 02:52:09 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:c22483e3-4185-47e3-875c-de6b526d1272</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;&amp;quot;To a very good &lt;b&gt;approximation&lt;/b&gt;, every pointer cast in a C
program is either superfluous or wrong&amp;quot;&lt;/i&gt;&lt;br /&gt;
(my emphasis).&lt;/p&gt;

&lt;p&gt;
He clearly said that it&amp;#39;s an &lt;b&gt;&lt;i&gt;approximation&lt;/i&gt;&lt;/b&gt; - I think
that is entirely fair in general, and definitely appropriate to this
specific context in particular.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Double pointer usage "freeze"</title><link>https://community.arm.com/thread/152940?ContentTypeID=1</link><pubDate>Thu, 17 Feb 2011 02:25:23 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:715bb31d-3577-4c9a-955c-b0289fee56bd</guid><dc:creator>Tamiryan Michael</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;No. Refer back to Broeker&amp;#39;s comment and, in particular, the
style of that comment.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Tough but fair!&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Double pointer usage "freeze"</title><link>https://community.arm.com/thread/152170?ContentTypeID=1</link><pubDate>Thu, 17 Feb 2011 01:58:21 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:c1014eb3-1410-47d0-a97d-224aa7129850</guid><dc:creator>bad memories</dc:creator><description>&lt;p&gt;&lt;pre&gt;
You still seem to upgrade a general recommendation into a hard rule.
&lt;/pre&gt;

&lt;p&gt;
No. Refer back to &lt;b&gt;Broeker&amp;#39;s&lt;/b&gt; comment and, in particular, the
&lt;i&gt;style&lt;/i&gt; of that comment.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Double pointer usage "freeze"</title><link>https://community.arm.com/thread/151400?ContentTypeID=1</link><pubDate>Thu, 17 Feb 2011 01:15:52 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:1c31ca54-b327-4c68-8fcd-5c53f9100bdc</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
&amp;quot;Someone stating that pointer casts are superfluous or wrong is
going a step too far with the purist bit.&amp;quot;&lt;/p&gt;

&lt;p&gt;
You still seem to upgrade a general recommendation into a hard
rule.&lt;/p&gt;

&lt;p&gt;
When implementing abstract data types in C, you normally end up
with a void or &amp;quot;base class&amp;quot; pointer that have to be cast to the
correct type before being used. And now and then, a C library forgets
a C on an input parameter, making it impossible to use your const
string without a type cast.&lt;/p&gt;

&lt;p&gt;
There are a number of situations where type casts of pointers are
needed. But real-world code tends to get a lot of pointer casts where
the code shouldn&amp;#39;t have needed any casts. Too much code tends to look
like trial-and-error.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Double pointer usage "freeze"</title><link>https://community.arm.com/thread/151404?ContentTypeID=1</link><pubDate>Thu, 17 Feb 2011 01:14:35 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:1ada28e4-ef32-4bea-9b8c-1cdcfd7c3620</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
Nobody denies that.&lt;/p&gt;

&lt;p&gt;
The assertion is that those instances are the &lt;i&gt;exception&lt;/i&gt;,
rather than the rule.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;&amp;quot;stating that pointer casts are superfluous or wrong is going a
step too far&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
But nobody said that!&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Double pointer usage "freeze"</title><link>https://community.arm.com/thread/146655?ContentTypeID=1</link><pubDate>Thu, 17 Feb 2011 01:03:05 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:f5f541b4-31c7-4dc2-a4d8-5b1f4f9ca24b</guid><dc:creator>bad memories</dc:creator><description>&lt;p&gt;&lt;pre&gt;
Can you honestly be comfortable looking, at a piece of code like this, to think that the
author really knows what&amp;#39;s going on:
&lt;/pre&gt;

&lt;p&gt;
No. IMHO it is just ugly code.&lt;/p&gt;

&lt;pre&gt;
To a very good approximation, every pointer cast in a C program is either superfluous or wrong.
&lt;/pre&gt;

&lt;p&gt;
That is what I take issue with! I believe that it is a bad
approximation. Pointer casts that are obviously over complex and
difficult to interpret with a quick glance are (again IMHO) best
avoided. However, there are times where simple pointer casts can be
very useful and easy to follow. Just because they are there does NOT
make the code wrong, nor does it make the person who uses them a bad
programmer.&lt;/p&gt;

&lt;p&gt;
In my career I have written plenty of code. Some of it uses
pointer casts. The code has been functional. The code has worked. The
code has been maintainable and maintained by me and others.&lt;/p&gt;

&lt;p&gt;
Someone stating that pointer casts are superfluous or wrong is
going a step too far with the purist bit.&lt;/p&gt;

&lt;p&gt;
The pragmatic approach has worked for me. I&amp;#39;ll stick with it and
recommend it.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Double pointer usage "freeze"</title><link>https://community.arm.com/thread/145040?ContentTypeID=1</link><pubDate>Thu, 17 Feb 2011 00:19:33 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:5e05ab6f-e3fe-49a8-a825-9b7754098eeb</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;&amp;quot;Just because a typecast is there, it does not mean it is bad
per se&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Of course not - and nobody said that. And the point was
specifically about &lt;i&gt;&lt;b&gt;pointer&lt;/b&gt;&lt;/i&gt; casts - not all casts in
general.&lt;/p&gt;

&lt;p&gt;
It was given as an &lt;i&gt;&lt;b&gt;approximation&lt;/b&gt;&lt;/i&gt;; ie, generally
true, but with exceptions.&lt;/p&gt;

&lt;p&gt;
A type cast is a sign that the data is of the wrong type for the
operation being performed on it. True, that&amp;#39;s not a problem &lt;i&gt;per
se&lt;/i&gt; - but, when you see code littered with casts it just has to be
a sign that the author really hasn&amp;#39;t thought things through.&lt;br /&gt;
Doesn&amp;#39;t it?&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;&lt;b&gt;Pointer&lt;/b&gt;&lt;/i&gt; casts are particularly dangerous because the
dangers of a mis-cast are so much greater.&lt;/p&gt;

&lt;p&gt;
Can you honestly be comfortable looking, at a piece of code like
this, to think that the author really knows what&amp;#39;s going on:&lt;/p&gt;

&lt;pre&gt;
*((double **)(&amp;amp;mat-&amp;gt;matrix) + i)
&lt;/pre&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Double pointer usage "freeze"</title><link>https://community.arm.com/thread/145038?ContentTypeID=1</link><pubDate>Thu, 17 Feb 2011 00:06:30 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:8f533dd1-a8ce-4f05-93e2-8c8157f3c336</guid><dc:creator>Tamiryan Michael</dc:creator><description>&lt;p&gt;&lt;p&gt;
A 2005 draft of the C standard requires that casting a pointer
derived from one type to one of another type should maintain the
alignment correctness for both types (6.3.2.3 Pointers, par.
7):[3]&lt;/p&gt;

&lt;pre&gt;
char *external_buffer = &amp;quot;abcdef&amp;quot;;
int *internal_data;

internal_data = (int *)external_buffer;  // UNDEFINED BEHAVIOUR if &amp;quot;the resulting pointer
                                         // is not correctly aligned&amp;quot;
&lt;/pre&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Double pointer usage "freeze"</title><link>https://community.arm.com/thread/142822?ContentTypeID=1</link><pubDate>Wed, 16 Feb 2011 23:03:48 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:fa614db5-b98e-43ce-bd09-7e0f08e2eac0</guid><dc:creator>bad memories</dc:creator><description>&lt;p&gt;&lt;p&gt;
Very &lt;b&gt;&lt;i&gt;droll&lt;/i&gt;&lt;/b&gt; Dr Jameson. Would you like custard with
that banana?&lt;/p&gt;

&lt;p&gt;
Just because a typecast is there, it does not mean it is bad
&lt;i&gt;per se&lt;/i&gt;. It is just another component of the language. Like any
component of the language, it has advantages, disadvantages and
dangers if used incorrectly. A sensible programmer should be aware of
all of these issues (and more) if they want to make the best use of
those components.&lt;/p&gt;

&lt;p&gt;
If you put a &amp;#39;+&amp;#39; where a &amp;#39;-&amp;#39; is required, bad things can happen.
It may be easier to find a fault like this, but it can still happen
and it can still have disasterous results.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Double pointer usage "freeze"</title><link>https://community.arm.com/thread/139823?ContentTypeID=1</link><pubDate>Wed, 16 Feb 2011 17:15:59 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:fc5ddec4-2a63-4882-9087-f64edf260395</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;My car had a problem recently so I took it to the garage. The
problem was caused by a nut not being correctly tightened. Why wasn&amp;#39;t
it correctly tightened? Simple, it was the wrong type.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;Probably best to ban all nuts.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Oh my, dude, are you in way over your head.&lt;/p&gt;

&lt;p&gt;
First you thought you were qualified to insult other people&amp;#39;s
contributions without so much a hint of an argument of your own. I
was going to let that pass as the usual childish nonsense of an
anonymous coward.&lt;/p&gt;

&lt;p&gt;
But that apparently wasn&amp;#39;t enough for you. So you had to go and
remove any remaining doubt and prove that you don&amp;#39;t even understand
the problem, much less qualify to judge advice about it, by
completely missing the point with your supposed analogy above.&lt;/p&gt;

&lt;p&gt;
You hardly deserve it, but for the benefit of other readers, I&amp;#39;ll
drop you a hint anyway: in a car analogy, the equivalent of those
pointer casts would rather be chewing gum used to patch various
gaping holes all across the car&amp;#39;s critical systems.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Double pointer usage "freeze"</title><link>https://community.arm.com/thread/151403?ContentTypeID=1</link><pubDate>Wed, 16 Feb 2011 07:03:06 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:4bd584e7-399a-4f06-ab14-093af7924559</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
IF this is a school project then, surely, the object of the
exercise is to learn those skills?&lt;/p&gt;

&lt;p&gt;
If it&amp;#39;s a commercial project, wouldn&amp;#39;t it be more appropriate to
hire someone who &lt;i&gt;does&lt;/i&gt; have the required skills?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Double pointer usage "freeze"</title><link>https://community.arm.com/thread/151402?ContentTypeID=1</link><pubDate>Wed, 16 Feb 2011 07:01:04 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:e17e8220-7036-442d-a281-2b2155ace2c5</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;&amp;quot;... and, unfortunately, not the time to enhance them&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
But you have time to deal, like this, with the consequences?!&lt;/p&gt;

&lt;p&gt;
Which is the better use of time:&lt;/p&gt;

&lt;p&gt;
&lt;b&gt;1.&lt;/b&gt; Throwing something together in a day, then spending a
week sorting out the mess;&lt;/p&gt;

&lt;p&gt;
&lt;b&gt;2.&lt;/b&gt; Taking a week to learn how to do it properly, then
spending a day getting it right first time.&lt;/p&gt;

&lt;p&gt;
Your call!&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Double pointer usage "freeze"</title><link>https://community.arm.com/thread/147672?ContentTypeID=1</link><pubDate>Wed, 16 Feb 2011 06:08:56 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:c298181b-13f3-4d71-b1df-d60d82e7c732</guid><dc:creator>Mike Kleshov</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;Do i have to call the init_mempool(xxx) only once to reserve
the memory for all my matrices?&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Exactly.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;i do not really have good programming skills and,
unfortunately, not the time to enhance them.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
If you only need to get the program running and code readability
and maintainability is not a concern, then simply ignore the
criticism.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Double pointer usage "freeze"</title><link>https://community.arm.com/thread/146660?ContentTypeID=1</link><pubDate>Wed, 16 Feb 2011 04:23:21 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:223aed4f-03d4-4673-96d0-858e9e7de12f</guid><dc:creator>Joshua Grosch</dc:creator><description>&lt;p&gt;&lt;p&gt;
Hey folks!&lt;/p&gt;

&lt;p&gt;
thanks for all the (more or less usefull) answers. Especially to
Andrew!!&lt;br /&gt;
The problem seems to be solved now.&lt;br /&gt;
It was not a NULL returning from the mat_creat function, moreover it
was the missing init_mempool function which initializes the memory
management routines.&lt;br /&gt;
Yet i do not really understand how to use this func the right
way.&lt;/p&gt;

&lt;p&gt;
- Do i have to call the init_mempool(xxx) only once to reserve the
memory for all my matrices?&lt;br /&gt;
or&lt;br /&gt;
- Do i have to call the func everytime i want memory reserved for a
single (new created) matrix&lt;/p&gt;

&lt;p&gt;
I&amp;#39;ve read the article in the User Guide: but it confused me
somehow&lt;br /&gt;
... Call the init_mempool function only once at the beginning of your
program ...&lt;br /&gt;
otherwise it is used different in that tst_init_mempool
function..&lt;/p&gt;

&lt;p&gt;
So far, iam sorry to hear of some &amp;quot;noobish&amp;quot; errors in my code - i
do not really have good programming skills and, unfortunately, not
the time to enhance them.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Double pointer usage "freeze"</title><link>https://community.arm.com/thread/145041?ContentTypeID=1</link><pubDate>Wed, 16 Feb 2011 01:04:30 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:351ca27b-2f7b-4236-899d-7fb7a7a62359</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
Which certainly &lt;i&gt;looks like&lt;/i&gt; the case here:&lt;/p&gt;

&lt;pre&gt;
*((double **)(&amp;amp;mat-&amp;gt;matrix) + i)
&lt;/pre&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Double pointer usage "freeze"</title><link>https://community.arm.com/thread/142812?ContentTypeID=1</link><pubDate>Wed, 16 Feb 2011 00:43:35 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:b2498697-fda3-4e58-9b68-47d09db92ae3</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
Most type casts gets added because one of:&lt;br /&gt;
- the developer wants to &amp;quot;explain&amp;quot; the code by adding type casts as
some form of comment to tell what data type (he thinks) the variable
has.&lt;br /&gt;
- the developer gets compilation errors and don&amp;#39;t completely
understand the pointer logic so he adds different variants of type
casts until the compiler doesn&amp;#39;t complain anymore.&lt;/p&gt;

&lt;p&gt;
Why can&amp;#39;t someone release a compiler that after the third
&amp;quot;trial-and-error&amp;quot; typecast found introduces a 24 hour compilation
lockdown while requiring the developer to get a good C/C++ book and
read up on the subject?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Double pointer usage "freeze"</title><link>https://community.arm.com/thread/139822?ContentTypeID=1</link><pubDate>Tue, 15 Feb 2011 23:20:24 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:f72fdd6c-ab81-44f2-ac57-31637d73edf5</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
But how often does that happen?&lt;/p&gt;

&lt;p&gt;
Pointer mis-casting, on the other hand, is very common...&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Double pointer usage "freeze"</title><link>https://community.arm.com/thread/130742?ContentTypeID=1</link><pubDate>Tue, 15 Feb 2011 22:48:25 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:2998fe61-1fab-4f1a-9516-43e435a4f689</guid><dc:creator>bad memories</dc:creator><description>&lt;p&gt;&lt;pre&gt;
To a very good approximation, every pointer cast in a C program is either superfluous or wrong
&lt;/pre&gt;

&lt;p&gt;
My car had a problem recently so I took it to the garage. The
problem was caused by a nut not being correctly tightened. Why wasn&amp;#39;t
it correctly tightened? Simple, it was the wrong type.&lt;/p&gt;

&lt;p&gt;
Probably best to ban all nuts.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Double pointer usage "freeze"</title><link>https://community.arm.com/thread/126657?ContentTypeID=1</link><pubDate>Tue, 15 Feb 2011 15:11:17 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:bb88dd56-021b-4c88-af6e-337489507c7b</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;&amp;quot;To a very good approximation, every pointer cast in a C
program is either superfluous or wrong&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Having just had to deal with some code where pointer casts
&lt;i&gt;were&lt;/i&gt; wrong and &lt;i&gt;were&lt;/i&gt; masking errors, I would very much
agree with that approximation!&lt;/p&gt;

&lt;p&gt;
It is, of course, just an approximation - there are a few cases
where pointer casts are warranted. But they are certainly the
exception rather than the rule.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Double pointer usage "freeze"</title><link>https://community.arm.com/thread/116243?ContentTypeID=1</link><pubDate>Tue, 15 Feb 2011 12:06:29 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:ee851b46-0e35-4f0e-b51f-4f83605ef3af</guid><dc:creator>bad memories</dc:creator><description>&lt;p&gt;&lt;pre&gt;
To a very good approximation, every pointer cast in a C program is either superfluous or wrong.
&lt;/pre&gt;

&lt;p&gt;
Your alter ego isn&amp;#39;t Dr Jameson by any chance? You sound much like
my first lecturer of software engineering who stated that no function
should have more than three lines of code.&lt;/p&gt;

&lt;p&gt;
He&amp;#39;s still a lecturer. We went on to write real code.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>