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 cl
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.
>
On Thu, Mar 06, 2003 at 03:25:41PM +, José Fonseca wrote:
> David, I don't know exactly if that was your point, but of all ways
> presented here to avoid catching exceptions with the 'new' operator,
> using 'set_new_hander' seems the best. It doesn't requires any include
> for every source file
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 is that it's certainly no more complex than the C sequ
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,
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
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 - op
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. It
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 somethi
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 an
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, rather
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 th
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 i
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).
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 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 s
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
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 linke
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
-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 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++
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.
-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 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. I
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. I
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
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
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
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 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 th
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
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
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
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++.
Jens,
On Tue, Mar 04, 2003 at 10:09:41AM -0700, 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
>
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: Acce
36 matches
Mail list logo
