From yury.zaytsev at traveltainment.de Thu Feb 12 09:44:18 2015 From: yury.zaytsev at traveltainment.de (Yury Zaytsev) Date: Thu Feb 12 10:06:24 2015 Subject: [xsd-users] Streaming and Xerces-C++ runtime initialization Message-ID: <1F897018A4B45549AE2FE45B2DFF9E3A9F5914@EX-TT-AC-01.traveltainment.int> Hi, I'm trying to adopt the streaming example to my needs (that is re-use serializer.cxx/serializer.hxx directly in my project), so that I don't have to hold large collections of sub-elements in memory, but rather write them to disk as soon as they are processed. Unfortunately, I'm getting a segfault upon the finalization of the runtime. If you replace the original driver.cxx of the streaming example with the trivial code below, same sort of segfault happens. I'm using C++/Tree mapping with serialization functions only, and don't need parsing at all. Could you please hint me at where the problem might lie? I'm clearly missing something obvious. Many thanks! int main (int argc, char* argv[]) { // We need to initialize the Xerces-C++ runtime because we are doing // the XML-to-DOM parsing ourselves. // xercesc::XMLPlatformUtils::Initialize (); serializer s; xercesc::XMLPlatformUtils::Terminate (); } Dr. Yury V. Zaytsev Senior Software Developer IT Data Production TravelTainment GmbH Carlo-Schmid-Stra?e 12 52146 W?rselen/Aachen, Germany yury.zaytsev@traveltainment.de http://www.traveltainment.de Amtsgericht Aachen, HRB 15873 Gesch?ftsf?hrer: Bernhard Steffens (Vorsitzender) Dr. Oliver Rengelshausen ??? ???????????? From christian at gsvitec.com Thu Feb 12 10:36:03 2015 From: christian at gsvitec.com (Christian Sell) Date: Thu Feb 12 10:36:06 2015 Subject: [xsd-users] Streaming and Xerces-C++ runtime initialization In-Reply-To: <1F897018A4B45549AE2FE45B2DFF9E3A9F5914@EX-TT-AC-01.traveltainment.int> References: <1F897018A4B45549AE2FE45B2DFF9E3A9F5914@EX-TT-AC-01.traveltainment.int> Message-ID: <213565099.2225202.1423755363372.JavaMail.open-xchange@omgreatgod.store> Hello, I have seen something similar recently when dealing with Xerces in a different context: when you call XMLPlatformUtilities::Terminate, Xerces's default MemoryManager gets killed. However, any XMLString (and other) objects you or anyone may have created locally only go out of scope after that call, and their destructors try to talk to the default MemoryMamanger as well -> bang! This is Xerces's strange memory mamangement architecture. In my standalone program, I simply left out the Terminate call and all was well. regards, Christian > Yury Zaytsev hat am 12. Februar 2015 um 15:44 > geschrieben: > > > Hi, > > I'm trying to adopt the streaming example to my needs (that is re-use > serializer.cxx/serializer.hxx directly in my project), so that I don't have to > hold large collections of sub-elements in memory, but rather write them to > disk as soon as they are processed. Unfortunately, I'm getting a segfault upon > the finalization of the runtime. If you replace the original driver.cxx of the > streaming example with the trivial code below, same sort of segfault happens. > I'm using C++/Tree mapping with serialization functions only, and don't need > parsing at all. Could you please hint me at where the problem might lie? I'm > clearly missing something obvious. Many thanks! > > int > main (int argc, char* argv[]) > { > > // We need to initialize the Xerces-C++ runtime because we are doing > // the XML-to-DOM parsing ourselves. > // > xercesc::XMLPlatformUtils::Initialize (); > > serializer s; > > xercesc::XMLPlatformUtils::Terminate (); > > } > > Dr. Yury V. Zaytsev > Senior Software Developer > IT Data Production > > TravelTainment GmbH > Carlo-Schmid-Stra?e 12 > 52146 W?rselen/Aachen, Germany > yury.zaytsev@traveltainment.de > > http://www.traveltainment.de > > Amtsgericht Aachen, HRB 15873 > Gesch?ftsf?hrer: Bernhard Steffens (Vorsitzender) > Dr. Oliver Rengelshausen > > > > > > > From garry.jeromson at enclustra.com Thu Feb 12 13:20:03 2015 From: garry.jeromson at enclustra.com (Garry Jeromson) Date: Thu Feb 12 13:20:12 2015 Subject: [xsd-users] RE: Linker conflict when generating code from 2 different XML files with identically-named elements Message-ID: <1520C279C80F2343A5C090E835E4E13DD521E6A9@CLUSTRAONE.clustra.local> Hello, I have a problem in code where I'd like to parse 2 different XML files (with different schemas) - when compiling, I get a bunch of linker errors like this: error LNK2005: "protected: void __thiscall ConfigurationProperty::parse(class xsd::cxx::xml::dom::parser &,class xsd::cxx::tree::flags)" (?parse@ConfigurationProperty@@IAEXAAV?$parser@D@dom@xml@cxx@xsd@@Vflags@tree@56@@Z) already defined in EepromMemoryMaps.obj The reason is clear - the ConfigurationProperty element in the XML schema generates the same code in both generated .cxx files. The question is, is there a smart way to deal with this? If possible I'd like to avoid renaming the elements in the schema and having to edit generated files by hand, if possible. Any tips are much appreciated. Cheers, Garry From boris at codesynthesis.com Fri Feb 13 05:01:00 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Feb 13 05:11:04 2015 Subject: [xsd-users] Streaming and Xerces-C++ runtime initialization In-Reply-To: <1F897018A4B45549AE2FE45B2DFF9E3A9F5914@EX-TT-AC-01.traveltainment.int> References: <1F897018A4B45549AE2FE45B2DFF9E3A9F5914@EX-TT-AC-01.traveltainment.int> Message-ID: Hi Yury, Yury Zaytsev writes: > xercesc::XMLPlatformUtils::Initialize (); > > serializer s; > > xercesc::XMLPlatformUtils::Terminate (); Christian is spot on: you are terminating the runtime before destroying the serializer object, which has all kinds of Xerces-C++ stuff as its data members. I bet this will work: xercesc::XMLPlatformUtils::Initialize (); { serializer s; } xercesc::XMLPlatformUtils::Terminate (); Boris From garry.jeromson at enclustra.com Thu Feb 12 11:32:16 2015 From: garry.jeromson at enclustra.com (Garry Jeromson) Date: Fri Feb 13 05:11:20 2015 Subject: [xsd-users] Linker conflict when generating code from 2 different XML files with identically-named elements Message-ID: <1520C279C80F2343A5C090E835E4E13DD521E67A@CLUSTRAONE.clustra.local> Hello, I have a problem in code where I'd like to parse 2 different XML files (with different schemas) - when compiling, I get a bunch of linker errors like this: error LNK2005: "protected: void __thiscall ConfigurationProperty::parse(class xsd::cxx::xml::dom::parser &,class xsd::cxx::tree::flags)" (?parse@ConfigurationProperty@@IAEXAAV?$parser@D@dom@xml@cxx@xsd@@Vflags@tree@56@@Z) already defined in EepromMemoryMaps.obj The reason is clear - the ConfigurationProperty element in the XML schema generates the same code in both generated .cxx files. The question is, is there a smart way to deal with this? If possible I'd like to avoid renaming the elements in the schema and having to edit generated files by hand, if possible. Any tips are much appreciated. Cheers, Garry From boris at codesynthesis.com Fri Feb 13 05:03:23 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Feb 13 05:13:27 2015 Subject: [xsd-users] Linker conflict when generating code from 2 different XML files with identically-named elements In-Reply-To: <1520C279C80F2343A5C090E835E4E13DD521E67A@CLUSTRAONE.clustra.local> References: <1520C279C80F2343A5C090E835E4E13DD521E67A@CLUSTRAONE.clustra.local> Message-ID: Hi Garry, Garry Jeromson writes: > I have a problem in code where I'd like to parse 2 different XML > files (with different schemas) - when compiling, I get a bunch of > linker errors like this: > > The reason is clear - the ConfigurationProperty element in the XML > schema generates the same code in both generated .cxx files. The > question is, is there a smart way to deal with this? Yep, called the --namespace-map option. Boris From garry.jeromson at enclustra.com Fri Feb 13 06:07:37 2015 From: garry.jeromson at enclustra.com (Garry Jeromson) Date: Fri Feb 13 06:07:45 2015 Subject: [xsd-users] Linker conflict when generating code from 2 different XML files with identically-named elements In-Reply-To: References: <1520C279C80F2343A5C090E835E4E13DD521E67A@CLUSTRAONE.clustra.local> Message-ID: <1520C279C80F2343A5C090E835E4E13DD52314AB@CLUSTRAONE.clustra.local> Hi Boris, Perfect. Thanks! Garry -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Freitag, 13. Februar 2015 11:03 To: Garry Jeromson Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] Linker conflict when generating code from 2 different XML files with identically-named elements Hi Garry, Garry Jeromson writes: > I have a problem in code where I'd like to parse 2 different XML files > (with different schemas) - when compiling, I get a bunch of linker > errors like this: > > The reason is clear - the ConfigurationProperty element in the XML > schema generates the same code in both generated .cxx files. The > question is, is there a smart way to deal with this? Yep, called the --namespace-map option. Boris From yury.zaytsev at traveltainment.de Fri Feb 13 05:38:05 2015 From: yury.zaytsev at traveltainment.de (Yury Zaytsev) Date: Fri Feb 13 06:09:55 2015 Subject: [xsd-users] Streaming and Xerces-C++ runtime initialization In-Reply-To: References: <1F897018A4B45549AE2FE45B2DFF9E3A9F5914@EX-TT-AC-01.traveltainment.int> Message-ID: <1F897018A4B45549AE2FE45B2DFF9E3A9F5961@EX-TT-AC-01.traveltainment.int> Hi Boris, Thank you very much for the quick and concise answer: > Christian is spot on: you are terminating the runtime before destroying the > serializer object, which has all kinds of Xerces-C++ stuff as its data members. I > bet this will work: <...> Yes, as Christian suggested, it worked after I commented out the termination of the runtime (thanks, Christian!). Indeed, your proposed solution works as well; I'll be more careful about it in the future. While we are at it, do you happen have any plans for inclusion of the serializer in the standard XSD runtime rather than keeping it as an example only? For now, I've hacked up a patch to convert it to use unique_ptr<>, which I can post if it would help, and included it directly in my project. However, since I include the runtime anyways, it would be easier maintenance-wise rather than checking whether anything has changed with every new version, and applying custom patches on top, etc. Many thanks, Dr. Yury V. Zaytsev Senior Software Developer IT Data Production TravelTainment GmbH Carlo-Schmid-Stra?e 12 52146 W?rselen/Aachen, Germany yury.zaytsev@traveltainment.de http://www.traveltainment.de Amtsgericht Aachen, HRB 15873 Gesch?ftsf?hrer: Bernhard Steffens (Vorsitzender) Dr. Oliver Rengelshausen From boris at codesynthesis.com Mon Feb 16 06:35:20 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Feb 16 06:45:25 2015 Subject: [xsd-users] Streaming and Xerces-C++ runtime initialization In-Reply-To: <1F897018A4B45549AE2FE45B2DFF9E3A9F5961@EX-TT-AC-01.traveltainment.int> References: <1F897018A4B45549AE2FE45B2DFF9E3A9F5914@EX-TT-AC-01.traveltainment.int> <1F897018A4B45549AE2FE45B2DFF9E3A9F5961@EX-TT-AC-01.traveltainment.int> Message-ID: Hi Yury, Yury Zaytsev writes: > While we are at it, do you happen have any plans for inclusion of the > serializer in the standard XSD runtime rather than keeping it as an example > only? For now, I've hacked up a patch to convert it to use unique_ptr<>, > which I can post if it would help, and included it directly in my > project. However, since I include the runtime anyways, it would be easier > maintenance-wise rather than checking whether anything has changed with > every new version, and applying custom patches on top, etc. The example started with a parser and serializer that had to be customized for each vocabulary. Now, however, that they were generalized, I agree it would make sense to move them to libxsd. There is one problem, though: libxsd is header-only and both of them, and especially the serializer, have quite a bit of non-inline source code. So that's an obstacle. Boris From tsroynciitraoln at gmail.com Mon Feb 16 11:26:59 2015 From: tsroynciitraoln at gmail.com (tsroynciitraoln) Date: Tue Feb 17 04:04:19 2015 Subject: [xsd-users] XML data binding Message-ID: Hi, I'm currently using CodeSynthesis for XML data binding. I generated files C++ files using the following comman line : ./xsd cxx-tree --std c++11 --file-per-type --generate-serialization --generate-wildcard --generate-ostream --output-dir ./generated espiDerived.xsd espiDerived is using atom.xsd, atom.xsd is using xml.xsd. Two main namespaces are created: Atom and espi. I'm able to navigate in the atom tree, using feed or entry root. When arriving in a contentType node, I'm able to detect the kind of child elements or attributs using this kind of code: for (auto jtContent = itEntry->content().begin(); jtContent != itEntry->content().end(); ++jtContent) { ::xercesc::DOMNode const* usagePointNode(0); for (::xercesc::DOMNode const* n(jtContent->_node()->getFirstChild()); n != 0; n = n->getNextSibling()) { if (n->getNodeType() == ::xercesc::DOMNode::ELEMENT_NODE && xsd::cxx::xml::transcode(n->getLocalName()) == "usahePoint") { usagePointNode = n; std::cout << "UsagePoint node detected" << std::endl; xml_schema::type& t(*reinterpret_cast (usagePointNode->getUserData(xml_schema::dom::tree_node_key))); espi::UsagePoint& a(dynamic_cast (t)); } } } My current problem is for cast the underlying dom element to a C++ generated object. Using the two last line of code result in nothing inside t and a. (empty struct). How can I solve my problem ? I'm using the last version of CodeSynthesis, and Visual Studio 2013 on Windows 8.1. Best regards From boris at codesynthesis.com Tue Feb 17 10:46:34 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Feb 17 10:56:38 2015 Subject: [xsd-users] XML data binding In-Reply-To: References: Message-ID: Hi, tsroynciitraoln writes: > My current problem is for cast the underlying dom element to a C++ > generated object. You cannot cast them to C++ objects. This is raw XML content that is represented as DOM fragments. You can, however, parse it into suitable C++ objects. Refer to the 'wildcard' example to see how it can be done. Boris From tsroynciitraoln at gmail.com Wed Feb 18 03:39:12 2015 From: tsroynciitraoln at gmail.com (tsroynciitraoln) Date: Wed Feb 18 05:08:50 2015 Subject: [xsd-users] XML data binding In-Reply-To: References: Message-ID: Thanks for the answer, has usual, I found a solution juste after asking you... 2015-02-17 16:46 GMT+01:00 Boris Kolpackov : > Hi, > > tsroynciitraoln writes: > > > My current problem is for cast the underlying dom element to a C++ > > generated object. > > You cannot cast them to C++ objects. This is raw XML content that is > represented as DOM fragments. You can, however, parse it into suitable > C++ objects. Refer to the 'wildcard' example to see how it can be done. > > Boris > From albert.babinskas at imagingsciences.com Wed Feb 18 15:12:51 2015 From: albert.babinskas at imagingsciences.com (Babinskas, Albert) Date: Wed Feb 18 15:12:59 2015 Subject: [xsd-users] Issue with maintaining order Message-ID: HI, I have issue with order of my elements. I have XSD that looks like this: ... Where looks like this: Codesynthesis provides me with AnnotationList.line() AnnotationList.Polygon() AnnotationList.Ellipse() But the order is not preserved. If I have: Line, 2 Polygons, and another Line. It will be serialized as 2 Lines, and 2 Polygons. Is there a way to preserve the order in which I serialize? Secondly If I am reading xml that has mixed lines and polygons, all my lines, and polygons will be in their distinct lists, and not in 1 main list where I could check type. Again same question is there a way to preserve order? Is there a way after XML is parsed into XSD objects, to access DOM structure of that Object? For example if I would be able to access annotationList Document, or have an iterator over the annotationList. Thank you! -Albert Imaging Sciences International From boris at codesynthesis.com Thu Feb 19 09:18:01 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Feb 19 09:28:26 2015 Subject: [xsd-users] Issue with maintaining order In-Reply-To: References: Message-ID: Hi Albert, Babinskas, Albert writes: > But the order is not preserved. In 4.0.0 we've added a feature specifically for that. Check Section 2.8.4, "Element Order" in the C++/Tree Mapping User Manual: http://codesynthesis.com/projects/xsd/documentation/cxx/tree/manual/#2.8.4 > Is there a way after XML is parsed into XSD objects, to access DOM > structure of that Object? For example if I would be able to access > annotationList Document, or have an iterator over the annotationList. Yes, you can use the DOM association feature. But the above approach is easier to use and it works for both parsing and serialization while the DOM association will only work for parsing. Boris From albert.babinskas at imagingsciences.com Thu Feb 19 10:34:27 2015 From: albert.babinskas at imagingsciences.com (Babinskas, Albert) Date: Thu Feb 19 10:34:35 2015 Subject: [xsd-users] Issue with maintaining order In-Reply-To: References: Message-ID: HI Boris, I am investigating solution provided in manual section "2.8.4 Element Order". But my XSD type is not labeled MIXED. The only way I could get annotationList::order_type, and get ellipse_id is when I would use compile option --ordered-type-all. But that creates issues for the rest of the project. I tried --ordered-type annotationList --ordered-type-derived, but that didn't provide me the functionality I needed. What am I doing wrong? -Albert -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Thursday, February 19, 2015 9:18 AM To: Babinskas, Albert Cc: 'xsd-users@codesynthesis.com' Subject: Re: [xsd-users] Issue with maintaining order Hi Albert, Babinskas, Albert writes: > But the order is not preserved. In 4.0.0 we've added a feature specifically for that. Check Section 2.8.4, "Element Order" in the C++/Tree Mapping User Manual: http://codesynthesis.com/projects/xsd/documentation/cxx/tree/manual/#2.8.4 > Is there a way after XML is parsed into XSD objects, to access DOM > structure of that Object? For example if I would be able to access > annotationList Document, or have an iterator over the annotationList. Yes, you can use the DOM association feature. But the above approach is easier to use and it works for both parsing and serialization while the DOM association will only work for parsing. Boris From boris at codesynthesis.com Thu Feb 19 10:38:51 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Feb 19 10:49:17 2015 Subject: [xsd-users] Issue with maintaining order In-Reply-To: References: Message-ID: Hi Albert, Babinskas, Albert writes: > I tried --ordered-type annotationList The type in question is anonymous and its name can differ from the element's name. Check what is the corresponding generated C++ class name and try that. If it has a number at the end, e.g., AnnotationList1, try both with and without the number. Boris From albert.babinskas at imagingsciences.com Thu Feb 19 10:54:01 2015 From: albert.babinskas at imagingsciences.com (Babinskas, Albert) Date: Thu Feb 19 10:54:08 2015 Subject: [xsd-users] Issue with maintaining order In-Reply-To: References: Message-ID: <26fde763cf4f4eda900440260b9519a7@DENORASPEXCH1.sds.sybrondental.com> Hi Boris, Thank you for help. This worked for me: --ordered-type annotations_t --ordered-type-derived --ordered-type annotationList --ordered-type-derived Not sure if right, but it worked. -Albert -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Thursday, February 19, 2015 10:39 AM To: Babinskas, Albert Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] Issue with maintaining order Hi Albert, Babinskas, Albert writes: > I tried --ordered-type annotationList The type in question is anonymous and its name can differ from the element's name. Check what is the corresponding generated C++ class name and try that. If it has a number at the end, e.g., AnnotationList1, try both with and without the number. Boris From maxim.maslennikov at gmail.com Sat Feb 21 15:45:33 2015 From: maxim.maslennikov at gmail.com (Maxim Maslennikov) Date: Mon Feb 23 08:01:39 2015 Subject: [xsd-users] FreeBSD compilation error Message-ID: <2E43CD35-4C57-4890-BE8B-20D308BEF2A0@gmail.com> Hello! I?m trying to make xsd-4.0.0+dep on FreeBSD 10.1 X86-64 and get following error: gmake CC=clang CXX=clang++ CXXFLAGS="-O2 -I/usr/local/include? ... c++ /root/dev/xsd-4.0.0+dep/libxsd-frontend/xsd-frontend/semantic-graph/elements.cxx /root/dev/xsd-4.0.0+dep/libxsd-frontend/xsd-frontend/semantic-graph/elements.cxx:298:13: error: invalid operands to binary expression ('std::wostream' (aka 'basic_ostream') and 'const value_type *' (aka 'const char *')) return os << path.string ().c_str (); ~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~ /root/dev/xsd-4.0.0+dep/libxsd-frontend/xsd-frontend/semantic-graph/elements.cxx:296:1: note: candidate function not viable: no known conversion from 'const value_type *' (aka 'const char *') to 'const XSDFrontend::SemanticGraph::Path' (aka 'const basic_path') for 2nd argument operator<< (std::wostream& os, XSDFrontend::SemanticGraph::Path const& path) ^ /usr/include/c++/v1/memory:5263:1: note: candidate template ignored: could not match 'shared_ptr' against 'const char *' operator<<(basic_ostream<_CharT, _Traits>& __os, shared_ptr<_Yp> const& __p); ^ /usr/include/c++/v1/string:4088:1: note: candidate template ignored: could not match 'basic_string' against 'const char *' operator<<(basic_ostream<_CharT, _Traits>& __os, ^ 1 error generated. /root/dev/xsd-4.0.0+dep/build-0.3/cxx/generic/cxx-o.make:23: ?????? ?????????? ??????? ??? ???? ?/root/dev/xsd-4.0.0+dep/libxsd-frontend/xsd-frontend/semantic-graph/elements.o? gmake: *** [/root/dev/xsd-4.0.0+dep/libxsd-frontend/xsd-frontend/semantic-graph/elements.o] ?????? 1 Best Regards, Maxim Maslennikov Moscow Russia +7 985 274-05-70 From boris at codesynthesis.com Mon Feb 23 08:07:20 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Feb 23 08:17:52 2015 Subject: [xsd-users] FreeBSD compilation error In-Reply-To: <2E43CD35-4C57-4890-BE8B-20D308BEF2A0@gmail.com> References: <2E43CD35-4C57-4890-BE8B-20D308BEF2A0@gmail.com> Message-ID: Hi Maxim, Maxim Maslennikov writes: > /root/dev/xsd-4.0.0+dep/libxsd-frontend/xsd-frontend/semantic-graph/elements.cxx:298:13: error: invalid operands to binary expression > ('std::wostream' (aka 'basic_ostream') and 'const value_type *' (aka 'const char *')) > return os << path.string ().c_str (); Looks like clang's libc++ doesn't support printing narrow strings to wide streams. Can you verify this by trying to compile this simple program: #include int main () { std::wcerr << "Hello, World!" << std::endl; } Boris From maxim.maslennikov at gmail.com Mon Feb 23 12:26:17 2015 From: maxim.maslennikov at gmail.com (Maxim Maslennikov) Date: Tue Feb 24 03:11:04 2015 Subject: [xsd-users] FreeBSD compilation error In-Reply-To: References: <2E43CD35-4C57-4890-BE8B-20D308BEF2A0@gmail.com> Message-ID: Hi Boris, It?s compiled without problem ? The output is bellow: root@dev:~/dev # cat main.cpp #include int main () { std::wcerr << "Hello, World!" << std::endl; } root@dev:~/dev # clang++ -std=c++11 main.cpp -o test root@dev:~/dev # ldd test test: libc++.so.1 => /usr/lib/libc++.so.1 (0x800820000) libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x800ae1000) libm.so.5 => /lib/libm.so.5 (0x800cfd000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x800f24000) libc.so.7 => /lib/libc.so.7 (0x801132000) root@dev:~/dev # ./test Hello, World! root@dev:~/dev # Best Regards, Maxim Maslennikov Moscow Russia +7 985 274-05-70 > On Feb 23, 2015, at 4:07 PM, Boris Kolpackov wrote: > > Hi Maxim, > > Maxim Maslennikov writes: > >> /root/dev/xsd-4.0.0+dep/libxsd-frontend/xsd-frontend/semantic-graph/elements.cxx:298:13: error: invalid operands to binary expression >> ('std::wostream' (aka 'basic_ostream') and 'const value_type *' (aka 'const char *')) >> return os << path.string ().c_str (); > > Looks like clang's libc++ doesn't support printing narrow strings > to wide streams. Can you verify this by trying to compile this > simple program: > > #include > > int main () > { > std::wcerr << "Hello, World!" << std::endl; > } > > Boris From boris at codesynthesis.com Tue Feb 24 03:37:34 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Feb 24 03:48:04 2015 Subject: [xsd-users] FreeBSD compilation error In-Reply-To: References: <2E43CD35-4C57-4890-BE8B-20D308BEF2A0@gmail.com> Message-ID: Hi Maxim, Maxim Maslennikov writes: > root@dev:~/dev # clang++ -std=c++11 main.cpp -o test Try in the c++98 mode since that's how you compile XSD. Clang is known to be anal enough not to implement common sense stuff just because the standard doesn't mandate it. Boris From maxim.maslennikov at gmail.com Tue Feb 24 15:02:22 2015 From: maxim.maslennikov at gmail.com (Maxim Maslennikov) Date: Wed Feb 25 03:48:26 2015 Subject: [xsd-users] FreeBSD compilation error In-Reply-To: References: <2E43CD35-4C57-4890-BE8B-20D308BEF2A0@gmail.com> Message-ID: Hi Boris, Result is the same ? root@dev:~/dev # cat main.cpp #include int main () { std::wcerr << "Hello, World!" << std::endl; } root@dev:~/dev # clang++ -std=c++98 main.cpp -o test root@dev:~/dev # ./test Hello, World! root@dev:~/dev # Also tried compiling xsd with -std=c++98 and got the same error :( /root/dev/xsd-4.0.0+dep/libxsd-frontend/xsd-frontend/semantic-graph/elements.cxx:298:13: error: invalid operands to binary expression ('std::wostream' (aka 'basic_ostream') and 'const value_type *' (aka 'const char *')) return os << path.string ().c_str (); ~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~ /root/dev/xsd-4.0.0+dep/libxsd-frontend/xsd-frontend/semantic-graph/elements.cxx:296:1: note: candidate function not viable: no known conversion from 'const value_type *' (aka 'const char *') to 'const XSDFrontend::SemanticGraph::Path' (aka 'const basic_path') for 2nd argument operator<< (std::wostream& os, XSDFrontend::SemanticGraph::Path const& path) ^ /usr/include/c++/v1/memory:5263:1: note: candidate template ignored: could not match 'shared_ptr' against 'const char *' operator<<(basic_ostream<_CharT, _Traits>& __os, shared_ptr<_Yp> const& __p); ^ /usr/include/c++/v1/string:4088:1: note: candidate template ignored: could not match 'basic_string' against 'const char *' operator<<(basic_ostream<_CharT, _Traits>& __os, ^ 1 error generated. Best Regards, Maxim Maslennikov Moscow Russia +7 985 274-05-70 > On Feb 24, 2015, at 11:37 AM, Boris Kolpackov wrote: > > Hi Maxim, > > Maxim Maslennikov writes: > >> root@dev:~/dev # clang++ -std=c++11 main.cpp -o test > > Try in the c++98 mode since that's how you compile XSD. Clang is > known to be anal enough not to implement common sense stuff just > because the standard doesn't mandate it. > > Boris From maxim.maslennikov at gmail.com Tue Feb 24 18:32:04 2015 From: maxim.maslennikov at gmail.com (Maxim Maslennikov) Date: Wed Feb 25 03:48:26 2015 Subject: [xsd-users] FreeBSD compilation error In-Reply-To: References: <2E43CD35-4C57-4890-BE8B-20D308BEF2A0@gmail.com> Message-ID: <504AAAE7-3590-42A8-9E12-E6B3027B2296@gmail.com> Hi Boris, I managed to do this. First I change in file xsd-4.0.0+dep/libxsd-frontend/xsd-frontend/semantic-graph/elements.cxx return os << path.string ().c_str (); to return os << wasting( path.string().begin(), path.string().end()); Second I change in file xsd-4.0.0+dep/build-0.3/git/gitignore #! /usr/bin env bash to #! /usr/bin env sh because of FreeBSD doesn?t use bash by default. But I get a few Assertion failed messages during testing in file xsd-4.0.0+dep/xsd/tests/cxx/parser/validation/built-in/float/driver.cxx I had to comment a few line to do all tests. The part of the file is below: // Bad // // float // { float_pimpl p; p.pre (); p._pre (); p._characters ("+INF"); //assert (test_post_fail (p)); } { float_pimpl p; p.pre (); p._pre (); p._characters ("1.45 E2"); assert (test_post_fail (p)); } // double // { double_pimpl p; p.pre (); p._pre (); p._characters ("+INF"); //assert (test_post_fail (p)); } { double_pimpl p; p.pre (); p._pre (); p._characters ("1.45 E2"); assert (test_post_fail (p)); } // decimal // { decimal_pimpl p; p.pre (); p._pre (); p._characters ("INF"); //assert (test_post_fail (p)); } { decimal_pimpl p; p.pre (); p._pre (); p._characters ("+INF"); //assert (test_post_fail (p)); } { decimal_pimpl p; p.pre (); p._pre (); p._characters ("-INF"); //assert (test_post_fail (p)); } { decimal_pimpl p; p.pre (); p._pre (); p._characters ("NaN"); //assert (test_post_fail (p)); } Why I got these assertion messages? How to correct this? Best Regards, Maxim Maslennikov Moscow Russia +7 985 274-05-70 > On Feb 24, 2015, at 11:02 PM, Maxim Maslennikov wrote: > > Hi Boris, > > Result is the same ? > > root@dev:~/dev # cat main.cpp > #include > > int main () > { > std::wcerr << "Hello, World!" << std::endl; > } > > root@dev:~/dev # clang++ -std=c++98 main.cpp -o test > root@dev:~/dev # ./test > Hello, World! > root@dev:~/dev # > > Also tried compiling xsd with -std=c++98 and got the same error :( > > /root/dev/xsd-4.0.0+dep/libxsd-frontend/xsd-frontend/semantic-graph/elements.cxx:298:13: error: invalid operands > to binary expression ('std::wostream' (aka 'basic_ostream') and 'const value_type *' > (aka 'const char *')) > return os << path.string ().c_str (); > ~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~ > /root/dev/xsd-4.0.0+dep/libxsd-frontend/xsd-frontend/semantic-graph/elements.cxx:296:1: note: candidate function > not viable: no known conversion from 'const value_type *' (aka 'const char *') to 'const > XSDFrontend::SemanticGraph::Path' (aka 'const basic_path') for 2nd argument > operator<< (std::wostream& os, XSDFrontend::SemanticGraph::Path const& path) > ^ > /usr/include/c++/v1/memory:5263:1: note: candidate template ignored: could not match > 'shared_ptr' against 'const char *' > operator<<(basic_ostream<_CharT, _Traits>& __os, shared_ptr<_Yp> const& __p); > ^ > /usr/include/c++/v1/string:4088:1: note: candidate template ignored: could not match > 'basic_string' against 'const char *' > operator<<(basic_ostream<_CharT, _Traits>& __os, > ^ > 1 error generated. > > Best Regards, > Maxim Maslennikov > Moscow Russia > +7 985 274-05-70 > >> On Feb 24, 2015, at 11:37 AM, Boris Kolpackov > wrote: >> >> Hi Maxim, >> >> Maxim Maslennikov > writes: >> >>> root@dev:~/dev # clang++ -std=c++11 main.cpp -o test >> >> Try in the c++98 mode since that's how you compile XSD. Clang is >> known to be anal enough not to implement common sense stuff just >> because the standard doesn't mandate it. >> >> Boris > From boris at codesynthesis.com Wed Feb 25 05:04:42 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Feb 25 05:15:12 2015 Subject: [xsd-users] FreeBSD compilation error In-Reply-To: <504AAAE7-3590-42A8-9E12-E6B3027B2296@gmail.com> References: <2E43CD35-4C57-4890-BE8B-20D308BEF2A0@gmail.com> <504AAAE7-3590-42A8-9E12-E6B3027B2296@gmail.com> Message-ID: Hi Maxim, Maxim Maslennikov writes: > First I change in file xsd-4.0.0+dep/libxsd-frontend/xsd-frontend/ > semantic-graph/elements.cxx > return os << path.string ().c_str (); > to > return os << wasting( path.string().begin(), path.string().end()); I think a better fix is to #include at the top of elements.cxx. Can you verify that it works (I am pretty sure it will)? > Second I change in file xsd-4.0.0+dep/build-0.3/git/gitignore > #! /usr/bin env bash > to > #! /usr/bin env sh > because of FreeBSD doesn?t use bash by default. It doesn't have to be the default shell, that's why there is env in there. It should work as long as you have it in PATH somewhere. > But I get a few Assertion failed messages during testing in file > xsd-4.0.0+dep/xsd/tests/cxx/parser/validation/built-in/float/driver.cxx Floating-point parsing/serialization is inherently imprecise and it seems FreeBSD's libc/libc++ has some peculiarities. You will have to investigate what's going on there (look at the implementation of the parser that fails, the input, etc). Boris From Peter.Sibinger at cpg.de Wed Feb 25 10:08:40 2015 From: Peter.Sibinger at cpg.de (Sibinger Peter) Date: Wed Feb 25 10:08:45 2015 Subject: [xsd-users] serialize problems: thousands separator in gyear_month and unsigned long Message-ID: <9EA4069FDCB059418A892D47A25498E456A64D@SONNE.cpg.de> Hi All, Today I had problems to serialize integer and long variables correctly. E.g. in date-time.txx the values x.year=2014 and x.month=12 resulted in a stream "2.014-12". The only solution I found was to add the classic "C" locale to get no thousands separator. You'll find the added line below. [date-time.txx] _________________________________ ... // gyear_month // namespace bits { template void insert (std::basic_ostream& os, const tree::gyear_month& x) { if (x.month () < 13) { os.imbue (std::locale::classic ()); // without that you'll get thousands separator os.fill (C ('0')); os.width (4); os << x.year () << C ('-'); os.width (2); os << x.month (); if (x.zone_present ()) zone_insert (os, x); } } } ... _________________________________ Unfortunately I run into the same problem for all integer and long variables in *.hxx, *.txx in tree/serialization. For double, decimal and float variables the classic "C" locale is part of the header (e.g. in tree/serialization/decimal.hxx) for integer and long variables not. I'm not sure whether there's another solution for that. With kind regards Peter From ILuyckx at benelux.tokheim.com Wed Feb 25 10:37:53 2015 From: ILuyckx at benelux.tokheim.com (Ivo Luyckx) Date: Wed Feb 25 10:37:59 2015 Subject: [xsd-users] linking problem with generated cxx/hxx files Message-ID: <1F99B50D975CD343AF178045C564BE1702BE8A284E@THSRV10.benelux.tokheim.com> Hello all, I am using xsd to compile a set of XSD files into cxx/hxx files. Command line: xsd.exe cxx-tree --output-dir ./out/ --show-sloc --generate-serialization --generate-doxygen --type-naming ucc --function-naming java --char-type wchar_t --type-regex '/ (.+)_t/\u$1/' hello.xsd xsd.exe cxx-tree --output-dir ./out/ --show-sloc --generate-serialization --generate-doxygen --type-naming ucc --function-naming java --char-type wchar_t --type-regex '/ (.+)_t/\u$1/' hello2.xsd Them I am using the generated files in a Visual Studio 2010 project. Compiling this project results in a number of the following errors while linking: hello2.obj : error LNK2005: "public: class xsd::cxx::tree::string > const & __thiscall Message::getGreeting(void)const " (?getGreeting@Message@@QBEABV?$string@_WV?$simple_type@_WV_type@tree@cxx@xsd@@@tree@cxx@xsd@@@tree@cxx@xsd@@XZ) already defined in hello.obj The input XSD files are quite basic: - hello.xsd: - hello2.xsd: The problem seems to be the nested in both XSD's. In both generated hxx files a class Message is generated: class Message: public ::xml_schema::Type { This is causing the 'already defined' linking problem. I am aware this problem can be solved by putting this complex type in an XSD which is included in hello.xsd and hello2.xsd. The problem is that the XSD's are coming from a third party and I have no control whatsoever on them. Is there a way to tell XSD (e.g. command line option) to generate a more complex class name (e.g. HelloResponse_Message) for these nested elements? This would avoid naming clashes for locally defined elements. Kind regards, Ivo. This e-mail and any attachments contain material that is confidential for the sole use of the intended recipient. Any review, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. This message has been scanned for malware by Websense. www.websense.com From yury.zaytsev at traveltainment.de Wed Feb 25 07:52:38 2015 From: yury.zaytsev at traveltainment.de (Yury Zaytsev) Date: Wed Feb 25 10:51:48 2015 Subject: [xsd-users] Support for list initialization Message-ID: <1F897018A4B45549AE2FE45B2DFF9E3A9F6091@EX-TT-AC-01.traveltainment.int> Hi, I think that it would be very helpful to use alias declarations instead of non-aggregate classes in XSD, at least in C++11 mode, so that one can use list initialization for stuff like infomaps: const xml_schema::namespace_infomap ns_map{{"", {ns_name, ns_schema}}}; Hopefully the attached patch clarifies what I mean. Obviously, it?s just syntactic sugar, but if you get a chance to implement it one day, it?s going to be welcome nevertheless. All the best, Dr. Yury V. Zaytsev Senior Software Developer IT Data Production TravelTainment GmbH Carlo-Schmid-Stra?e 12 52146 W?rselen/Aachen, Germany yury.zaytsev@traveltainment.de http://www.traveltainment.de Amtsgericht Aachen, HRB 15873 Gesch?ftsf?hrer: Bernhard Steffens (Vorsitzender) Dr. Oliver Rengelshausen ??? ???????????? -------------- next part -------------- A non-text attachment was scrubbed... Name: serialization-header.hxx.patch Type: application/octet-stream Size: 534 bytes Desc: serialization-header.hxx.patch Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20150225/7a516644/serialization-header.hxx.obj From boris at codesynthesis.com Wed Feb 25 10:53:51 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Feb 25 11:04:20 2015 Subject: [xsd-users] serialize problems: thousands separator in gyear_month and unsigned long In-Reply-To: <9EA4069FDCB059418A892D47A25498E456A64D@SONNE.cpg.de> References: <9EA4069FDCB059418A892D47A25498E456A64D@SONNE.cpg.de> Message-ID: Hi Peter, Sibinger Peter writes: > E.g. in date-time.txx the values x.year=2014 and x.month=12 resulted > in a stream "2.014-12". > > The only solution I found was to add the classic "C" locale to get > no thousands separator. I think something in your application changes the global locale (std::locale::global(); "C" by default). I believe this is a bad idea and will lead to all kinds of breakages. I also don't think explicitly setting "C" locale on each stream that XSD ever creates is a good solution. It will be a performance drag and is unnecessary in 99.9% (in the 10 years that XSD was around you are the first person to have this problem). I found this page has quite a bit of background information on C and C++ locales: http://stdcxx.apache.org/doc/stdlibug/24-3.html Boris From boris at codesynthesis.com Wed Feb 25 10:57:49 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Feb 25 11:08:18 2015 Subject: [xsd-users] linking problem with generated cxx/hxx files In-Reply-To: <1F99B50D975CD343AF178045C564BE1702BE8A284E@THSRV10.benelux.tokheim.com> References: <1F99B50D975CD343AF178045C564BE1702BE8A284E@THSRV10.benelux.tokheim.com> Message-ID: Hi Ivo, Ivo Luyckx writes: > Compiling this project results in a number of the following errors > while linking: The two schemas that you have probably define the same types. The solution is to place the generated code for the two schemas into different C++ namespace. That is, add this option to the first command line: --namespace-map =ns1 And this to the second: --namespace-map =ns2 > Is there a way to tell XSD (e.g. command line option) to generate a > more complex class name (e.g. HelloResponse_Message) for these nested > elements? Yes, you can do that also. See the --anonymous-regex option in the XSD compiler command line manual. Boris From Markowitz_Hillel at bah.com Wed Feb 25 13:54:49 2015 From: Markowitz_Hillel at bah.com (Markowitz, Hillel [USA]) Date: Thu Feb 26 02:45:48 2015 Subject: [xsd-users] Template for member created by Code Synthesis Message-ID: <1424890488495.8923@bah.com> A set of xsd uses Code Synthesis to create a set of classes and members. I would like to set up templates to handle certain members that will be added in the future. I would like to use the templates so that I do not get a compilation file before the updated include files and libraries are installed. for example baseclass.myMemberA().push_back(basedata); Where myMemberA is the element that is being added. if there were a #define, the I could have used #ifdef. However, there is no such define. I could use a template using myMemberA, but that requires an explicit test. I could have a number of such members coming up so I would like a generic solution. I go into more detail on this question at https://stackoverflow.com/questions/28680879/c-template-for-variable-type-declaration but have not yet received a usable answer. Is there something in what Code Synthesis generates that I can use? I do not have any control over the xsd files or the library and include files generated by Code Snthesis. [https://cdn.sstatic.net/stackoverflow/img/apple-touch-icon@2.png?v=ea71a5211a91] C++ template for variable type declaration - Stack Overflow I have a number of classes with differing members, all of which have operations of the following type ::basedata::Maindata maindata; ::basedata::Subdata subinfo("This goes into the subinfo vector"); Read more... [https://cdn.sstatic.net/stackoverflow/img/apple-touch-icon@2.png?v=ea71a5211a91] C++ template for variable type declaration - Stack Overflow I have a number of classes with differing members, all of which have operations of the following type ::basedata::Maindata maindata; ::basedata::Subdata subinfo("This goes into the subinfo vector"); Read more... -- Hillel Eli Markowitz Booz Allen Hamilton Markowitz_Hillel@bah.com Hillel.Markowitz@gmail.com From maxim.maslennikov at gmail.com Wed Feb 25 15:19:54 2015 From: maxim.maslennikov at gmail.com (Maxim Maslennikov) Date: Thu Feb 26 02:45:48 2015 Subject: [xsd-users] FreeBSD compilation error In-Reply-To: References: <2E43CD35-4C57-4890-BE8B-20D308BEF2A0@gmail.com> <504AAAE7-3590-42A8-9E12-E6B3027B2296@gmail.com> Message-ID: Hi Boris, You are right, adding just #include is simpler and better and it works. FreeBSD doesn?t install bash by default. Can I use sh or I should install bash? Concerning assertion failed in float test how did you solve the issue in mac os x clang? Best Regards, Maxim Maslennikov Moscow Russia +7 985 274-05-70 > On Feb 25, 2015, at 1:04 PM, Boris Kolpackov wrote: > > Hi Maxim, > > Maxim Maslennikov writes: > >> First I change in file xsd-4.0.0+dep/libxsd-frontend/xsd-frontend/ >> semantic-graph/elements.cxx >> return os << path.string ().c_str (); >> to >> return os << wasting( path.string().begin(), path.string().end()); > > I think a better fix is to #include at the top of elements.cxx. > Can you verify that it works (I am pretty sure it will)? > > >> Second I change in file xsd-4.0.0+dep/build-0.3/git/gitignore >> #! /usr/bin env bash >> to >> #! /usr/bin env sh >> because of FreeBSD doesn?t use bash by default. > > It doesn't have to be the default shell, that's why there is env in > there. It should work as long as you have it in PATH somewhere. > > >> But I get a few Assertion failed messages during testing in file >> xsd-4.0.0+dep/xsd/tests/cxx/parser/validation/built-in/float/driver.cxx > > Floating-point parsing/serialization is inherently imprecise and > it seems FreeBSD's libc/libc++ has some peculiarities. You will > have to investigate what's going on there (look at the implementation > of the parser that fails, the input, etc). > > Boris From Peter.Sibinger at cpg.de Thu Feb 26 04:09:00 2015 From: Peter.Sibinger at cpg.de (Sibinger Peter) Date: Thu Feb 26 04:09:06 2015 Subject: AW: [xsd-users] serialize problems: thousands separator in gyear_month and unsigned long In-Reply-To: References: <9EA4069FDCB059418A892D47A25498E456A64D@SONNE.cpg.de> Message-ID: <9EA4069FDCB059418A892D47A25498E4573046@SONNE.cpg.de> Hi Boris, Many thanks for your help and your quick reply. I hadn't been aware that I changed my global locale. I have to change my software in that way. Best regards, Peter -----Urspr?ngliche Nachricht----- Von: Boris Kolpackov [mailto:boris@codesynthesis.com] Gesendet: Mittwoch, 25. Februar 2015 16:54 An: Sibinger Peter Cc: xsd-users@codesynthesis.com Betreff: Re: [xsd-users] serialize problems: thousands separator in gyear_month and unsigned long Hi Peter, Sibinger Peter writes: > E.g. in date-time.txx the values x.year=2014 and x.month=12 resulted > in a stream "2.014-12". > > The only solution I found was to add the classic "C" locale to get > no thousands separator. I think something in your application changes the global locale (std::locale::global(); "C" by default). I believe this is a bad idea and will lead to all kinds of breakages. I also don't think explicitly setting "C" locale on each stream that XSD ever creates is a good solution. It will be a performance drag and is unnecessary in 99.9% (in the 10 years that XSD was around you are the first person to have this problem). I found this page has quite a bit of background information on C and C++ locales: http://stdcxx.apache.org/doc/stdlibug/24-3.html Boris From boris at codesynthesis.com Thu Feb 26 04:45:25 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Feb 26 04:55:56 2015 Subject: [xsd-users] Template for member created by Code Synthesis In-Reply-To: <1424890488495.8923@bah.com> References: <1424890488495.8923@bah.com> Message-ID: Hi Hillel, Markowitz, Hillel [USA] writes: > I would like to set up templates to handle certain members that > will be added in the future. I would like to use the templates > so that I do not get a compilation file before the updated include > files and libraries are installed. > > > for example baseclass.myMemberA().push_back(basedata); Ok, if I understood the above correctly, you are looking for a way to test at C++-compile-time whether a class has a certain member. If you are using C++11, this can be easily done with the expression SFINAE. E.g., something along these lines: template auto MemberA_push_back (const T* baseclass, const BaseData* basedata) -> decltype (baseclass->myMemberA().push_back (*basedata)) { baseclass->myMemberA().push_back (*basedata); } template void MemberA_push_back (...) {} MemberA_push_back (&baseclass, &basedata) You could also probably use enable_if instead of function return types. Boris From boris at codesynthesis.com Thu Feb 26 04:47:14 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Feb 26 04:57:44 2015 Subject: [xsd-users] FreeBSD compilation error In-Reply-To: References: <2E43CD35-4C57-4890-BE8B-20D308BEF2A0@gmail.com> <504AAAE7-3590-42A8-9E12-E6B3027B2296@gmail.com> Message-ID: Hi Maxim, Maxim Maslennikov writes: > FreeBSD doesn?t install bash by default. Can I use sh or I should > install bash? Yes, you need bash as stated in the README file. > Concerning assertion failed in float test how did you solve the > issue in mac os x clang? I don't think we have tested clang with libc++ yet. Boris From boris at codesynthesis.com Thu Feb 26 04:49:12 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Feb 26 04:59:43 2015 Subject: [xsd-users] Support for list initialization In-Reply-To: <1F897018A4B45549AE2FE45B2DFF9E3A9F6091@EX-TT-AC-01.traveltainment.int> References: <1F897018A4B45549AE2FE45B2DFF9E3A9F6091@EX-TT-AC-01.traveltainment.int> Message-ID: Hi Yury, Thanks for the patch. I've added an item to the TODO list. Boris From Markowitz_Hillel at bah.com Thu Feb 26 17:23:22 2015 From: Markowitz_Hillel at bah.com (Markowitz, Hillel [USA]) Date: Fri Feb 27 06:05:34 2015 Subject: [External] Re: [xsd-users] Template for member created by Code Synthesis In-Reply-To: References: <1424890488495.8923@bah.com>, Message-ID: <1424989402145.2318@bah.com> Thank you. looking at this, I see that it explicitly has memberA_pushback. I have been able to create templates that will use the generic member as long as the member exists in the base class. However, consider the case in which memberA, memberB, ..., memberL all exist while memberM, ..., memberZ have not yet been implemented. i do not have control of the relevant library but would like to be able to set up a generic template rather than have to write a unique one for each member. Looking at the enable_if I am not sure what needs to be done to create the appropriate boolean. I have set it up to return a boolean as well instead of a void which has worked so far. I also have a more complex set of mainClass::BaseClass baseclass; mainClass::MemberClassA mymember("baseData); mymember.setContexts(contextData); baseclass.memberClassA().push_back(mymember); However, I would first want to get the simple case solved if possible. I am also including my outside email in the cc: line so that I can see this and your response at home. Thank you for answering me. -- Hillel Eli Markowitz Booz Allen Hamilton Markowitz_Hillel@bah.com Hillel.Markowitz@gmail.com ________________________________________ From: Boris Kolpackov Sent: Thursday, February 26, 2015 4:45 AM To: Markowitz, Hillel [USA] Cc: xsd-users@codesynthesis.com Subject: [External] Re: [xsd-users] Template for member created by Code Synthesis Hi Hillel, Markowitz, Hillel [USA] writes: > I would like to set up templates to handle certain members that > will be added in the future. I would like to use the templates > so that I do not get a compilation file before the updated include > files and libraries are installed. > > > for example baseclass.myMemberA().push_back(basedata); Ok, if I understood the above correctly, you are looking for a way to test at C++-compile-time whether a class has a certain member. If you are using C++11, this can be easily done with the expression SFINAE. E.g., something along these lines: template auto MemberA_push_back (const T* baseclass, const BaseData* basedata) -> decltype (baseclass->myMemberA().push_back (*basedata)) { baseclass->myMemberA().push_back (*basedata); } template void MemberA_push_back (...) {} MemberA_push_back (&baseclass, &basedata) You could also probably use enable_if instead of function return types. Boris From boris at codesynthesis.com Fri Feb 27 06:36:18 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Feb 27 06:46:49 2015 Subject: [External] Re: [xsd-users] Template for member created by Code Synthesis In-Reply-To: <1424989402145.2318@bah.com> References: <1424890488495.8923@bah.com> <1424989402145.2318@bah.com> Message-ID: Hi Hillel, Markowitz, Hillel [USA] writes: > Thank you. looking at this, I see that it explicitly has memberA_pushback. > I have been able to create templates that will use the generic member > as long as the member exists in the base class. However, consider the > case in which memberA, memberB, ..., memberL all exist while memberM, > ..., memberZ have not yet been implemented. i do not have control of > the relevant library but would like to be able to set up a generic > template rather than have to write a unique one for each member. I don't think you can have it both ways. You can pass a member name in the form of a pointer to member function. But if you spell it out in your code and it doesn't exist, you will get a compile error. Or, you can specify it in a SFINAE expression without the compile error but you have to spell it out. Perhaps you can use the first approach for the implementation and the second as a thin wrapper over it (maybe with some macros to shorten things up even more). Boris From Markowitz_Hillel at bah.com Fri Feb 27 12:52:25 2015 From: Markowitz_Hillel at bah.com (Markowitz, Hillel [USA]) Date: Mon Mar 2 08:37:56 2015 Subject: [External] Re: [xsd-users] Template for member created by Code Synthesis In-Reply-To: References: <1424890488495.8923@bah.com>, Message-ID: <1425059544777.24538@bah.com> I got the smaller case working however, I have another case that is built in the form ::maindata::Subdata mydata(indata); // processing to add other information to mydata base.subData().push_back(mydata); However, it fails when I set up the template as template auto pushSubData(D indata, b &base, AttrType attrData) -> decltype(base.subData(), bool()) { doPush<::maindata::Subdata>(mydata, base.subData(), attrData); // This breaks the compiler return true; } However, when I change it to doPush(mydata, base.subData(), attrData); // This breaks the compiler It does compile successfully. What am I doing wrong in the specification. Shouldn't the template skip this segment when subData() is not a member of base? Would this be a valid way of trying it? maindata.subData.push_back(myData); auto newData = maindata.subData().back(); newData.attributes = attrData; -- Hillel Eli Markowitz Booz Allen Hamilton Markowitz_Hillel@bah.com Hillel.Markowitz@gmail.com ________________________________________ From: Boris Kolpackov Sent: Thursday, February 26, 2015 4:45 AM To: Markowitz, Hillel [USA] Cc: xsd-users@codesynthesis.com Subject: [External] Re: [xsd-users] Template for member created by Code Synthesis Hi Hillel, Markowitz, Hillel [USA] writes: > I would like to set up templates to handle certain members that > will be added in the future. I would like to use the templates > so that I do not get a compilation file before the updated include > files and libraries are installed. > > > for example baseclass.myMemberA().push_back(basedata); Ok, if I understood the above correctly, you are looking for a way to test at C++-compile-time whether a class has a certain member. If you are using C++11, this can be easily done with the expression SFINAE. E.g., something along these lines: template auto MemberA_push_back (const T* baseclass, const BaseData* basedata) -> decltype (baseclass->myMemberA().push_back (*basedata)) { baseclass->myMemberA().push_back (*basedata); } template void MemberA_push_back (...) {} MemberA_push_back (&baseclass, &basedata) You could also probably use enable_if instead of function return types. Boris