Re: File conversion

Robert Jones wrote:

As this newsgroup isn't yet subscribed to by computers instead of
people,  a simple "please" would seem to be in order for common
courtesy.

To answer your question

this seems to be a good case for MOVE CORRESPONDING, many organisations
don't like this construct as a general rule, but this situation appears
to be an obvious candidate.   You will have to first check that all
fields fully correspond in respect of data names and convertibility of
formats, I haven't done a detailed check on the two record layouts
myself.

It would also be a good idea to initialise the destination record by
moving spaces to it, so the filler always contains spaces, alternately,
rename the filler such that the same name is used in both layouts.

A disadvantage of using MOVE CORRESPONDING is that it is harder to
debug.

Also, programmers making future amendments to the program may not make
the appropriate changes to both record layouts, but then even if they
used lots of independent MOVEs, they still might not do that correctly
either.

Regards

Robert



MOVE CORR is not hard to debug, in my opinion. I would suggest just compiling with the XREF option (each elementary field will have an entry in the XREF) and generating an Assembler expansion of the code for that verb.

You would then have to do a detailed comparison of what fields the compiler found to correspond. Once you have done that, and proven that your COPY members are defined correctly, you're home free! Of course, future changes to the COPY members could blow you right out of the water....

Writing a series of MOVEs is, as you say, both tedious and error prone. The same sort of detailed comparison will be required, to ensure that no MOVEs were left out, and that the from and to fields in each MOVE were named correctly. And, future changes to the COPY members could blow you right out of the water....

So why not use the power of the compiler (MOVE CORR) to do part of your coding for you? It has always seemed like a good idea to me.

.

Relevant Pages

  • Re: struct alignment
    ... necessary so that all the members can be accesssed correctly. ... Does any compiler let you do this? ... Permit reordering of struct members, ... but that surely is rare. ...
    (comp.lang.c)
  • Re: Please help optimize (and standarize) this code...
    ... If you want to be sure that this also works with a C99 compiler you ... This obviously assumes that the members of the NameExt structure are ... itoa() isn't a standard C function, so this will fail on systems ...
    (comp.lang.c)
  • Re: Managed method in Native Class ?
    ... > void myClass::myMethod ... the members occupy a slot in the objects vtable laid-out by the compiler. ... a managed method cannot be a member of a native class. ...
    (microsoft.public.dotnet.languages.vc)
  • Re: Do not trust ALIGN
    ... The compiler assumes the data members are aligned!. ... Or similarly for a 32 bit bus. ... Hardware designers have lot's of tradeoffs to make in terms of external ...
    (microsoft.public.windowsce.platbuilder)
  • Re: functions returning objects
    ... > copies all of the members of that result into the members of objC? ... copy assignment operator which does memberwise assignment is valid. ... The compiler should also check that C's copy constructor is accessible, ... directly in the space allocated for objC, and do no copying at all. ...
    (alt.comp.lang.learn.c-cpp)