On Windows, when a file is opened in "text" mode, but it actually
contains Unix-style line endings, the behavior of tellg() is
unexpected.
Consider this program which puts the (binary) contents "a\nb\n" in a
file, then opens it in text mode for reading. It prints each
character read, along with the value returned by tellg():
#include <iostream>
#include <fstream>
int main()
{
{
std::ofstream f("myfile.txt", std::ios::binary);
f << "a\nb\n";
}
std::ifstream f("myfile.txt");
for (char c=0; f.get(c);)
std::cout << f.tellg() << ' ' << int(c) << '\n';
}
On a UNIX platform which does not have a distinction between "text"
and "binary" files, the output will read
1 97
2 10
3 98
4 10
because the file position simply advances one position after each
byte is read.
On Windows with the Visual Studio C and C++ runtime, the result is
instead
-1 97
1 10
2 98
4 10
While it is impossible to say exactly what the Windows runtime is
doing here, it appears that it is trying to adjust for the mismatch
between "number of bytes read in byte oriented mode and "number of
bytes read in text mode".
Since "part21" files don't necessarily contain CRLF line endings
when viewed in binary mode, open the file in binary mode. This
fixes the test failure seen on appveyor ci running the
"test_inverse_attr3" test.
|
||
|---|---|---|
| cmake | ||
| data | ||
| doc | ||
| example/ap203min | ||
| include | ||
| misc | ||
| src | ||
| test | ||
| .appveyor.yml | ||
| .gitignore | ||
| .travis.yml | ||
| AUTHORS | ||
| ChangeLog | ||
| CMakeLists.txt | ||
| CONTRIBUTING.md | ||
| COPYING | ||
| ctest_matrix.cmake | ||
| CTestConfig.cmake | ||
| INSTALL | ||
| lcov.cmake | ||
| NEWS | ||
| README.md | ||
| run_ctest.cmake | ||
| SC_VERSION.txt | ||
| Travis-CI | AppVeyor CI |
|---|---|
| Linux, OSX (LLVM) | Windows (MSVC) |
STEPcode v0.8 -- stepcode.org, github.com/stepcode/stepcode
-
What is STEPcode? SC reads ISO10303-11 EXPRESS schemas and generates C++ source code that can read and write Part 21 files conforming to that schema. In addition to C++, SC includes experimental support for Python.
-
Renamed in April/May 2012: SC was formerly known as STEP Class Libraries, SCL for short. It was renamed because the name wasn't accurate: the class libraries make up only a part of the code.
-
Much of the work to update SC has been done by the developers of BRL-CAD, and SC (then STEP Class Library) was originally created at NIST in the 90's.
-
For information on changes version-by-version, see the NEWS file
-
Building and testing SCL - see the INSTALL file
-
For more details on the libraries and executables, see the wiki: http://github.com/stepcode/stepcode/wiki/About-STEPcode
-
For license details, see the COPYING file. Summary: 3-clause BSD.
CODING STANDARDS
SC's source has been reformatted with astyle. When making changes, try to match the current formatting. The main points are:
- compact (java-style) brackets:
if( a == 3 ) {
c = 5;
function( a, b );
} else {
somefunc( );
}
- indents are 4 spaces
- no tab characters
- line endings are LF (linux), not CRLF (windows)
- brackets around single-line conditionals
- spaces inside parentheses and around operators
- return type on the same line as the function name, unless that's too long
- doxygen-style comments (see http://www.stack.nl/~dimitri/doxygen/docblocks.html)
If in doubt about a large patch, run astyle with the config file misc/astyle.cfg. Download astyle from http://sourceforge.net/projects/astyle/files/astyle/
For more info, see the wiki.