|
From: Geoff H. <hut...@me...> - 2002-06-03 15:16:08
|
> Thanks for your help both,
Sorry for not responding earlier--my net connection has been flaky.
> If endModify() is going to transform the information then it is important
> to highlight what it does and whether it is controllable. Maybe there
> should be something like:
>
> endModify(endModifyOptions)
Well, documentation is admittedly a problem, but unfortunately it's not
one that can be resolved quickly.
>>I see a design problem. Could an OBAtom exist without a parent molecule?
>>If the answer is YES then the source MUST be modified for this situation. For
>>example OBAtom::x() should become
>>or something similar
No, I agree. I don't think the OE folks consider this possiblity when they
wrote the code. If this code was what you referred to in your previous
message, I misunderstood.
> ReadFOO and WriteFOO it could be useful to give a ReadDummy and WriteDummy
> that shows how to do it safely!
I guess I'm a little unclear on this--for one, different file formats have
their own quirks. So it's hard to cover a useful amount in an example
format. But certainly there are simple examples like ghemical.cc or xyz.cc
that seem like they'd already be a ReadDummy/WriteDummy example:
xyz.cpp:
atom = mol.NewAtom();
x = atof((char*)vs[1].c_str());
y = atof((char*)vs[2].c_str());
z = atof((char*)vs[3].c_str());
atom->SetVector(x,y,z); //set coordinates
//set atomic number
atom->SetAtomicNum(etab.GetAtomicNum(vs[0].c_str()));
>>The coordinates are stored in a parentless atom (am I wrong?), _c is null so
>>they are stored in _v. But GetX() calls x() which reads the x coordinate from
>>_c, right?
>>On my system (Mandrake Linux 8.2) I got a segmentation fault in OBAtom::x().
Yeah, I don't know why I don't get a segfault and do get the "expected"
answer on RH 7.3. A good example of why you should test on multiple
platforms. :-)
-Geoff
--
-Geoff Hutchison <hut...@ch...>
Marks/Ratner Groups (847) 491-3295
Northwestern Chemistry <http://www.chem.nwu.edu>
|