-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 20, 2006, at 1:04 AM, [EMAIL PROTECTED] pfgshield-
[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 QA section:
The
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 QA 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
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 QA section:
The goal of EC++ is to provide embedded systems programmers with a subset of
C++ that
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
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 longjmp().
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
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
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/catch
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
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 the
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 come
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
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
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 have
--- 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 only
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
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 all
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). While
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 pioneer)
--- 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,
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 for
GTK+?
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
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 of
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, otherwise we
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, for
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
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
[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
+++
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.
---
[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(),
在 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/rewrite C++
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 features are
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++
[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 the C standard.
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
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 does not
(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++
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
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);
: int
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't
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 be
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++
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 exercise (if you
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
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 to port
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,
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
:
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 require
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
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 require device
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:
: : and OS X
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 *myBar;
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
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
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:
Just as
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 created for
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. About the
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 deciding
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
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
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 say that
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
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
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
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
[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 have seen some
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 of using C++ in the
67 matches
Mail list logo
