Changes between Version 44 and Version 45 of StylePage


Ignore:
Timestamp:
2019-06-12T13:37:40Z (16 months ago)
Author:
peter
Comment:

Update description of open_data().

Legend:

Unmodified
Added
Removed
Modified
  • StylePage

    v44 v45  
    118118DEBUG_ENTRY( "routine()" ) - This routine produces a call trace (recording entry and exit of each routine) when the macro DEBUG_FUN is defined during compilation. This produces ''lots'' of output and is only used as a last resort when all other debugging methods fail to uncover where the code crashes. To keep the bulk of the output down, trivial routines typically do not have the DEBUG_ENTRY call. This is especially the case for code that is intended to be inlined. Any routine that calls cdEXIT also '''must''' have a call to DEBUG_ENTRY at the start. The debugtrace class generated by the DEBUG_ENTRY call is used as a source of the routine name so that it can be printed in the exit message. Once the C++0x standard is in effect, this can be replaced with the {{{__func__}}} string, but for now this is the only reliable source of the routine name.
    119119
    120 open_data() - All files need to be opened with open_data() as ''the use of fopen() is deprecated'' (the compiler will actually generate an error if you accidentally try to use fopen). When reading files, this routine will traverse the search path and open the file in the first location where it finds a match. It will produce a warning if multiple matches are found along the path and also produce an appropriate error message if the file is not found. The access_scheme flag will determine which parts of the search path will be searched. The default is AS_DEFAULT, which translates to AS_DATA_ONLY when reading files. This means that only the data directories will be searched, and not the current working directory. For historical reasons there currently is a bewildering variety of access schemes. This should be simplified in the near future. A description of the existing schemes can be found in cpu.h. There are three versions of open_data(), one for classic C-style I/O streams, one for C++ fstream based I/O, and one for MPI-IO based I/O. We have defined a bunch of flags in cpu.h to define the access mode to the fstream. These are chosen to be equivalent to their C-style counterparts, e.g. C-style access mode "r" becomes mode_r, and access mode "r+b" becomes mode_rpb. All existing C-style access modes are represented. C++ offers more access modes than C, and you can still use those by supplying the raw ios_base flags to open_data. These will be the most common ways of using open_data to read a normal core data file:
     120open_data() - All files need to be opened with open_data() as ''the use of fopen() is deprecated'' (the compiler will actually generate an error if you accidentally try to use fopen). When reading files, this routine will traverse the search path and open the file in the first location where it finds a match. It will produce a caution if multiple matches are found along the path and (when appropriate) also produce an error message if the file is not found. The access_scheme flag will determine how such errors will be handled. A description of the existing schemes can be found in cpu.h. There are three versions of open_data(), one for classic C-style I/O streams, one for C++ fstream based I/O, and one for MPI-IO based I/O. We have defined a bunch of flags in cpu.h to define the access mode to the fstream. These are chosen to be equivalent to their C-style counterparts, e.g. C-style access mode "r" becomes mode_r, and access mode "r+b" becomes mode_rpb. All existing C-style access modes are represented. C++ offers more access modes than C, and you can still use those by supplying the raw ios_base flags to open_data. These will be the most common ways of using open_data to read a normal core data file:
    121121
    122122{{{
     
    141141C++ based I/O has several advantages. I think the most important are that you get simple access to all the nifty string manipulation options that C++ has to offer, that you don't need to worry about buffer overflows any longer, and that the destructor of the fstream will close the file for you. The disadvantage is that it can be slower if you have very large files to read. If that becomes an issue, it can be worked around by using sscanf on the C-representation of the string, or other (lower level) routines. However, in my experience that is rarely needed and the advantaged of C++ I/O vastly outweigh the disadvantages.
    142142
    143 To allocate arrays always use C++ container classes such as array, vector, valarray, multi_arr, or flex_arr. **Never** use malloc() and try to stay away from new / delete / delete[] as the memory allocated with new will not be automatically freed. Cloudy has a firm policy that all memory that is allocated during a run is freed at the end.
     143To allocate arrays always use C++ container classes such as array, vector, valarray, multi_arr, or flex_arr. **Never** use malloc() and try to stay away from new / delete / delete[] as the memory allocated with new will not be automatically freed. Cloudy has a firm policy that all memory that is allocated during a run must be freed at the end.
    144144
    145145TorF( bool ) - returns the character T or F indicating the value of the bool argument.  This allows values of logical variables to be printed in way that makes sense to people.