-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 20, 2006, at 1:04 AM, <[EMAIL PROTECTED]> [EMAIL PROTECTED]> wrote:
FWIW;
I went on to check that Embedded C++ that David Nugent mentioned,
and I found
this:
http://www.caravan.net/ec2plus/
Acording to the Q&A section:
"The goal of EC
On 7/20/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
FWIW;
I went on to check that Embedded C++ that David Nugent mentioned, and I found
this:
http://www.caravan.net/ec2plus/
Acording to the Q&A section:
"The goal of EC++ is to provide embedded systems programmers with a subset of
C++ tha
FWIW;
I went on to check that Embedded C++ that David Nugent mentioned, and I found
this:
http://www.caravan.net/ec2plus/
Acording to the Q&A section:
"The goal of EC++ is to provide embedded systems programmers with a subset of
C++ that is easy for the average C programmer to understand and us
Matthias Andree wrote:
Deciding that some features are bad beforehand, before you evaluate them
is IMO bad idea. Let interested people write a bunch of C++ modules with
the complete language before deciding on what shouldn't be used.
No, that won't work -- plus you need a bunch of run-time
On Thu, 2006-Jul-13 11:16:18 +0530, Kamal R. Prasad wrote:
>Im sorry I didn't understand you. setjmp() stores a few register contents
This varies with the CPU - from 48 bytes (i386 and sparc64) to 656
bytes (alpha). In addition, setjmp() stores the signal mask - and
accessing this requires a syst
In message: <[EMAIL PROTECTED]>
Joerg Sonnenberger <[EMAIL PROTECTED]> writes:
: On Thu, Jul 13, 2006 at 11:16:18AM +0530, Kamal R. Prasad wrote:
: > Im sorry I didn't understand you. setjmp() stores a few register contents
: > [notably ip] in a jmpbuf -which are restored after a longjm
On Thu, Jul 13, 2006 at 11:16:18AM +0530, Kamal R. Prasad wrote:
> Im sorry I didn't understand you. setjmp() stores a few register contents
> [notably ip] in a jmpbuf -which are restored after a longjmp(). How is the
> try/catch mechanism more efficient than a setjmp()/longjmp() in terms of
> spac
>From: "Kamal R. Prasad" <[EMAIL PROTECTED]>
>Im sorry I didn't understand you. setjmp() stores a few register contents
>[notably ip] in a jmpbuf -which are restored after a longjmp(). How is the
>try/catch mechanism more efficient than a setjmp()/longjmp() in terms of
>space/time complexity?
try
Im sorry I didn't understand you. setjmp() stores a few register contents
[notably ip] in a jmpbuf -which are restored after a longjmp(). How is the
try/catch mechanism more efficient than a setjmp()/longjmp() in terms of
space/time complexity?
thanks
-kamal
On 7/12/06, Joerg Sonnenberger <[EMA
Quoting Mike Meyer <[EMAIL PROTECTED]> (Wed, 12 Jul 2006 15:54:53 -0400):
> C++ may be the best choice
> because of it's roots in C, but there are better OO languages with
> roots in C as well. Even taking all that into account, C++ may be the
> best choice. But don't simply settle on C++ (or OO,
In <[EMAIL PROTECTED]>, Intron <[EMAIL PROTECTED]> typed:
> Mike Meyer wrote:
> > In <[EMAIL PROTECTED]>, [EMAIL PROTECTED] typed:
> >> C++ is the de-facto standard for OO: a lot of people know how to use it
> > We're bright enough to know that popularity doesn't imply technical
> > excellence, oth
Mike Meyer wrote:
In <[EMAIL PROTECTED]>, [EMAIL PROTECTED] typed:
C++ is the de-facto standard for OO: a lot of people know how to use it
Oh gods, does this bring to mind lots (and *lots*) of scathing
commentary. I'll restrict myself to just one:
Windows is the de-facto standard OS: a lot o
2006/7/12, Joerg Sonnenberger <[EMAIL PROTECTED]>:
On Tue, Jul 11, 2006 at 11:37:52PM +0200, Attilio Rao wrote:
> Even if I have no proof-of-concepts (so maybe somebody can show that
> this is not fair), if we have setjmp/longjmp in the kernel we can have
> a correct exception handling mechanism
>From: [EMAIL PROTECTED]
>Jason Slagle wrote:
>
>> On Wed, 12 Jul 2006, [EMAIL PROTECTED] wrote:
>>
>>> I would repeat several sentences in my last reply.
>>> Why would people write Windows application with rather MFC/ATL/.NET
>>> Framework than direct Windows API? Why is gtkmm framework created
--- Mike Meyer <[EMAIL PROTECTED]> ha scritto:
...
>
> Windows is the de-facto standard OS: a lot of people know how to use
> it.
>
Well... I wish several commercial CAD software producers thought otherwise.
> We're bright enough to know that popularity doesn't imply technical
> excellence,
Rick C. Petty <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> >
> > C++ is the de-facto standard for OO
>
> That is just sad. So many other languages do a much better job of
> implementing OO (Smalltalk, Java, Python, even Scheme).
That's true. At OOPSLA '97, Alan Kay (an OO pion
In <[EMAIL PROTECTED]>, Rick C. Petty <[EMAIL PROTECTED]> typed:
> On Wed, Jul 12, 2006 at 04:10:29PM +0200, [EMAIL PROTECTED] wrote:
> > C++ is the de-facto standard for OO
> That is just sad. So many other languages do a much better job of
> implementing OO (Smalltalk, Java, Python, even Scheme)
On Wed, Jul 12, 2006 at 04:10:29PM +0200, [EMAIL PROTECTED] wrote:
>
> C++ is the de-facto standard for OO
That is just sad. So many other languages do a much better job of
implementing OO (Smalltalk, Java, Python, even Scheme). While we're at
it, why not implement a bytecode interpreter for al
In <[EMAIL PROTECTED]>, [EMAIL PROTECTED] typed:
> C++ is the de-facto standard for OO: a lot of people know how to use it
Oh gods, does this bring to mind lots (and *lots*) of scathing
commentary. I'll restrict myself to just one:
Windows is the de-facto standard OS: a lot of people know how to
--- Peter Jeremy <[EMAIL PROTECTED]> ha scritto:
...
>
> I think the general concensus is that it's up to one of the proponents
> of this to actually implement it and demonstrate that it works and has
> no undesirable side-effects.
>
I only wanted to point out that Darwin modules are not the o
On Wed, Jul 12, 2006 at 06:33:09PM +0530, Kamal R. Prasad wrote:
> On 7/12/06, Joerg Sonnenberger <[EMAIL PROTECTED]> wrote:
>
> >On Tue, Jul 11, 2006 at 11:37:52PM +0200, Attilio Rao wrote:
> >> Even if I have no proof-of-concepts (so maybe somebody can show that
> >> this is not fair), if we hav
On 7/12/06, Joerg Sonnenberger <[EMAIL PROTECTED]> wrote:
On Tue, Jul 11, 2006 at 11:37:52PM +0200, Attilio Rao wrote:
> Even if I have no proof-of-concepts (so maybe somebody can show that
> this is not fair), if we have setjmp/longjmp in the kernel we can have
> a correct exception handling me
On Tue, Jul 11, 2006 at 11:37:52PM +0200, Attilio Rao wrote:
> Even if I have no proof-of-concepts (so maybe somebody can show that
> this is not fair), if we have setjmp/longjmp in the kernel we can have
> a correct exception handling mechanism without not great problems.
ROFL. Sorry, but using s
Quoting "M. Warner Losh" <[EMAIL PROTECTED]> (from Tue, 11 Jul 2006
10:32:03 -0600 (MDT)):
As to your other points, the resource allocation repetition has been
improved with bus_alloc_resources. the trouble is that many drivers
haven't been converted to use the new api.
Would you please com
On Tue, 2006-Jul-11 21:26:09 +0200, [EMAIL PROTECTED] wrote:
>I think it would be really nice to have the IOKit, or a lookalike that uses
>kobj(), available on FreeBSD. Another interesting experiment that I've
>mentioned before is OpenBFS:
I think the general concensus is that it's up to one of th
On Tue, 11 Jul 2006, Attilio Rao wrote:
> Even if I have no proof-of-concepts (so maybe somebody can show that
> this is not fair), if we have setjmp/longjmp in the kernel we can have
> a correct exception handling mechanism without not great problems.
You'd think that, but at least one issue is
Jason Slagle wrote:
On Wed, 12 Jul 2006, [EMAIL PROTECTED] wrote:
I would repeat several sentences in my last reply.
Why would people write Windows application with rather MFC/ATL/.NET
Framework than direct Windows API? Why is gtkmm framework created for
GTK+? Would you write a X11 applicati
Jason Slagle wrote:
On Wed, 12 Jul 2006, [EMAIL PROTECTED] wrote:
I would repeat several sentences in my last reply.
Why would people write Windows application with rather MFC/ATL/.NET
Framework than direct Windows API? Why is gtkmm framework created for
GTK+? Would you write a X11 applicati
On Wed, 12 Jul 2006, [EMAIL PROTECTED] wrote:
I would repeat several sentences in my last reply.
Why would people write Windows application with rather MFC/ATL/.NET Framework
than direct Windows API? Why is gtkmm framework created for GTK+? Would you
write a X11 application with original X11 A
At 7:03 PM -0400 7/11/06, Mike Meyer wrote:
In <[EMAIL PROTECTED]>, Rick C. Petty
<[EMAIL PROTECTED]> typed:
On Wed, Jul 12, 2006 at 02:25:21AM +0800, [EMAIL PROTECTED] wrote:
> > Good packages for various APIs are much easier to learn/debug
> > than those original APIs.
> What makes you s
FWIW and just IMHO;
I think it would be really nice to have the IOKit, or a lookalike that uses
kobj(), available on FreeBSD. Another interesting experiment that I've
mentioned before is OpenBFS:
http://www.bug-br.org.br/openbfs/index.phtml?section=development
"OpenBFS, as all file systems under
John Baldwin wrote:
On Tuesday 11 July 2006 12:33, M. Warner Losh wrote:
In message: <[EMAIL PROTECTED]>
John Baldwin <[EMAIL PROTECTED]> writes:
: and OS X both of which I've written a PCI driver for) we require device
: driver writers to go through a lot more hoops to do certain
M. Warner Losh wrote:
In message: <[EMAIL PROTECTED]>
V lav Haisman <[EMAIL PROTECTED]> writes:
: Deciding that some features are bad beforehand, before you evaluate them
: is IMO bad idea. Let interested people write a bunch of C++ modules with
: the complete language before decidi
In <[EMAIL PROTECTED]>, Rick C. Petty <[EMAIL PROTECTED]> typed:
> On Wed, Jul 12, 2006 at 02:25:21AM +0800, [EMAIL PROTECTED] wrote:
> > Good packages for various APIs are much easier to learn/debug than those
> > original APIs.
> What makes you say that C++ would provide a good API?
Good point.
On Wed, Jul 12, 2006 at 02:25:21AM +0800, [EMAIL PROTECTED] wrote:
>
> Matthias Andree wrote:
>
> Why would people write Windows application with rather MFC/ATL/.NET
> Framework than direct Windows API?
Because they like buggy code? (Not that the basic API is much better)
> Why is gtkmm create
2006/7/11, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
Why do you all consider importing C++ code to FreeBSD kernel to be so
complicated at the beginning?
Matthias Andree wrote:
> (please don't Cc me on list replies; chopping down the Cc list)
>
> On Tue, 11 Jul 2006, [EMAIL PROTECTED] wrote:
>
>> J
In message: <[EMAIL PROTECTED]>
John Baldwin <[EMAIL PROTECTED]> writes:
: On Tuesday 11 July 2006 15:21, [EMAIL PROTECTED] wrote:
: > John Baldwin wrote:
: >
: > > On Tuesday 11 July 2006 12:33, M. Warner Losh wrote:
: > >> In message: <[EMAIL PROTECTED]>
: > >> John Baldw
In message: <[EMAIL PROTECTED]>
[EMAIL PROTECTED] writes:
: Why do you all consider importing C++ code to FreeBSD kernel to be so
: complicated at the beginning?
Many people reading this list have conducted experiments in the past
at various employers. Everyone who has conducted the e
> It's less ugly than it used to be, esp. with the bus_read_X() stuff. There's
> no separate bus_alloc_resource/bus_setup_intr for interrupts though for
> example, just bus_setup_intr() equivalent. This is pretty simple though:
>
> /* OS X */
> IOMemoryMap *myBarMap;
> void *
On Tuesday 11 July 2006 14:48, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> John Baldwin <[EMAIL PROTECTED]> writes:
> : On Tuesday 11 July 2006 12:33, M. Warner Losh wrote:
> : > In message: <[EMAIL PROTECTED]>
> : > John Baldwin <[EMAIL PROTECTED]> writes:
> :
On Tuesday 11 July 2006 15:21, [EMAIL PROTECTED] wrote:
> John Baldwin wrote:
>
> > On Tuesday 11 July 2006 12:33, M. Warner Losh wrote:
> >> In message: <[EMAIL PROTECTED]>
> >> John Baldwin <[EMAIL PROTECTED]> writes:
> >> : and OS X both of which I've written a PCI driver for) we re
At 12:43 AM +0800 7/12/06, [EMAIL PROTECTED] wrote:
Before I do enough experiments, naturally I would never
talk about this thing.
I don't know why Dag-Erling C. Smo/rgrav is so unfriendly
to me ??? !!!
He is commenting on your patches. Do not take those as
personal attacks on you.
You seem
In message: <[EMAIL PROTECTED]>
John Baldwin <[EMAIL PROTECTED]> writes:
: On Tuesday 11 July 2006 12:33, M. Warner Losh wrote:
: > In message: <[EMAIL PROTECTED]>
: > John Baldwin <[EMAIL PROTECTED]> writes:
: > : and OS X both of which I've written a PCI driver for) we req
On Tuesday 11 July 2006 12:33, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> John Baldwin <[EMAIL PROTECTED]> writes:
> : and OS X both of which I've written a PCI driver for) we require device
> : driver writers to go through a lot more hoops to do certain things like
> :
Why do you all consider importing C++ code to FreeBSD kernel to be so
complicated at the beginning?
Matthias Andree wrote:
(please don't Cc me on list replies; chopping down the Cc list)
On Tue, 11 Jul 2006, [EMAIL PROTECTED] wrote:
Just as you said, C++ is more complicated than C. However,
Dag-Erling [iso-8859-1] Sm grav wrote:
John Baldwin <[EMAIL PROTECTED]> writes:
On Tuesday 11 July 2006 10:57, Dag-Erling Sm grav wrote:
> [EMAIL PROTECTED] writes:
> > What's more, can the "object model" function really as OpenDarwin's
> > IOKit class model?
> Does it need to?
He's trying t
Joerg Sonnenberger wrote:
On Tue, Jul 11, 2006 at 10:45:52PM +0800, [EMAIL PROTECTED] wrote:
Just as you said, C++ is more complicated than C. However, without
C++ exception and other advanced features, it hasn't brought much
complexity to C++ runtime library. Early C++ compiler even translates
John Baldwin <[EMAIL PROTECTED]> writes:
> On Tuesday 11 July 2006 10:57, Dag-Erling Smørgrav wrote:
> > [EMAIL PROTECTED] writes:
> > > What's more, can the "object model" function really as OpenDarwin's
> > > IOKit class model?
> > Does it need to?
> He's trying to port IOKit to FreeBSD for his e
John Baldwin wrote:
On Tuesday 11 July 2006 10:57, Dag-Erling Sm grav wrote:
> For example, I think C++ exception handling is really poorly suited for
> low-level code.
Exception handling is required by the standard, even for freestanding
implementations.
Standards aside, in Darwin, the C++
In message: <[EMAIL PROTECTED]>
John Baldwin <[EMAIL PROTECTED]> writes:
: and OS X both of which I've written a PCI driver for) we require device
: driver writers to go through a lot more hoops to do certain things like
: allocate resources. At the very least there is much that can
In message: <[EMAIL PROTECTED]>
[EMAIL PROTECTED] writes:
: You can LOOK DOWN UPON me again and again. But is it really your patent,
: a FreeBSD security team member's patent: you know what FreeBSD kernel
: and C++ is, but I am too BRAINLESS to understand FreeBSD kernel and C++?
I don'
In message: <[EMAIL PROTECTED]>
[EMAIL PROTECTED] writes:
: >> --- systm.h.orig Mon Jul 10 05:42:58 2006
: >> +++ systm.hMon Jul 10 18:44:01 2006
: >> @@ -203,7 +203,7 @@
: >> int suword16(void *base, int word);
: >> int suword32(void *base, int32_t word);
: >>
In message: <[EMAIL PROTECTED]>
Václav Haisman <[EMAIL PROTECTED]> writes:
: Deciding that some features are bad beforehand, before you evaluate them
: is IMO bad idea. Let interested people write a bunch of C++ modules with
: the complete language before deciding on what shouldn't be u
(please don't Cc me on list replies; chopping down the Cc list)
On Tue, 11 Jul 2006, [EMAIL PROTECTED] wrote:
> Just as you said, C++ is more complicated than C. However, without
> C++ exception and other advanced features, it hasn't brought much
> complexity to C++ runtime library. Early C++ com
On Tuesday 11 July 2006 10:57, Dag-Erling Smørgrav wrote:
> > For example, I think C++ exception handling is really poorly suited for
> > low-level code.
>
> Exception handling is required by the standard, even for freestanding
> implementations.
Standards aside, in Darwin, the C++ Apple uses doe
On Tue, Jul 11, 2006 at 10:45:52PM +0800, [EMAIL PROTECTED] wrote:
> Just as you said, C++ is more complicated than C. However, without
> C++ exception and other advanced features, it hasn't brought much
> complexity to C++ runtime library. Early C++ compiler even translates
> C++ code into C code
[EMAIL PROTECTED] writes:
> Dag-Erling [iso-8859-1] Sm grav wrote:
>
>> [EMAIL PROTECTED] writes:
>>> But "-ffreestanding" doesn't work with C++.
>> While the C++ standard does define hosted and freestanding
>> implementations, its definition is different from (and less useful
>> than) that in t
Dag-Erling [iso-8859-1] Sm grav wrote:
[EMAIL PROTECTED] writes:
But "-ffreestanding" doesn't work with C++.
While the C++ standard does define hosted and freestanding
implementations, its definition is different from (and less useful
than) that in the C standard. For instance, the C++ sta
Václav Haisman <[EMAIL PROTECTED]> writes:
> Binary compatibility is always a problem, no mater the language used.
> Besides, doesn't the FreeBSD kernel build system always compile all
> modules?
It can be configured in make.conf if you want only a subset of modules.
> Deciding that some feature
在 2006-07-11二的 16:13 [EMAIL PROTECTED]
[...]
> I agree with you. Firstly, we may keep up with OpenDarwin, just as
> what's on
>
> http://developer.apple.com/documentation/DeviceDrivers/Conceptual/IOKitFundamentals/Features/chapter_2_section_6.html
>
>
> At the same time, we may port/rewri
[EMAIL PROTECTED] writes:
> But "-ffreestanding" doesn't work with C++.
While the C++ standard does define hosted and freestanding
implementations, its definition is different from (and less useful
than) that in the C standard. For instance, the C++ standard requires
the existence of abort(), ate
Dag-Erling [iso-8859-1] Sm grav wrote:
[EMAIL PROTECTED] writes:
But prior to long-term discussion, please commit my 4 patches
firstly. They are nearly CPP-independent and do no harm to current
FreeBSD kernel.
We don't do the kind of changes you propose without discussion.
--- kern.mk.or
[EMAIL PROTECTED] writes:
> But prior to long-term discussion, please commit my 4 patches
> firstly. They are nearly CPP-independent and do no harm to current
> FreeBSD kernel.
We don't do the kind of changes you propose without discussion.
> --- kern.mk.orig Fri Jun 30 05:15:25 2006
> +++
Václav Haisman <[EMAIL PROTECTED]> writes:
> Deciding that some features are bad beforehand, before you evaluate
> them is IMO bad idea. Let interested people write a bunch of C++
> modules with the complete language before deciding on what shouldn't
> be used.
It's not that simple. The complete
Julian Elischer wrote, On 10.7.2006 21:45:
> [EMAIL PROTECTED] wrote:
>
>> Joseph Koshy wrote:
>>
I would write my kernel module in C++, just like IOKit
of OpenDarwin. Thus, all conflicts against C++ in current
FreeBSD kernel source must be swept out firstly.
>>>
> While the idea
[EMAIL PROTECTED] wrote:
> Joseph Koshy wrote:
>
>>
>>> I would write my kernel module in C++, just like IOKit
>>> of OpenDarwin. Thus, all conflicts against C++ in current
>>> FreeBSD kernel source must be swept out firstly.
>>
>>
While the idea of using C++ in the kernel made me very nervous,
I
Joseph Koshy wrote:
I would write my kernel module in C++, just like IOKit
of OpenDarwin. Thus, all conflicts against C++ in current
FreeBSD kernel source must be swept out firstly.
Your patch is missing the following:
- runtime support for static constructors and destructors
- runtime supp
67 matches
Mail list logo
