One other trick I use extensively when working with pointers, both in
embedded and non embedded systems is simply to use a cast to a reference.
It is a simple method that makes the code easier to read and prevents
inadvertently altering the pointer.
It also enables use of . instead of -> pointer de-referencing which is
(IMHO) easier to read when using classes/ structures

for example, a simple piece of code to increment all entries in a buffer
until one reaches 255 ( useless but serves to demonstrate the meaning )

It has no run-time overhead, the code generated is the same as with pointer
de-referencing, but it avoids the risk of missing parentheses.

i.e. the often seen mistakes such as
*(lpDemo++) versus (*lpDemo)++
unsigned gDemoArray[100];

void f1(...){
unsigned * lpDemo = gDemoArray;
While(lpDemo < gDemoArray + 100){
unsigned & lDemo(*lpDemo); // creates a reference, this
generates no actual code

if (lDemo++ == 255) break; // using the reference actually
uses the pointer, but prevents accidentally modifying the pointer

lpDemo++; // the pointer is used only when the pointer
itself is the target of assignment, or the value to be tested
}
}

Regards

Phil.

-----Original Message-----
From: l... [mailto:l...] On Behalf Of
Wouter van Ooijen
Sent: 03 March 2012 08:01
To: l...
Subject: Re: [lpc2000] Embedded C++ tips

> Deallocation of same-size blocks is O(1)--nice, but uninteresting.

For systems with strict real-time requirements O(1) is very interesting,
especially when the constant factor is small.

> Deallocation in a buddy heap can be made to be effectively O(1) > for
small memory embedded systems.

A heap can have is use in embedded systems, but IMO not in systems with
strict timing constraints, high reliability, and (very) small memory.
Some more arguments (which every one has to evaluate for himself against his
particular system):

- fragmentation: it is very unfortunate when a system works now (during
test), but fails due to some specific pattern of allocation and deallocation
(which of course happens only in the field..).

- memory leaks and dead pointers: programmers are bad at correctly freeing
memory, especially in exceptional situations. on the other side, programmers
sometimes use memory after they have free'd it. Both types of errors are
hard to test and debug (although filling freed memory with DEAD BEEF is a
good start).

- (un)predictability: for verifying timing requirements history-dependent
execution time (of malloc and/or free) can be a nightmare.

--

Wouter van Ooijen

-- -------
Van Ooijen Technische Informatica: www.voti.nl consultancy, development,
PICmicro products docent Hogeschool van Utrecht: www.voti.nl/hvu
C++ on uC blog: http://www.voti.nl/erblog

Start a New Thread