Letters

We Have Mail

Letters to the editor may be sent via email to cujed@cmp.com, or via the postal service to Letters to the Editor, C/C++ Users Journal, 1601 W. 23rd St., Ste 200, Lawrence, KS 66046-2700.

Hello,

I’ve read this article [“Documenting the Graphic Import Filter Interface,” by Bret Pehrson, CUJ, March 2001] with great interest, since I’m developing an own graphic import filter myself. However, it is not fully correct, that the filter interface is undocumented so far. In addition to the sources mentioned in the article I know about the following additional source of information:

1) “Graphic Import Filters for Windows Applications”, Dr. Dobbs Journal, July 92, pp. 82-110. 2) Chapter: “Das Aldus Importfilter Format” in Grafikformate by Thomas Lipp (Microsoft Press, ISBN 3-86063-391-0). This book includes also a CD-ROM with the needed header files and and example. Unfortunately for you, it is in German.

Further, I’d like to point you to the import filter that I have built. This filter allows programmers to import PostScript or PDF as vector graphics. It can be found at: <www.geocities.com/wglunz/importps/>.

Finally, I’d like to mention that in addition to MS-Office, also other applications like PaintShop-Pro or Photoline (<http://www.pl32.com/>) support this interface. PaintShop-Pro needs other registry entries, though.

Best Regards,

Wolfgang Glunz

Dear CUJ,

I wanted to take the time to stress my overall direction with regards to computers.

  1. I have subscribed to C/C++ Users Journal for ten years now.
  2. I no longer use Windows as my primary operating system. It has been replace by Linux.
  3. Windows has been placed on my legacy list miles and miles below DOS.
  4. I will not use or even look at C#.
  5. I do not want to see C# as part of the C/C++ Users Journal.
  6. If the C/C++ Users Journal becomes C/C++/C#, I will cancel my subscription.

A year ago, 100% of my systems were based on Microsoft products. That number has been reduced to 30%.

As a C/C++ Users Journal customer, I would like to see more Linux related articles and less Windows related articles.

Harry Barrett

Although I will soon have little control over the content and direction of CUJ (see my Editor’s Forum), I think I can safely say that CUJ is not going to turn into C/C++/C# Users Journal or any other such monstrosity. That said, CUJ will be publishing at least one C# article in coming months. That is my doing; I have always believed that it was healthy to have a look at closely related languages to see what they have to offer. C# does have a few features that may be of interest to C++ programmers. For example, the C# delegate type is somewhat like a function pointer, but much more versatile. Some readers might want to see if there’s a way to simulate its semantics in C++.

I am no big fan of Microsoft, but that doesn’t stop me from using their products. Likewise, CUJ will not refuse to cover something just because it’s produced by Microsoft. I simply cannot believe that is an effective policy for running a magazine, or for that matter, developing software. — mb

Dear CUJ,

I read with interest Alan Griffith’s “Here Be Dragons” article in CUJ March 2001 edition.

I must point out however, that the unwary traveller may unexpectedly be disembowelled by a familiar beast lurking in the undergrowth; this fiend being the “attempt to dereference a null pointer exception,” when using the copy constructor for Whole as shown in the article.

Perhaps we should make use of our fickle friend, the conditional expression, to render this beast harmless?

Whole::Whole(const Whole& rhs)
: p1(rhs.p1.get() ?
     new PartOne(*rhs.p1) : NULL),
  p2(rhs.p2.get() ?
     new PartTwo(*rhs.p2) : NULL)
{
}

With the dereferencing of the pointer members of Whole thus guarded, we can continue our journey with confidence.

Regards,

Mike da Silva

We forwarded your message to Alan Griffiths, but have not heard back from him, so I will try to fake a reply. First, some context for readers unfamiliar with the article. The copy constructor you refer to is part of the Whole class shown below:

class PartOne { ... };
class PartTwo { ... };

class Whole
{
public:
   ... // other stuff
   Whole::Whole(const Whole& rhs);
   ... // other stuff
private:
   std::auto_ptr<PartOne> p1;
   std::auto_ptr<PartTwo> p2;
};

The copy constructor attempts to make copies of the PartOne and PartTwo objects being referenced by rhs.p1 and rhs.p2.

Absent any other information about class Whole, it appears that it may be possible to construct a Whole object with members p1 and p2 wrapping null pointers. As you point out, a naive attempt to copy construct from such a “null-content” object would likely be disastrous.

In Griffiths’ defense, if he had included your “fickle friend” the query operator in his code snippets, it would have been very distracting from the main point he was trying to make. I would also suggest that a better solution than yours would be to disallow such null-content objects to be constructed in the first place. I suspect this is what Griffiths had in mind, but to bring it up would have distracted from the discussion at hand. This is always the challenge in technical writing: to balance robustness with readability. All in all, I think Griffiths did a pretty decent job. But thanks for alerting us to the danger. — mb

Dear CUJ,

Send congratulations to Herb for taking the initiative to pull this survey [“Compiler Conformance Roundup,” CUJ, April 2001] together. Indeed, a yearly roundup will be a great tool for C++ software engineers and architects. The perennial information was, IMHO, very interesting to read and compare.

Dr. Nicolas Rouquette
Mission Execution & Automation
Jet Propulsion Laboratory
<http://www.jpl.nasa.gov>

We will certainly pass along your kudos to Herb. Thanks for writing. — mb

Hello Gents,

We have just read the article by Steve Vinoski and Douglas Schmidt about CORBA and the integration of the C++ Standard, in the C/C++ Users Journal Experts Forum. [See “Object Interconnections: Standard C++ and the OMG C++ Mapping,” <www.cuj.com/experts/1901/vinoski.htm>; and “Object Interconnections: Using Standard C++ in the OMG C++ Mapping,” <www.cuj.com/experts/1904/vinoski.htm>.]

The paper is quite interesting since it contradicts our position.

Our major criticism is that the arguments seem to be driven from the viewpoint of an implementor of an ORB with a running solution and not from the requirements that the user of an ORB has. The requirements of the users are very important and shall drive the design of any public interface under the restrictions that it must be implementable.

From the users’ point of view it is clearly favorable to use the standards of the language as far as possible. In particular this is true for C++ since the available standard library is very powerful, flexible, and efficient at the same time.

Currently we always recommend not to use CORBA in conjunction with C++ because the language binding is of hardly acceptable quality. We would appreciate if this changes in the future because we would like to see such a major standard technology move forward.

Regards,

Detlef Hoeffner
Dietmar Kuehl