Re: [Dri-devel] C++ Framework Concern
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 - operator new() will return a NULL if the object cannot be created, unless you use set_new_hander() to proved a callback for OOM conditions. Then, it will call your handler function first. I don't find it very onerous in my coding to say foo = new thing; if (!foo) --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] C++ Framework Concern
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 is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] C++ Framework Concern
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 course, in some situations. I do embedded C++ using GCC for a living - operator new() will return a NULL if the object cannot be created, unless you use set_new_hander() to proved a callback for OOM conditions. Then, it will call your handler function first. I don't find it very onerous in my coding to say foo = new thing; if (!foo) I've read about set_new_handler and the default behaviour of the 'new' operator when allocationg fails is actually (based on http://www.roguewave.com/support/docs/sourcepro/stdlibref/operatornew.html ): - see if there is a handler (previously specified with set_new_handler): successive calls to the handler and allocation tries until the handler fails to return (aborts) or the allocation succeeds - if it's a no_throw version: returns NULL - if it's the regular version: throws std::bad_alloc. 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 where 'new' is used, and also avoids duplicating the NULL check (already done internally by new) in every allocation. The only bad thing is that we can't tell when an allocation failed, but the out-of-memory condition shouldn't appear in practice, and I'd rather have to fire gdb to find that out, than having to write if(!(foo = new ..) == NULL) ... around everywhere. Thanks. José Fonseca __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] C++ Framework Concern
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 is that it's certainly no more complex than the C sequence, then you're obviously right ;) The problem if you have an operator new implementation that doesn't throw is that it becomes painful to deal with failure in constructors (which are a pain in the ass anyway, but at least _can_ be dealt properly with exceptions). The workaround would have to have that operator new basically try/catch around the constuctor chain call (in place new) and return NULl when that fails, though it doesn't provide very expressive error code. I tend to understand why Apple dumped the constructor approach as much as possible and added a separate init() method to all their classes Ben. --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] C++ Framework Concern
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 classes having a fallible constructor? --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] C++ Framework Concern
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 investing in this transition to C++? I don't think the issue is readability so much. I think the bigger issue is the ability to share code among the drivers. Looking at the code for the various CreateContext functions, the code is about 60% between mga, radeon, r200, and r128 drivers. I assume that the mach64 and savage drivers will likely be the same. I haven't looked at the i810 and i830 drivers, but they probably follow similar form. If we could share a bunch of that code among four or five drivers, it would save a LOT of duplicated code. Are you saying that C++ somehow allows for more code sharing between drivers than straight ANSI C? I can buy into a statement that, due to C++'s encouragement of OOP behaviour, shared code can become more prevalant in C++ than in C. However, I do not hold with the view that C++ intrinsically allows for more code sharing. If you're going to rewrite the code in C++ to facilitate code sharing... you could just as well rewrite the code in better ANSI C to facilitate code sharing. [ Mind you, technically feasible, and someone with experience doing it are two separate things. As I mentioned in the IRC chat to someone, perhaps the real issue in your comparison of C++ and C code, is that you havent actually SEEN any well-written C code :- ] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] C++ Framework Concern
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 is the best suited language for every task out there? I've already programmed in Assembly, Basic, C, C++, Fortran, Lisp, Matlab, Pascal, Python, and although some of these have little more to offer than a different syntax, there are others which can considerably aid the developer for certain tasks (optimization, simplicity, numeric efficiency, small footprint interpreted language, OOP, rapid application development, etc.) The C language clearly outstands from the remaining because it can be used for low-level programming and for the availability of compilers for virtually any platform, but C++ can do everything that is done in C, plus facilitates OOP, and thanks to gcc there is no lack of C++ compilers for our target platforms. For the record, the languages I code most nowadays are C and Python. I can buy into a statement that, due to C++'s encouragement of OOP behaviour, shared code can become more prevalant in C++ than in C. However, I do not hold with the view that C++ intrinsically allows for more code sharing. If you're going to rewrite the code in C++ to facilitate code sharing... you could just as well rewrite the code in better ANSI C to facilitate code sharing. You must think were are all very naive to expect that we'll only reimplement the drivers in a new language... Did you bother reading the examples I gave in the Doxygen generated docs before saying this nonsense? I don't think so, because most of few classes I tryied to show where *exactly* new objects which have no parallel in the current C code and will substantially improve code reusability. Although the concepts aren't new, there are no objects in the current C code for things like vertex formats or DMA engines, and state atoms only exist in Radeon and have not been generalized, and this is just a small part. Of course all this could be done in C, but it *isn't* in my POV the appropriate language for the task. It would take more effort coding (both the framework and the drivers) using C and I see no reason why not use C++. José Fonseca __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] C++ Framework Concern
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 we agree to use a reasonable subset of C++, we should have a good chance. This is probably something we should bring up on [EMAIL PROTECTED] sooner rather than later. I don't know, Ian... It will only start a flame where people would step in to say how C++ is the holy grail or how C++ is evil... How can it not be, if people in [EMAIL PROTECTED] have nothing else to base their opinions? A 3D driver is a complex beast - I myself can't yet picture how everything detail will fit in the final picture, most people here on DRI devel can't imagine either just by my descriptions, so how can the people of [EMAIL PROTECTED] understand the need to use C++ in a 3D driver? On the other hand, if we manage to write something which is actually used and yields significant advantages, how can they possibly dismiss it? Also I think we should choose the C++ subset used (or in better words, the C++ programming paradigms used) on a technical basis, and that alone. If you want, you can ping opinions on the [EMAIL PROTECTED], but if that turns into a flame on the C++ language I'll bail out immediately - it's pointless to argue such things and I'd rather invest that energy in coding. I'd really prefer waiting to have something to show. Finally, there are a few XFree86 developers in this list. I assume that if they haven't made any comment so far it's because they're also waiting to see. After all, we all read everyday things like the killer app Linux needs is.., X is deprecated, why not use language-I'm-learning-on-my-degree, it's great!, which are completely detached from reality. This is not what I want. José Fonseca __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] C++ Framework Concern
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 fuddy duddy class (as Keith calls it) in that I'm not fluent in C++. 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 we agree to use a reasonable subset of C++, we should have a good chance. This is probably something we should bring up on [EMAIL PROTECTED] sooner rather than later. Concern #2: As a driver writer, I prefer looking at C and thinking in terms of the machine transactions that are likely to take place based on that code. C++ code tends to hide that level of detail for me and I don't feel like I've got a strong grip on the various machine transactions when using it. The hidden detail tends to come from three things: function / operator overloading, inheritance, and templates. I don't think the first or third items will particularly come into play. We may use C++ templates, but not in the usual, generic programming sort of way. DRI already uses a lot of inheritance in the C code, so I don't think that's a problem. 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++. 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 language's standard library since it's already debugged and optimized)--you could write your own customized allocators for it that handle the different mm mappings. This could allow greater compartmentalization--only a few would have to worry about _writing_ the allocators, the rest of the devs would only have to know which one to use when rather than understand all their icky details. Also, how many containers are you going to hand code before deciding that a generalized, reusable solution would save you all the trouble? Why discount operator and function overloading so quickly? The greater readability due to the expanded namespace alone can be nice. Combine that with namespaces and you have an even easier time at choosing a good, simple, descriptive name for each function. I understand there may be portions of C++ that you feel don't belong in the solution (exceptions, many of the things already mentioned above and previously on the list)--but many of these items may actually be integral to the optimal solution. 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 C++ solves elegantly, then don't use it--but don't hobble it before, limiting how the tool will be allowed to solve it. Solve the problem with the tool and then look back and see what portions of the tool were and were not used, then if necessary, cut off what was not useful. I admit that I am probably closely aligned with Bjarne Stroustrup's philosophy as referenced earlier. Nick --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] C++ Framework Concern
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), please keep in mind that most people will use gcc for XFree86, and worry more about specific gcc issues and performance than about abstract issues. Also, keep in mind that at both an upper _and_ a lower level you will end up having to integrate with C anyway. In particular, avoid overly virtual code (horrible performance if you have dynamic casts etc) and exceptions (bad code generation, and a fundamental inability to work with high-performance C code). But templates are potentially a great idea, since that is something that is easily very ugly in C (realize that the DRM(xxx)() thing with type defines etc for the kernel is nothign but a C template implementation. It's certainly not very readable, but it's better than the alternatives, and C++ is not an option in most kernels). 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. Linus --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] C++ Framework Concern
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++. 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: 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 we agree to use a reasonable subset of C++, we should have a good chance. This is probably something we should bring up on [EMAIL PROTECTED] sooner rather than later. Concern #2: As a driver writer, I prefer looking at C and thinking in terms of the machine transactions that are likely to take place based on that code. C++ code tends to hide that level of detail for me and I don't feel like I've got a strong grip on the various machine transactions when using it. The hidden detail tends to come from three things: function / operator overloading, inheritance, and templates. I don't think the first or third items will particularly come into play. We may use C++ templates, but not in the usual, generic programming sort of way. DRI already uses a lot of inheritance in the C code, so I don't think that's a problem. 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++. 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 language's standard library since it's already debugged and optimized)--you could write your own customized allocators for it that handle the different mm mappings. This could allow greater compartmentalization--only a few would have to worry about _writing_ the allocators, the rest of the devs would only have to know which one to use when rather than understand all their icky details. Also, how many containers are you going to hand code before deciding that a generalized, reusable solution would save you all the trouble? 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. But does C++ use the library behind your back? AFAIK g++ alway implicitly links with libstdc++. Why discount operator and function overloading so quickly? The greater readability due to the expanded namespace alone can be nice. Combine that with namespaces and you have an even easier time at choosing a good, simple, descriptive name for each function. I understand there may be portions of C++ that you feel don't belong in the solution (exceptions, many of the things already mentioned above and previously on the list)--but many of these items may actually be integral to the optimal solution. 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 C++ solves elegantly, then don't use it--but don't hobble it before, limiting how the tool will be allowed to solve it. Solve the problem with the tool and then look back and see what portions of the tool were and were not used, then if necessary, cut off what was not useful. I admit that I am probably closely aligned with Bjarne Stroustrup's philosophy as referenced earlier. I agree, mostly. But to me it doesn't feel right to use the STL in a driver. But maybe that's just supersticion. Nick Regards, Felix __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] C++ Framework Concern
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 be wrong, but as I understood it C++ already provides a non-exception
version of new ('nothrow' or similar) that will instead return 0 on failure
for just this case. This avoids combining malloc with placement newsall
over. The only disadvantage is having to check for 0 returns everwhere again
rather than having a single exception catcher at some high-level entry point.
Also, 16.6 of the C++ FAQ Lite shows how you can easily replace new's error
handler. You wouldn't even have to worry about testing each new for 0 return
everywhere--just handle it there and you're back to C++ clean-code goodness.
Nick
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] C++ Framework Concern
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 save by investing in this transition to C++? I don't think the issue is readability so much. I think the bigger issue is the ability to share code among the drivers. Looking at the code for the various CreateContext functions, the code is about 60% between mga, radeon, r200, and r128 drivers. I assume that the mach64 and savage drivers will likely be the same. I haven't looked at the i810 and i830 drivers, but they probably follow similar form. If we could share a bunch of that code among four or five drivers, it would save a LOT of duplicated code. 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 lib/GL/mesa/src/drv/common/texmem.h there is a structure called driTextureObject. In lib/GL/mesa/src/drv/radeon/radeon_context.h there is a structure called radeon_tex_obj that has a driTextureObject as it's first element. Basically, I'm using inheritance here. The problem is that everywhere I want to use something from the base class I have to say tObj-base.foo. There's also no easy way to over-ride functions from the base. There are a number of structures, like the *_context structures, where we could do this. It's possible to do in C, but in C++ it's less syntactically painful. --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] C++ Framework Concern
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 think if we agree to use a reasonable subset of C++, we should have a good chance. This is probably something we should bring up on [EMAIL PROTECTED] sooner rather than later. I don't know, Ian... It will only start a flame where people would step in to say how C++ is the holy grail or how C++ is evil... How can it not be, if people in [EMAIL PROTECTED] have nothing else to base their opinions? A 3D driver is a complex beast - I myself can't yet picture how everything detail will fit in the final picture, most people here on DRI devel can't imagine either just by my descriptions, so how can the people of [EMAIL PROTECTED] understand the need to use C++ in a 3D driver? On the other hand, if we manage to write something which is actually used and yields significant advantages, how can they possibly dismiss it? And there's the problem. Do we ask permission or beg forgiveness? I would sure hate to do a whole bunch of work, improve the drivers, and have it all rejected. The people that control what gets into XFree86 are on devel, not dri-devel (AFAIK). Also I think we should choose the C++ subset used (or in better words, the C++ programming paradigms used) on a technical basis, and that alone. 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 system. If I'm not mistaken we have seven processors families (x86, x86-64, IA-64, Alpha, SPARC, PPC32, and PPC64) that we either support now or in the near future and three operating systems (Linux, Solaris, and *BSD) that we either support now or in the near future. If I'm not mistaken, we also have to support several versions of GCC and other native compilers (Intel's compiler, Digital/Compaq/HP's compiler for Alpha, Sun's compiler for SPARC, IBM's compiler for PPC, and perhaps Watcom, too). The technical decision of will this feature make the driver better? doesn't have to be made a-priori, but the decision of is this feature supported WELL on all of the platforms we have to consider? does. In general, I don't think C++ compilers are as mature as C compilers. It's a lot better than it was a few years ago, but it's still an issue. ESPECIALLY for people writing critical software...like drivers. If you want, you can ping opinions on the [EMAIL PROTECTED], but if that turns into a flame on the C++ language I'll bail out immediately - it's pointless to argue such things and I'd rather invest that energy in coding. I'd really prefer waiting to have something to show. I agree 100%. At the same time, that can be a good litmus test. If it instantly degrades into flames, then now is probably not the right time. All that said, I would *REALLY* like to see this happen. I would especially like to see this happen quickly so that some of the new drivers (Savage i740) can make use of it from the get-go. Having drivers that ONLY exist using the new framework would probably help our case. Esp. if we can show that the drivers took less time to develop because of the C++ framework. :) --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] C++ Framework Concern
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 lib/GL/mesa/src/drv/common/texmem.h there
is a structure called driTextureObject. In
lib/GL/mesa/src/drv/radeon/radeon_context.h there is a structure called
radeon_tex_obj that has a driTextureObject as it's first element.
Basically, I'm using inheritance here. The problem is that everywhere I
want to use something from the base class I have to say
tObj-base.foo. There's also no easy way to over-ride functions from
the base.
..
There are a number of structures, like the *_context structures, where
we could do this. It's possible to do in C, but in C++ it's less
syntactically painful.
Given the abundance of macros already in use in dri, I would think you
would just define a macro for that sort of stuff ;-)
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 it. So
[quick-n-dirty illustration for discussion purposes]
struct dritexture{
int baseval;
};
struct radeontexture {
int baseval;
int radeonextraval;
};
Also, since functions are not part of the object, I dont see where
overriding functions comes into play. If you dont want to use a base
function, you just call a radeon-specific one?
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] C++ Framework Concern
-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 might be, of course, in some situations. I always thought that by the time new failed due to lack of memory you had bigger problems than that in any case... Well, that's what we assume in KDE and it doesn't seem to cause any problems. Perhaps with XFree86 it's different. - -- Cheers, Chris Howells -- [EMAIL PROTECTED], [EMAIL PROTECTED] Web: http://chrishowells.co.uk, PGP ID: 33795A2C KDE: http://www.koffice.org, http://printing.kde.org, http://usability.kde.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE+ZkWDF8Iu1zN5WiwRAiXgAKCgsuKXb30raSRH2o+XyxaUuo+JjwCfTH8M nqWYPshvOX/E6XSqiPTx/Jc= =PXmo -END PGP SIGNATURE- --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] C++ Framework Concern
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. But does C++ use the library behind your back? AFAIK g++ alway implicitly links with libstdc++. Yes, there might be ABI issues, but doesn't the DRI already worry about binary compatibility issues? Also, you can avoid linking with libstdc++ by invoking gcc as gcc rather than g++. This is what MySQL does. But then, iirc, you have to explicitly implement a new method for every class which becomes really tedious and error prone. There are probably other facilities missing then as well. I don't see how this would really be an issue to concern about. Each distro is going to produce their own packages anyways, which they already have to build with the compiler they shipped with. [snip] I agree, mostly. But to me it doesn't feel right to use the STL in a driver. But maybe that's just supersticion. Why does it not feel right? It's just type-safe code reuse. The question as I see it is who would you rather have handle the code bloat--the compiler or the coder. You either only write the template once and reuse it for different types letting the compiler generate the differences, or the developer himself must rewrite the same or similar code for each different type and maintain all of it. And in the case of the STL, if the problem has already been solved, coded, and debugged, then why not use it? It is extremely flexible and customizeable. I'm not saying that the STL necessarily has solutions for any of the problems that will be encountered in this framework. If it doesn't then that's the way it is. If it does, then unless there's some unsurmountable or really practical reason not to, why reinvent the wheel? Nick --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] C++ Framework Concern
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 people decide to go with C++ (which I don't disagree with per se), please keep in mind that most people will use gcc for XFree86, and worry more about specific gcc issues and performance than about abstract issues. I know that some C++ features have impact on performance. Exceptions as you mention below, is mostly an consensual one. Other aren't that consensual. And arguments in the line of Embedded C++ or Java doesn't support it don't move me much. Both the Embedded C++ and Java were designed with philosophies which have nothing to do with the OpenGL driver reality (the EC++ rationale clearly states they wanted a specification as small as possible). More importantly, as you said above, gcc will be used, and _not_ an EC++ or java compiler. Also, keep in mind that at both an upper _and_ a lower level you will end up having to integrate with C anyway. In particular, avoid overly virtual code (horrible performance if you have dynamic casts etc) and exceptions (bad code generation, and a fundamental inability to work with high-performance C code). 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. On the other hand, there won't be need of dynamic casts: the driver derived classes are expected to work only with other derived classes from the same driver, i.e., a Radeon::VertexFormat member function can be sure that a Mesa::Context* is actually a Radeon::Context*. This means that drivers should never derive classes from another driver, but always from the the Generic driver. If any piece of code in a driver is useful for others drivers, then it should be put on the Generic driver to be derived by all interested drivers. But templates are potentially a great idea, since that is something that is easily very ugly in C (realize that the DRM(xxx)() thing with type defines etc for the kernel is nothign but a C template implementation. It's certainly not very readable, but it's better than the alternatives, and C++ is not an option in most kernels). 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. Thanks for pointing that out. I've made a search on Goggle and found this article, http://www.palmoswerks.com/stories/storyReader$15 , which proposes a very clean solution - reimplement the default 'new' and 'delete' operators to not throw any exceptions. José Fonseca __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] C++ Framework Concern
-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 system. If I'm not mistaken we have seven processors families (x86, x86-64, IA-64, Alpha, SPARC, PPC32, and PPC64) that we either support now or in the near future and three operating systems (Linux, Solaris, and *BSD) that we either support now or in the near future. If I'm not mistaken, we also have to support several versions of GCC and other native compilers (Intel's compiler, Digital/Compaq/HP's compiler for Alpha, Sun's compiler for SPARC, IBM's compiler for PPC, and perhaps Watcom, too). While I know nothing about the working of DRI (I hate C ;) ), don't forget that cross platform C++ is not _that_ impossible -- KDE does a good job of being compilable on a similar list of platforms to those above. - -- Cheers, Chris Howells -- [EMAIL PROTECTED], [EMAIL PROTECTED] Web: http://chrishowells.co.uk, PGP ID: 33795A2C KDE: http://www.koffice.org, http://printing.kde.org, http://usability.kde.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE+ZkteF8Iu1zN5WiwRAnX2AJ9Ma+BZgTox/7H+eqBQt0oHcoBNwwCeKpWR dZTlRap9esnkCm2cKsZDZuI= =7GM7 -END PGP SIGNATURE- --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] C++ Framework Concern
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 language's standard library since it's already debugged and optimized)--you could write your own customized allocators for it that handle the different mm mappings. This could allow greater compartmentalization--only a few would have to worry about _writing_ the allocators, the rest of the devs would only have to know which one to use when rather than understand all their icky details. Also, how many containers are you going to hand code before deciding that a generalized, reusable solution would save you all the trouble? 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. STL won't be necessary. So far I haven't come across anything which could use the STL - the data structures used by the drivers are either too simple to justify using the STL, or too specific that justify dedicate implementations. I don't much about libstdc++'s STL implementation, but probably also requires exception support. 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 compiled code unless the source actually uses the STL. Most C++ support code for such as global constructors, exceptions and RTTI are outside STL. José Fonseca __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] C++ Framework Concern
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 without the standard library. I mean avoiding things like std::cout is no problem. But does C++ use the library behind your back? AFAIK g++ alway implicitly links with libstdc++. Yes, there might be ABI issues, but doesn't the DRI already worry about binary compatibility issues? If you're referring to the libxaa and xserver problems with the binary snapshots, that's a completely different story as Xserver, libxaa and DRI belong together. So it's no problem to include a new xserver and libxaa in the snapshot or offer it for download separately. You can't do that with STL. Also, you can avoid linking with libstdc++ by invoking gcc as gcc rather than g++. This is what MySQL does. But then, iirc, you have to explicitly implement a new method for every class which becomes really tedious and error prone. There are probably other facilities missing then as well. I don't see how this would really be an issue to concern about. Each distro is going to produce their own packages anyways, which they already have to build with the compiler they shipped with. Yes, but you still have the problem with binary snapshots. Another way would be to link the driver statically. If you use only a small subset of the standard library the footprint should not be to dramatic. The template instances will be in the drivers anyway, no matter whether you link statically or dynamically. [snip] I agree, mostly. But to me it doesn't feel right to use the STL in a driver. But maybe that's just supersticion. Why does it not feel right? It's just type-safe code reuse. The question as I see it is who would you rather have handle the code bloat--the compiler or the coder. You either only write the template once and reuse it for different types letting the compiler generate the differences, or the developer himself must rewrite the same or similar code for each different type and maintain all of it. 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 is a great abstraction, and if you need more advanced container types and don't *want* to worry about allocation issues, than it's a great tool. But for the purpose of a driver I'd prefer implementing a linked list as a linked list myself. And in the case of the STL, if the problem has already been solved, coded, and debugged, then why not use it? It is extremely flexible and customizeable. I'm not saying that the STL necessarily has solutions for any of the problems that will be encountered in this framework. If it doesn't then that's the way it is. If it does, then unless there's some unsurmountable or really practical reason not to, why reinvent the wheel? Regards, Felix __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] C++ Framework Concern
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 compiled code unless the source actually uses the STL. Most C++ support code for such as global constructors, exceptions and RTTI are outside STL. AFAIK STL is part of the standard library by now. So the question is not really whether we use STL but whether we use the standard library. Anyway, if you use only the basic support code then linking the standard library statically should be no problem WRT binary size. José Fonseca __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] C++ Framework Concern
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 projects that utilize our code. This is probably the biggest issue. I think if we agree to use a reasonable subset of C++, we should have a good chance. This is probably something we should bring up on [EMAIL PROTECTED] sooner rather than later. I don't know, Ian... It will only start a flame where people would step in to say how C++ is the holy grail or how C++ is evil... How can it not be, if people in [EMAIL PROTECTED] have nothing else to base their opinions? A 3D driver is a complex beast - I myself can't yet picture how everything detail will fit in the final picture, most people here on DRI devel can't imagine either just by my descriptions, so how can the people of [EMAIL PROTECTED] understand the need to use C++ in a 3D driver? On the other hand, if we manage to write something which is actually used and yields significant advantages, how can they possibly dismiss it? And there's the problem. Do we ask permission or beg forgiveness? I would sure hate to do a whole bunch of work, improve the drivers, and have it all rejected. The people that control what gets into XFree86 are on devel, not dri-devel (AFAIK). I really hate to have to discuss this kind of hypothetical scenarios involving people actions, but: - if in the remote chance that the C++ framework sucks big time and doesn't deliver the expected goods: I don't expect anything else than blunt rejection from XFree86.org. Hopefully the OOP conceptualization made is useful enough to be worth to reimplement it in plain C, and a C driver framework can be made. (PS: I've more faith in winning the jackpot than this to happen ) - if in the chance that C++ framework delivers the expected goods, but it's rejected by XFree86.org: I don't care. I'll keep working on the framework and write drivers for it and make them available. Alternatives are a good thing. - in the more likely scenario that the C++ framework is everything it promises and is accepted by XFree86: great! Next step: world domination! - if I actually *win* the jackpot: I never get a job and spend the rest of my life writting open-source software...! (PS: Unfortunatly I don't play... so a life of dull mechanical engineer by day and crazy OSS developer by night awaits me ;-) My point with this is that, at least as far as 3D drivers are concerned, the objectivity of having a good work done is much more important that the subjectivity of acceptance. If you want, you can ping opinions on the [EMAIL PROTECTED], but if that turns into a flame on the C++ language I'll bail out immediately - it's pointless to argue such things and I'd rather invest that energy in coding. I'd really prefer waiting to have something to show. I agree 100%. At the same time, that can be a good litmus test. If it instantly degrades into flames, then now is probably not the right time. All that said, I would *REALLY* like to see this happen. I would especially like to see this happen quickly so that some of the new Hurries are a no-no, especially in OSS development. But as I said in IRC I hope in a month to have the Mesa wrapper stable. At that point things can go faster. (BTW, I have to start cutting on emails, as they're cutting my time to develop... :-/) drivers (Savage i740) can make use of it from the get-go. Having drivers that ONLY exist using the new framework would probably help our case. Esp. if we can show that the drivers took less time to develop because of the C++ framework. :) Agreed. José Fonseca __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] C++ Framework Concern
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 virtualization - when the overhead is just a function pointer. It's things like dynamic casts etc that you should avoid like the plague. On the other hand, there won't be need of dynamic casts: the driver derived classes are expected to work only with other derived classes from the same driver, i.e., a Radeon::VertexFormat member function can be sure that a Mesa::Context* is actually a Radeon::Context*. This means that drivers should never derive classes from another driver, but always from the the Generic driver. If any piece of code in a driver is useful for others drivers, then it should be put on the Generic driver to be derived by all interested drivers. Yes. 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. Thanks for pointing that out. I've made a search on Goggle and found this article, http://www.palmoswerks.com/stories/storyReader$15 , which proposes a very clean solution - reimplement the default 'new' and 'delete' operators to not throw any exceptions. I'd almost go with the std::nothrow approach even if it's syntactically a bit more awkward (maybe that can be fixed with a macro). It's not entirely unlikely that the compiler may have special case support for its internal new implementation. Some gcc person might be able to tell you. Linus --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] C++ Framework Concern
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 is a great abstraction, and if you need more advanced container types and don't *want* to worry about allocation issues, than it's a great tool. But for the purpose of a driver I'd prefer implementing a linked list as a linked list myself. Perhaps it's bloated, perhaps not. One of the points I tried to make earlier is that the STL is designed so that you *can* specify allocation policies. The fact that it was designed specifically to provide such an option places it higher on my list of reusable code. If it solves some of the problems involved (which Jose thinks it probably will not), it is at least possible to transparently (to the end coder) alter the underlying allocation mechanism to whatever is necessary. That, imo, is truly powerful reuseablility. And in the case where new container types are written instead, yes, templatized would be the way to go, and I would highly suggest borrowing from the allocation mechinisms in the STL to achieve similar flexibility. A very nice thing is that you could write your own templatized linked-list, and provide iterator classes such that it has the same feel and use as the rest of the stdlib that people are already familiar with. Then you leave it possible to use the stdlib templatized algorithms on it as well if they happen to suit... Nick --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] C++ Framework Concern
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 it. So
[quick-n-dirty illustration for discussion purposes]
struct dritexture{
int baseval;
};
struct radeontexture {
int baseval;
int radeonextraval;
};
So what happens when you want to refactor and move data out of
radeontexture and into dritexture? Then the functions that operate on
dritexture will possibly break.
Also, since functions are not part of the object, I dont see where
overriding functions comes into play. If you dont want to use a base
function, you just call a radeon-specific one?
That's exactly the problem! If you change from using the base
function to using a derrived function, you have to touch the code in
every single place that used the base function. If you miss one, you
have a bug...a bug that may go a long time unnoticed.
Part point of this exercise is to make it easier to refactor code later.
Doing things that make it easier to create hidden, latent bugs is
*not* helpful! :)
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] C++ Framework Concern
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 encapsulating it. So
[quick-n-dirty illustration for discussion purposes]
struct dritexture{
int baseval;
};
struct radeontexture {
int baseval;
int radeonextraval;
};
So what happens when you want to refactor and move data out of
radeontexture and into dritexture? Then the functions that operate on
dritexture will possibly break.
how so?
If you have a non-radeon card driver using dritexture, it will ignore
the extra field added. Or, it will keep using the same base functions,
which, if you done the refactoring' right, will be a transparent change.
If you have a radeon card driver routine that previously accessed the
extra field.. it can STILL access the extra field. So what will break?
Also, since functions are not part of the object, I dont see where
overriding functions comes into play. If you dont want to use a base
function, you just call a radeon-specific one?
That's exactly the problem! If you change from using the base
function to using a derrived function, you have to touch the code in
every single place that used the base function. If you miss one, you
have a bug...a bug that may go a long time unnoticed.
Are you honestly making the argument,
Hunting down places that called RadeonTextureTwiddle, and renaming them
to DriTextureTwiddle, is a difficult operation that can lead to bugs
??
It should be a straightforward excercise to migrate a sub-object function,
into a base-object function, as describe above. If it isnt, there are two
possibilities:
a) It doesnt BELONG as a base object function. case closed.
b) the writer of the sub-object function, did a poor job designing/writing
the sub-object function. In which case, the author needs to be
whipped^H^H^Hreeducated, and made to fix the design.
Only after that is done, should it then be migrated up into the base
object.
in this model, it should not be a bug magnet any more than the
corresponding operation of migrating from a C++ derived class
to a parent class.
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] C++ Framework Concern
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 than encapsulating it. So
[quick-n-dirty illustration for discussion purposes]
struct dritexture{
int baseval;
};
struct radeontexture {
int baseval;
int radeonextraval;
};
So what happens when you want to refactor and move data out of
radeontexture and into dritexture? Then the functions that operate on
dritexture will possibly break.
how so?
If you have a non-radeon card driver using dritexture, it will ignore
the extra field added. Or, it will keep using the same base functions,
which, if you done the refactoring' right, will be a transparent change.
If you have a radeon card driver routine that previously accessed the
extra field.. it can STILL access the extra field. So what will break?
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 checking done by the compiler, seems like a bad call.
If we going to do that, I would rather see it done as either a nested
structure (like driTextureObject) or as a macro:
#define DRI_TEXTURE \
int baseval;
struct radeontexture {
DRI_TEXTURE
int radeonextraval;
};
That eliminates the worry of cut-and-paste errors. What if someone puts
two of the fields from the base in the wrong order? The compiler
won't notice it, and it would be very difficult to detect by inspection.
Bugs like that are the ones that usually take (waste!) a lot of time
to track down.
Also, since functions are not part of the object, I dont see where
overriding functions comes into play. If you dont want to use a base
function, you just call a radeon-specific one?
That's exactly the problem! If you change from using the base
function to using a derrived function, you have to touch the code in
every single place that used the base function. If you miss one, you
have a bug...a bug that may go a long time unnoticed.
Are you honestly making the argument,
Hunting down places that called RadeonTextureTwiddle, and renaming them
to DriTextureTwiddle, is a difficult operation that can lead to bugs
??
It should be a straightforward excercise to migrate a sub-object function,
into a base-object function, as describe above. If it isnt, there are two
possibilities:
a) It doesnt BELONG as a base object function. case closed.
b) the writer of the sub-object function, did a poor job designing/writing
the sub-object function. In which case, the author needs to be
whipped^H^H^Hreeducated, and made to fix the design.
Only after that is done, should it then be migrated up into the base
object.
in this model, it should not be a bug magnet any more than the
corresponding operation of migrating from a C++ derived class
to a parent class.
I'll agree with all of that. However, I was talking about going the
other way around. I meant that replacing driTextureTwiddle with
radeonTextureTwiddle. In the case you were talking about
radeonTextureTwiddle would presumably go away, so the compiler or the
linker will let you know that something is wrong. In the other case,
the code will still compile, link, and run.
You're right. Doing a global search-and-replace *should* be easy. As
an experienced developer, I've seen much simpler things get botched.
How many times have you send cut-and-paste style errors? It's all
pretty easy stuff, but we're still human. It's nice to have a machine
around to tap you on the head and say, Hey stupid! You messed up! :)
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] C++ Framework Concern
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 checking done by the compiler, seems like a bad call.
If we going to do that, I would rather see it done as either a nested
structure (like driTextureObject) or as a macro:
#define DRI_TEXTURE \
int baseval;
struct radeontexture {
DRI_TEXTURE
int radeonextraval;
};
Yes, I was going to suggest that if the topic of typos, etc came up :-
PS:
#define DRI_TEXTURE_STRUCTINFO \
or some such.
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] C++ Framework Concern
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 C++ solves The problem certainly maps into an object model well. It seems to map well into C with classes. Whether you should go further is more the question. C with classes is a tool just like full C++. 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 easier to make it work and look at features conservatively than try and remove them later. Ultimately its sort of irrelevant he who writes the code wins the argument. And rightfully so. --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] C++ Framework Concern
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 easier to make it work and look at features conservatively than try and remove them later. Indeed. Ultimately its sort of irrelevant he who writes the code wins the argument. And rightfully so. True... --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] C++ Framework Concern
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: Acceptance into XFree86, etc. Creating dependencies on C++ compilers could be a big issue for some of the major projects that utilize our code. Concern #2: As a driver writer, I prefer looking at C and thinking in terms of the machine transactions that are likely to take place based on that code. C++ code tends to hide that level of detail for me and I don't feel like I've got a strong grip on the various machine transactions when using it. 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 investing in this transition to C++? Thanks for your consideration of these issues and thanks for all your excellent contributions to the DRI project. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] C++ Framework Concern
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++. 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 we agree to use a reasonable subset of C++, we should have a good chance. This is probably something we should bring up on [EMAIL PROTECTED] sooner rather than later. Concern #2: As a driver writer, I prefer looking at C and thinking in terms of the machine transactions that are likely to take place based on that code. C++ code tends to hide that level of detail for me and I don't feel like I've got a strong grip on the various machine transactions when using it. The hidden detail tends to come from three things: function / operator overloading, inheritance, and templates. I don't think the first or third items will particularly come into play. We may use C++ templates, but not in the usual, generic programming sort of way. DRI already uses a lot of inheritance in the C code, so I don't think that's a problem. 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 investing in this transition to C++? I don't think the issue is readability so much. I think the bigger issue is the ability to share code among the drivers. Looking at the code for the various CreateContext functions, the code is about 60% between mga, radeon, r200, and r128 drivers. I assume that the mach64 and savage drivers will likely be the same. I haven't looked at the i810 and i830 drivers, but they probably follow similar form. If we could share a bunch of that code among four or five drivers, it would save a LOT of duplicated code. Why cut-and-paste when you can just re-use the same code? :) --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
