Crash in IfcAddress::Purpose()

[Ian Mackenzie]

I'm getting a crash which looks like it might be a bug in IfcOpenShell. If
I write some code like

IfcSchema::IfcPostalAddress* address = new IfcSchema::IfcPostalAddress(
IfcSchema::IfcAddressTypeEnum::IfcAddressType_OFFICE, // purpose
boost::optional<std::string>(), // description
boost::optional<std::string>(), // user defined purpose
boost::optional<std::string>(), // internal location
boost::optional<std::vector\<std::string>>(), // address lines
boost::optional<std::string>(), // postal box
std::string("Toronto"), // town
boost::optional<std::string>(), // region
boost::optional<std::string>(), // postal code
boost::optional<std::string>() // country
);
std::cout << "Has purpose: " << address->hasPurpose() << std::endl;
std::cout << "Purpose: " << address->Purpose() << std::endl;</std::string></std::string></std::string></std::string></std::vector\<std::string></std::string></std::string></std::string>

the hasPurpose() returns true but an exception is thrown from Purpose().
The call stack is

    IfcAddress::Purpose() (Ifc2x3.cpp line 6547)
    IfcWriteArgument::operator std::string() (IfcWrite.cpp line 313)
    IfcWriteArgument::as<std::string>() (IfcWrite.h line 99)

so I thought it might be a quirk related to how enums seem to be stored as
strings and then converted back and forth. I'm using SVN revision 298. Is
this a bug or am I doing something wrong? Thanks!

-Ian Mackenzie

[Thomas Krijnen]

Hi Ian,

Thanks for your report. Your intuition seems correct. Fixed in the latest commit: r320. Let me know if you encounter any more issues.

Kind regards,
Thomas

[Ian Mackenzie]

Hi Thomas,

Thanks for the quick response! When trying to compile r320 I ran into an
error in XmlSerializer.cpp:

src\ifcconvert\XmlSerializer.cpp(43): error C2248:
'IfcUtil::IfcBaseType::getArgument' : cannot access private member declared
in class 'IfcUtil::IfcBaseType'

Was the removal of the 'public' access specifier from IfcBaseType in
revision 312 intentional?

-Ian

[Thomas Krijnen]

Hi Ian,

Thanks a lot. It was not intentional. Fixed in latest commit.

Kind regards,
Thomas