>> 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 Wed, Dec 16, 2009 at 9:13 PM, Carsten Breuer
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 group ;-).
You're just ke
Carsten Breuer a écrit :
> 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.
> QT and with it KDE are build on virtual functions.
But then, QT and KDE do not have a requi
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 missin
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
On Wed, Dec 16, 2009 at 8:43 PM, Carsten Breuer
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 exactly what i thought when i
>
> 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 coul
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
> 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
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
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
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
> > derefer
On Sunday 13 December 2009, Carsten Breuer wrote:
> If i have time i will make a check with lint and QAC and
> if there are errors, i will submit patches.
Great! Though try to filter out any that aren't going
to be in the "obviously worth fixing" category and are
more in the "debatable style choi
Hi David,
i switch the subject to OpenOCD Coding, because this
has nothing to do with the original posting anymore.
> So if you have access to MISRA tools and specifications, which aren't
> exactly public ... are you intending to submit any patches to address
> related issues?
If i have time i w
14 matches
Mail list logo
