Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Another Code Sample for Crituque

Reply
Thread Tools

Another Code Sample for Crituque

 
 
Steven T. Hatton
Guest
Posts: n/a
 
      06-08-2004
The short sample program listed below has some features that I find to be
bad style. In particular, they fail to communicate the connection between
names used in this program and the location in which they are declared and
or defined. I'd like to know if there are any features of this code you
believe represents bad programming technique. How would the feature be
better implemented?

/*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999-2003 The Apache Software Foundation. All rights
* reserved.
* Please visit the following url for the complete license statement:


http://cvs.apache.org/viewcvs.cgi/xm...1.18&view=auto
*/

/*
* $Id: CreateDOMDocument.cpp,v 1.18 2003/12/10 23:48:53 neilg Exp $
*/

/*
* This sample illustrates how you can create a DOM tree in memory.
* It then prints the count of elements in the tree.
*/


//
---------------------------------------------------------------------------
// Includes
//
---------------------------------------------------------------------------
#include <xercesc/util/PlatformUtils.hpp>
#include <xercesc/util/XMLString.hpp>
#include <xercesc/dom/DOM.hpp>
#if defined(XERCES_NEW_IOSTREAMS)
#include <iostream>
#else
#include <iostream.h>
#endif

XERCES_CPP_NAMESPACE_USE

//
---------------------------------------------------------------------------
// This is a simple class that lets us do easy (though not terribly
efficient)
// trancoding of char* data to XMLCh data.
//
---------------------------------------------------------------------------
class XStr
{
public :
//
-----------------------------------------------------------------------
// Constructors and Destructor
//
-----------------------------------------------------------------------
XStr(const char* const toTranscode)
{
// Call the private transcoding method
fUnicodeForm = XMLString::transcode(toTranscode);
}

~XStr()
{
XMLString::release(&fUnicodeForm);
}


//
-----------------------------------------------------------------------
// Getter methods
//
-----------------------------------------------------------------------
const XMLCh* unicodeForm() const
{
return fUnicodeForm;
}

private :
//
-----------------------------------------------------------------------
// Private data members
//
// fUnicodeForm
// This is the Unicode XMLCh format of the string.
//
-----------------------------------------------------------------------
XMLCh* fUnicodeForm;
};

#define X(str) XStr(str).unicodeForm()


//
---------------------------------------------------------------------------
// main
//
---------------------------------------------------------------------------

int main(int argC, char* argV[])
{
// Initialize the XML4C2 system.
try
{
XMLPlatformUtils::Initialize();
}

catch(const XMLException& toCatch)
{
char *pMsg = XMLString::transcode(toCatch.getMessage());
XERCES_STD_QUALIFIER cerr << "Error during Xerces-c Initialization
\n"
<< " Exception message:"
<< pMsg;
XMLString::release(&pMsg);
return 1;
}

// Watch for special case help request
int errorCode = 0;
if (argC > 1)
{
XERCES_STD_QUALIFIER cout << "\nUsage:\n"
" CreateDOMDocument\n\n"
"This program creates a new DOM document from scratch in
memory.\n"
"It then prints the count of elements in the tree.\n"
<< XERCES_STD_QUALIFIER endl;
errorCode = 1;
}
if(errorCode) {
XMLPlatformUtils::Terminate();
return errorCode;
}

{
// Nest entire test in an inner block.
// The tree we create below is the same that the XercesDOMParser
would
// have created, except that no whitespace text nodes would be
created.

// <company>
// <product>Xerces-C</product>
// <category idea='great'>XML Parsing Tools</category>
// <developedBy>Apache Software Foundation</developedBy>
// </company>

DOMImplementation* impl =
DOMImplementationRegistry::getDOMImplementation(X( "Core"));

if (impl != NULL)
{
try
{
DOMDocument* doc = impl->createDocument(
0, // root element namespace
URI.
X("company"), // root element name
0); // document type object
(DTD).

DOMElement* rootElem = doc->getDocumentElement();

DOMElement* prodElem = doc->createElement(X("product"));
rootElem->appendChild(prodElem);

DOMText* prodDataVal = doc->createTextNode(X("Xerces-C"));
prodElem->appendChild(prodDataVal);

DOMElement* catElem = doc->createElement(X("category"));
rootElem->appendChild(catElem);

catElem->setAttribute(X("idea"), X("great"));

DOMText* catDataVal = doc->createTextNode(X("XML Parsing
Tools"));
catElem->appendChild(catDataVal);

DOMElement* devByElem =
doc->createElement(X("developedBy"));
rootElem->appendChild(devByElem);

DOMText* devByDataVal = doc->createTextNode(X("Apache
Software Foundation"));
devByElem->appendChild(devByDataVal);

//
// Now count the number of elements in the above DOM tree.
//

unsigned int elementCount =
doc->getElementsByTagName(X("*"))->getLength();
XERCES_STD_QUALIFIER cout << "The tree just created contains:
" << elementCount
<< " elements." << XERCES_STD_QUALIFIER endl;

doc->release();
}

catch (const DOMException& e)
{
XERCES_STD_QUALIFIER cerr << "DOMException code is: " <<
e.code << XERCES_STD_QUALIFIER endl;
errorCode = 2;
}
catch (...)
{
XERCES_STD_QUALIFIER cerr << "An error occurred creating the
document" << XERCES_STD_QUALIFIER endl;
errorCode = 3;
}
} // (inpl != NULL)
else
{
XERCES_STD_QUALIFIER cerr << "Requested implementation is not
supported" << XERCES_STD_QUALIFIER endl;
errorCode = 4;
}
}

XMLPlatformUtils::Terminate();
return errorCode;
}
--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org
 
Reply With Quote
 
 
 
 
Steven T. Hatton
Guest
Posts: n/a
 
      06-09-2004
Steven T. Hatton wrote:

> The short sample program listed below has some features that I find to be
> bad style. In particular, they fail to communicate the connection between
> names used in this program and the location in which they are declared and
> or defined. I'd like to know if there are any features of this code you
> believe represents bad programming technique. How would the feature be
> better implemented?
>
> /*
> * The Apache Software License, Version 1.1
> *
> * Copyright (c) 1999-2003 The Apache Software Foundation. All rights
> * reserved.
> * Please visit the following url for the complete license statement:
>
>
>

http://cvs.apache.org/viewcvs.cgi/xm...1.18&view=auto
> */

---------------------------------------------------------------------------
> // Includes
> //
>

---------------------------------------------------------------------------
> #include <xercesc/util/PlatformUtils.hpp>
> #include <xercesc/util/XMLString.hpp>
> #include <xercesc/dom/DOM.hpp>
> #if defined(XERCES_NEW_IOSTREAMS)
> #include <iostream>
> #else
> #include <iostream.h>
> #endif


What is this? Is it grammatically part of C++?

> XERCES_CPP_NAMESPACE_USE
>
> //

At a second level of #inclusion I found this:

//
---------------------------------------------------------------------------
// Define namespace symbols if the compiler supports it.
//
---------------------------------------------------------------------------
#if defined(XERCES_HAS_CPP_NAMESPACE)
#define XERCES_CPP_NAMESPACE_BEGIN namespace XERCES_CPP_NAMESPACE {
#define XERCES_CPP_NAMESPACE_END }
#define XERCES_CPP_NAMESPACE_USE using namespace XERCES_CPP_NAMESPACE;
#define XERCES_CPP_NAMESPACE_QUALIFIER XERCES_CPP_NAMESPACE::

namespace XERCES_CPP_NAMESPACE { }
namespace xercesc = XERCES_CPP_NAMESPACE;
#else
#define XERCES_CPP_NAMESPACE_BEGIN
#define XERCES_CPP_NAMESPACE_END
#define XERCES_CPP_NAMESPACE_USE
#define XERCES_CPP_NAMESPACE_QUALIFIER
#endif

I find that downright depressing.


This is C programming, not C++.
> > #define X(str) XStr(str).unicodeForm()


--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org
 
Reply With Quote
 
 
 
 
Steven T. Hatton
Guest
Posts: n/a
 
      06-10-2004
This is from the same sample code I posted earlier. I believe the form of
the function main shown here is not specified in the Standard, and the
Standard does not require an implementation to successfully compile it. Do
you agree?

int main(int argC, char* argV[])
{}

--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org
 
Reply With Quote
 
Robert Bauck Hamar
Guest
Posts: n/a
 
      06-10-2004
In article <(E-Mail Removed)>, Steven T. Hatton wrote:
> This is from the same sample code I posted earlier. I believe the form of
> the function main shown here is not specified in the Standard, and the
> Standard does not require an implementation to successfully compile it. Do
> you agree?
>
> int main(int argC, char* argV[])
> {}
>


From §3.6.1:
All implementations shall allow both of the following definitions of
main:

int main() { /* ... */ }
and
int main(int argc, char* argv[]) { /* ... */ }

--
Robert Bauck Hamar
 
Reply With Quote
 
Robert Bauck Hamar
Guest
Posts: n/a
 
      06-10-2004
In article <(E-Mail Removed)> , Robert Bauck Hamar wrote:
> In article <(E-Mail Removed)>, Steven T. Hatton wrote:
>> This is from the same sample code I posted earlier. I believe the form of
>> the function main shown here is not specified in the Standard, and the
>> Standard does not require an implementation to successfully compile it. Do
>> you agree?
>>
>> int main(int argC, char* argV[])
>> {}
>>

>
> From §3.6.1:
> All implementations shall allow both of the following definitions of
> main:
>
> int main() { /* ... */ }
> and
> int main(int argc, char* argv[]) { /* ... */ }
>


And I forgot:
If control reaches the end of main without encountering a return
statement, the effect is that of executing
return 0;

--
Robert Bauck Hamar
 
Reply With Quote
 
Steven T. Hatton
Guest
Posts: n/a
 
      06-10-2004
Robert Bauck Hamar wrote:

> In article <(E-Mail Removed)>, Steven T. Hatton wrote:
>> This is from the same sample code I posted earlier. I believe the form
>> of the function main shown here is not specified in the Standard, and the
>> Standard does not require an implementation to successfully compile it.
>> Do you agree?
>>
>> int main(int argC, char* argV[])
>> {}
>>

>
> From §3.6.1:
> All implementations shall allow both of the following definitions of
> main:
>
> int main() { /* ... */ }
> and
> int main(int argc, char* argv[]) { /* ... */ }
>

So I conclude that the form I presented is not specified by the standard.
--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org
 
Reply With Quote
 
Robert Bauck Hamar
Guest
Posts: n/a
 
      06-10-2004
In article <(E-Mail Removed)>, Steven T. Hatton wrote:
> Robert Bauck Hamar wrote:
>
>> In article <(E-Mail Removed)>, Steven T. Hatton wrote:
>>> This is from the same sample code I posted earlier. I believe the form
>>> of the function main shown here is not specified in the Standard, and the
>>> Standard does not require an implementation to successfully compile it.
>>> Do you agree?
>>>
>>> int main(int argC, char* argV[])
>>> {}
>>>

>>
>> From §3.6.1:
>> All implementations shall allow both of the following definitions of
>> main:
>>
>> int main() { /* ... */ }
>> and
>> int main(int argc, char* argv[]) { /* ... */ }
>>

> So I conclude that the form I presented is not specified by the standard.


If you are thinking about the naming of the parameters, then I cannot
see that the standard says anything more than I just wrote. Mark that
main should not be overloaded and must return an int, but othervise it's
type is implementation defined.
--
Robert Bauck Hamar
 
Reply With Quote
 
Steven T. Hatton
Guest
Posts: n/a
 
      06-10-2004
Robert Bauck Hamar wrote:

> In article <(E-Mail Removed)>, Steven T. Hatton wrote:
>> Robert Bauck Hamar wrote:
>>
>>> In article <(E-Mail Removed)>, Steven T. Hatton
>>> wrote:
>>>> This is from the same sample code I posted earlier. I believe the form
>>>> of the function main shown here is not specified in the Standard, and
>>>> the Standard does not require an implementation to successfully compile
>>>> it. Do you agree?
>>>>
>>>> int main(int argC, char* argV[])
>>>> {}
>>>>
>>>
>>> From §3.6.1:
>>> All implementations shall allow both of the following definitions of
>>> main:
>>>
>>> int main() { /* ... */ }
>>> and
>>> int main(int argc, char* argv[]) { /* ... */ }
>>>

>> So I conclude that the form I presented is not specified by the standard.

>
> If you are thinking about the naming of the parameters, then I cannot
> see that the standard says anything more than I just wrote. Mark that
> main should not be overloaded and must return an int, but othervise it's
> type is implementation defined.

Yes, the names. Do you understand the Standard to be requiring the names to
be exactly those used in the text of the Standard? I understand it to be
saying that.
--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org
 
Reply With Quote
 
Robert Bauck Hamar
Guest
Posts: n/a
 
      06-10-2004
In article <(E-Mail Removed)>, Steven T. Hatton wrote:
> Robert Bauck Hamar wrote:
>
>> In article <(E-Mail Removed)>, Steven T. Hatton wrote:
>>> Robert Bauck Hamar wrote:
>>>
>>>> In article <(E-Mail Removed)>, Steven T. Hatton
>>>> wrote:
>>>>> This is from the same sample code I posted earlier. I believe the form
>>>>> of the function main shown here is not specified in the Standard, and
>>>>> the Standard does not require an implementation to successfully compile
>>>>> it. Do you agree?
>>>>>
>>>>> int main(int argC, char* argV[])
>>>>> {}
>>>>>
>>>>
>>>> From §3.6.1:
>>>> All implementations shall allow both of the following definitions of
>>>> main:
>>>>
>>>> int main() { /* ... */ }
>>>> and
>>>> int main(int argc, char* argv[]) { /* ... */ }
>>>>
>>> So I conclude that the form I presented is not specified by the standard.

>>
>> If you are thinking about the naming of the parameters, then I cannot
>> see that the standard says anything more than I just wrote. Mark that
>> main should not be overloaded and must return an int, but othervise it's
>> type is implementation defined.

> Yes, the names. Do you understand the Standard to be requiring the names to
> be exactly those used in the text of the Standard? I understand it to be
> saying that.


Considering §3.6.1 [basic.start.main] alone, yes. Grepping the standard
for main, I found mostly main() in examples. Two examples in §22.2.8
defined:
int main(int argc, char** argv) { /* ... */ }
I also searched for argc and argv, but i found nothing more than §3.6.1,
the same examples, and C compitability issues.

--
Robert Bauck Hamar
 
Reply With Quote
 
red floyd
Guest
Posts: n/a
 
      06-10-2004
Robert Bauck Hamar wrote:
> In article <(E-Mail Removed)>, Steven T. Hatton wrote:
>
>>Robert Bauck Hamar wrote:
>>
>>
>>>In article <(E-Mail Removed)>, Steven T. Hatton wrote:
>>>
>>>>Robert Bauck Hamar wrote:
>>>>
>>>>
>>>>>In article <(E-Mail Removed)>, Steven T. Hatton
>>>>>wrote:
>>>>>
>>>>>>This is from the same sample code I posted earlier. I believe the form
>>>>>>of the function main shown here is not specified in the Standard, and
>>>>>>the Standard does not require an implementation to successfully compile
>>>>>>it. Do you agree?
>>>>>>
>>>>>>int main(int argC, char* argV[])
>>>>>>{}
>>>>>>
>>>>>
>>>>>From §3.6.1:
>>>>>All implementations shall allow both of the following definitions of
>>>>>main:
>>>>>
>>>>>int main() { /* ... */ }
>>>>>and
>>>>>int main(int argc, char* argv[]) { /* ... */ }
>>>>>
>>>>
>>>>So I conclude that the form I presented is not specified by the standard.
>>>
>>>If you are thinking about the naming of the parameters, then I cannot
>>>see that the standard says anything more than I just wrote. Mark that
>>>main should not be overloaded and must return an int, but othervise it's
>>>type is implementation defined.

>>
>>Yes, the names. Do you understand the Standard to be requiring the names to
>>be exactly those used in the text of the Standard? I understand it to be
>>saying that.

>
>
> Considering §3.6.1 [basic.start.main] alone, yes. Grepping the standard
> for main, I found mostly main() in examples. Two examples in §22.2.8
> defined:
> int main(int argc, char** argv) { /* ... */ }
> I also searched for argc and argv, but i found nothing more than §3.6.1,
> the same examples, and C compitability issues.
>


I don't know... I've also compiled (but don't know if it's complaint)

int main(int, char*[])
{
}
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Sample code for doing a “chunked” webfile HTTP d ownload, andthen stream to HTTP upload to another web app? Greg Hauptmann Ruby 1 12-08-2009 06:37 PM
looking for asp.net sample with vb.net backend sample is there one? Jake ASP .Net 0 02-09-2006 10:44 PM
PN: Sample code to call another program/command from inside a C++ program Peter Nolan C++ 4 04-08-2004 08:33 PM
Sample Code That Instruments Java Byte Code? CHANGE username to westes Java 1 10-14-2003 06:10 AM
Code review of cross platform code sample Otto Wyss C++ 5 09-07-2003 02:06 PM



Advertisments