Hi Øyvind,
Of course resources tracking in C++ and exception handling comes to
mind as a much more robust solution to such problems. I'm not
arguing for using C++, I'm just saying that
That's exactly what i thought when i see all the
malloc's in OpenOcd. I think, that there are still
a
That's exactly what i thought when i see all the
malloc's in OpenOcd. I think, that there are still
a lot of memory leaks there. Are there any plans too switch
over to C++? There could be some great base classes
with virtual functions for the drivers and all this
allocation stuff could be
On Wed, Dec 16, 2009 at 8:43 PM, Carsten Breuer
carstenbreueropen...@textwork.de wrote:
Hi Øyvind,
Of course resources tracking in C++ and exception handling comes to
mind as a much more robust solution to such problems. I'm not
arguing for using C++, I'm just saying that
That's
Hi Dean,
...any plans too switch over to C++? There could be some great base
Nooo! Don't start this again! :)
Ups. Sorry. It looks like that i have the talent to ask the
wrong questions in the wrong group ;-).
I was actually just talking with a friend about C++ and virtual
tables. We
Hi Øyvind, hi all.
Are there any plans too switch over to C++?
None. There is no interest amongst the maintainers.
We know of no *significant* memory leaks today and we accept patches
to fix all malloc() / resource tracking problems.
Do you know of any real memory leak(other than missing
On Wed, Dec 16, 2009 at 9:13 PM, Carsten Breuer
carstenbreueropen...@textwork.de wrote:
Hi Dean,
...any plans too switch over to C++? There could be some great base
Nooo! Don't start this again! :)
Ups. Sorry. It looks like that i have the talent to ask the
wrong questions in the wrong
The correct function is selected by the compiler and the overhead
is IMO in our area not an issue.
In embedded developpment, IMO can be argued to be not precise
enough.
Well, we talk about the PC-side of an embedded system.
So we have more then enough horse power here.
The overhead is:
On
On Sun, 2009-12-13 at 15:49 -0800, David Brownell wrote:
[snip]
Note that MISRA is not universally lauded. As I understand, some of
its practices are contrary to other widely adopted coding policies.
Sure. Some points are a laugh like a null pointer should not be
dereferenced.
On Sunday 13 December 2009, Zach Welch wrote:
On Sun, 2009-12-13 at 15:49 -0800, David Brownell wrote:
[snip]
Note that MISRA is not universally lauded. As I understand, some of
its practices are contrary to other widely adopted coding policies.
Sure. Some points are a laugh
On Sunday 13 December 2009, David Brownell wrote:
I admit that when I first came across it, the don't check for NULL
philosophy seemed pretty wrong. But, quite a few years later on, now
I see that it's quite effective. The it's wrong argument is on micro
scales. The it's right one is macro
One of the common threads there is needing to have a handle on
just how common an error is before choosing strategies for
dealing with it.
I did a pass of OpenOCD in the early days where I fixed
all the error paths for malloc() where malloc() was greater than
a few bytes. I have no evidence
11 matches
Mail list logo
