Linus Torvalds wrote:
Also note that if you don't allow exceptions (which I would _strongly_
encourage), you can't really use new - unless you think it's ok to
SIGSEGV under low-mem circumstances. Which it might be, of course, in some
situations.
I do embedded C++ using GCC for a living -
On Thu, 06 Mar 2003 06:25:32 -0600
David D. Hagood [EMAIL PROTECTED] wrote:
I don't find it very onerous in my coding to say
foo = new thing;
if (!foo)
...
hmm.
foo=malloc(sizeof(thing))
if(!foo)
...
:-)
---
This SF.net email
On Thu, Mar 06, 2003 at 06:25:32AM -0600, David D. Hagood wrote:
Linus Torvalds wrote:
Also note that if you don't allow exceptions (which I would _strongly_
encourage), you can't really use new - unless you think it's ok to
SIGSEGV under low-mem circumstances. Which it might be, of
On Thu, 2003-03-06 at 16:41, Linus Torvalds wrote:
On Thu, 6 Mar 2003, Ian Molton wrote:
foo=malloc(sizeof(thing))
if(!foo)
...
Well, the advantage of new is that it will run all the constructors etc
automatically, so it's potentially a simpler allocation than C.
If your point
On Thursday 06 March 2003 18:23, Benjamin Herrenschmidt wrote:
I tend to understand why Apple dumped the constructor approach as much
as possible and added a separate init() method to all their classes
Isn't that a bit radical? Why not go with the Qt approach, and add a
bool isOpen() to
On Tue, Mar 04, 2003 at 11:10:02PM -0800, Ian Romanick wrote:
Jens Owen wrote:
Concern #3: Readability by the active contributors. I'm not the only
old fuddy duddy in this group of developers. How much readability
time do you figure the young C++ whipper snappers will save by
On Wed, Mar 05, 2003 at 12:30:50AM -0800, Philip Brown wrote:
Are you saying that C++ somehow allows for more code sharing between
drivers than straight ANSI C?
If you think that the used computer language is so irrelevant, then why
is there such a great number of them? Or are you saying that C
On Tue, Mar 04, 2003 at 11:10:02PM -0800, Ian Romanick wrote:
Jens Owen wrote:
Concern #1: Acceptance into XFree86, etc. Creating dependencies on
C++ compilers could be a big issue for some of the major projects that
utilize our code.
This is probably the biggest issue. I think if
On Wednesday 05 March 2003 12:10 am, Ian Romanick wrote:
Jens Owen wrote:
Jose,
I've been on the road for the last few days, so I haven't had a chance
to express my concern for porting the DRI to C++. Please take these
concerns with a grain of salt as I am definitely in the old
On Wed, 5 Mar 2003, Nicholas Leippe wrote:
I agree with Jose--let the features used be chosen on technical merit, not
just somebody's whim. Imo, it is far too premature to just discard this or
that feature of C++.
If people decide to go with C++ (which I don't disagree with per se),
On Wed, 5 Mar 2003 10:24:12 -0700
Nicholas Leippe [EMAIL PROTECTED] wrote:
On Wednesday 05 March 2003 12:10 am, Ian Romanick wrote:
Jens Owen wrote:
Jose,
I've been on the road for the last few days, so I haven't had a chance
to express my concern for porting the DRI to C++.
On Wednesday 05 March 2003 10:31 am, Linus Torvalds wrote:
Also note that if you don't allow exceptions (which I would _strongly_
encourage), you can't really use new - unless you think it's ok to
SIGSEGV under low-mem circumstances. Which it might be, of course, in some
situations.
I may
Philip Brown wrote:
On Tue, Mar 04, 2003 at 11:10:02PM -0800, Ian Romanick wrote:
Jens Owen wrote:
Concern #3: Readability by the active contributors. I'm not the only
old fuddy duddy in this group of developers. How much readability
time do you figure the young C++ whipper snappers will
José Fonseca wrote:
On Tue, Mar 04, 2003 at 11:10:02PM -0800, Ian Romanick wrote:
Jens Owen wrote:
Concern #1: Acceptance into XFree86, etc. Creating dependencies on
C++ compilers could be a big issue for some of the major projects that
utilize our code.
This is probably the biggest issue.
On Wed, Mar 05, 2003 at 10:04:40AM -0800, Ian Romanick wrote:
Philip Brown wrote:
Are you saying that C++ somehow allows for more code sharing between
drivers than straight ANSI C?
It's not so much that it allows it as it makes it less painful. Look at
the texmem-0-0-1 branch. In
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On Wednesday 05 March 2003 17:31, Linus Torvalds wrote:
Also note that if you don't allow exceptions (which I would _strongly_
encourage), you can't really use new - unless you think it's ok to
SIGSEGV under low-mem circumstances. Which it
On Wednesday 05 March 2003 10:54 am, Felix Kühling wrote:
If you use the standard library you have to start worrying about ABI
compatibility issues. How much trouble is it to write C++ code that can
be linked without the standard library. I mean avoiding things like
std::cout is no problem.
On Wed, Mar 05, 2003 at 09:31:09AM -0800, Linus Torvalds wrote:
On Wed, 5 Mar 2003, Nicholas Leippe wrote:
I agree with Jose--let the features used be chosen on technical
merit, not just somebody's whim. Imo, it is far too premature to
just discard this or that feature of C++.
If
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On Wednesday 05 March 2003 18:24, Ian Romanick wrote:
Right. Part of the technical basis that we have to consider is
compiler and operating system support. Linux/x86 may be the main system
that we consider, but it is by no means the only
On Wed, Mar 05, 2003 at 06:54:31PM +0100, Felix Kühling wrote:
On Wed, 5 Mar 2003 10:24:12 -0700 Nicholas Leippe [EMAIL PROTECTED]
wrote:
Templates provide a great deal of power that you may not want to do
without. For instance, you could use portions of the STL (always
good to use the
On Wed, 5 Mar 2003 11:54:56 -0700
Nicholas Leippe [EMAIL PROTECTED] wrote:
On Wednesday 05 March 2003 10:54 am, Felix Kühling wrote:
If you use the standard library you have to start worrying about ABI
compatibility issues. How much trouble is it to write C++ code that can
be linked
On Wed, 5 Mar 2003 19:22:39 +
José Fonseca [EMAIL PROTECTED] wrote:
On Wed, Mar 05, 2003 at 06:54:31PM +0100, Felix Kühling wrote:
[snip]
But does C++ use the library behind your back?
AFAIK g++ alway implicitly links with libstdc++.
I don't believe there is any dependency of STL on
On Wed, Mar 05, 2003 at 10:24:12AM -0800, Ian Romanick wrote:
José Fonseca wrote:
On Tue, Mar 04, 2003 at 11:10:02PM -0800, Ian Romanick wrote:
Jens Owen wrote:
Concern #1: Acceptance into XFree86, etc. Creating dependencies on
C++ compilers could be a big issue for some of the major
On Wed, 5 Mar 2003, [iso-8859-15] José Fonseca wrote:
Actually virtual code will be used extensively, especially in the Mesa
wrapper classes, but there is no other way around it - the current Mesa
C driver callback table has more than 112 functions.
Oh, I agree that you should not avoid
On Wednesday 05 March 2003 12:28 pm, Felix Kühling wrote:
[snip]
The developer may as well implement his own container types as
templates. My point is that STL seems quite bloated and often a bit
clumsy to use. The code I wrote using STL was never exactly well
readable (maybe my own fault). It
Philip Brown wrote:
On Wed, Mar 05, 2003 at 10:04:40AM -0800, Ian Romanick wrote:
Also, rather than containing the struct, you could do what is done already
in the drm level, with drm_map_t vs drm_local_map_t (and all over the X
server code), and just extend the struct, rather than encapsulating
On Wed, Mar 05, 2003 at 01:08:52PM -0800, Ian Romanick wrote:
Philip Brown wrote:
Also, rather than containing the struct, you could do what is done already
in the drm level, with drm_map_t vs drm_local_map_t (and all over the X
server code), and just extend the struct, rather than
Philip Brown wrote:
On Wed, Mar 05, 2003 at 01:08:52PM -0800, Ian Romanick wrote:
Philip Brown wrote:
Also, rather than containing the struct, you could do what is done already
in the drm level, with drm_map_t vs drm_local_map_t (and all over the X
server code), and just extend the struct,
On Wed, Mar 05, 2003 at 02:36:21PM -0800, Ian Romanick wrote:
I suppose that it is doable, but it just seems wrong. Doesn't this just
boil down to inheritance by conincidence? Expecting each driver to
duplicate the same data structures and add their unique data onto the
end, without any
In short, I don't see why everyone is so keen to accept C++ but only if it is
somehow hobbled from the onset? C++ is a tool. Tools work best when the
right one is chosen for the job, the tip is sharp, and the handle is not
splintered or cut off. If the problem does not map into something
On 06 Mar 2003 01:05:05 +
Alan Cox [EMAIL PROTECTED] wrote:
I'd argue strongly in favour of the former or a C with structs for the
virtual operation sets for performance reasons, and because its easier
for embedded devices than hauling in the entire C++ and STL class
libraries. Its much
Jose,
I've been on the road for the last few days, so I haven't had a chance
to express my concern for porting the DRI to C++. Please take these
concerns with a grain of salt as I am definitely in the old fuddy duddy
class (as Keith calls it) in that I'm not fluent in C++.
Concern #1:
Jens Owen wrote:
Jose,
I've been on the road for the last few days, so I haven't had a chance
to express my concern for porting the DRI to C++. Please take these
concerns with a grain of salt as I am definitely in the old fuddy duddy
class (as Keith calls it) in that I'm not fluent in C++.
33 matches
Mail list logo
