From: Roy S. <roy...@ic...> - 2009-02-12 03:43:04
|
On Wed, 11 Feb 2009, Vijay S. Mahadevan wrote: >> There was one spot you missed that should have been converted to >> subdomain_id, and one spot you converted that shouldn't have been >> (although I'm not surprised, it was in a subdomain-handling function >> and tricked me too before I ran a class object test through it). > > Roy, just curious as to which source file this was happening. It is > much easier for me to make the change in to my source directly rather > than updating and merging the code along with my existing changes. IIRC The spot you didn't convert and should have was in mesh_tools; the spot you did but shouldn't have was in boundary_info. But you might just want to do an update and merge; even if you do that conversion and unconversion by hand, the biggest difference from your patch was moving the typedef to a separate header. And if you're getting conflicts from new merges, that's a reason to do them more frequently, not less; the conflicts you get end up being less frequent and easier to resolve. >> I left the typedef as unsigned char for now; if you and Ben want to >> change the default to unsigned int that's fine with me. > > I guess asking to make this configurable with ./configure might be too > much to ask. I'll happily accept a patch, but won't have time to write it myself for a while. > But is there some way to define a flag or something to make this > change with a user defined header. Perhaps something with > preprocessors (#ifdefs) ? Or does it not make sense ? I propose this > because if tomorrow you change some other property in Elem and > typedef it, I would like it to be easy enough to change the > definition to fit my needs. If there is no clean way to do this, do > not worry about it. As long future changes are typedef'd also, I > can modify it accordingly. I'm not sure I understand - now that we've got things down into one typedef that's not even in elem.h, that's about as easy for you to maintain as it'll get without a configure test. And yes, for any future type changes (boundary_id, I'm looking at you) we'll wrap them in a typedef; hunting through the library for every instance of a certain sort of index is too tedious to risk having to do it twice. --- Roy |