By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,042 Members | 1,036 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,042 IT Pros & Developers. It's quick & easy.

Types as tags and RTTI for flow control

P: n/a
I'm trying to work out a design for dynamically determining file types, and
for generating new files of a given type. I'm curious to know what others
think of my current strategy. Is it "so einfach wie möglich machen, aber
nicht einfacher" or "Rube Goldberg"?

The first part of this has to do with a technique used in the C++ Standard
Library, so I suspect the purist will not have any objection. It's the
approach used to build the inheritance hierarchy for iterators. Understand
"Role" to mean what role a file has such as header, source, etc. I have
organized my types as follows:

namespace files {
struct FileRole {};
struct CppRole : FileRole{};
struct CppSrcRole : CppRole {};
struct CppHeaderRole: CppRole {};

// create a functor class that takes some kind of descriptive
// statement about a file, and returns role information in the
// form of a subclass of FileRole.

struct RoleRecognizer {
virtual FileRole* operator(const QFileInfo& fileInfo) const = 0;
};

// There is a problem, however. There are no virtual functions in
// any of the types derived from FileRole. The type information is,
// therefore only useful at compiletime. So I do this:
struct FileRole {virtual ~FileRole (){}};
struct CppRole : FileRole{virtual ~CppRole (){}};
struct CppSrcRole : CppRole {virtual ~CppSrcRole (){}};
struct CppHeaderRole: CppRole {virtual ~CppHeaderRole(){}};
}

I can now sniff the return value from RoleRecognizer::operator(fileInfo); to
determin, at runtime, what kind of file I have. A much simpler approach
would be to use an enum such as

enum Role {
FileRole,
CppRole,
CppSrcRole,
CppHeaderRole
};

And then return values of type Role.

There are problems with this approach. For one, I have never like the open
nature of enums. I can check that the value I pass is declared to be of a
given enum type, but I cannot ensure the value is one of those declared in
the enum definition. Enums are therefore, to some extent nondeterministic.
One great advantage to using enums is that they require very little simple
to declare. There is a disadvantage that comes with that simplicity. I
cannot later add functionality to an enum value such as a conversion
operator to std::string.

IIRC, Stroustrup cautions against using RTTI for flow control. There are
places, such as in 3D graphics, where I have seen RTTI used to great
advantage. I intend to use RTTI for flow control when determining what
kind of object to create for an in-memory representation of a file. The
idea is to subclass RoleRecognizer to implement specific strategies for
resolving file roles. For example *.cpp vs *.cc, or extensionless
filesnames with file type meta information on the first line. Such as:

/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2005 Robert Osfield

Is this a path others have headed down, and found problematic?

--
NOUN:1. Money or property bequeathed to another by will. 2. Something handed
down from an ancestor or a predecessor or from the past: a legacy of
religious freedom. ETYMOLOGY: MidE legacie, office of a deputy, from OF,
from ML legatia, from L legare, to depute, bequeath. www.bartleby.com/61/
Mar 2 '06 #1
Share this Question
Share on Google+
3 Replies


P: n/a
Steven T. Hatton wrote:
I'm trying to work out a design for dynamically determining file types,
and for generating new files of a given type. I'm curious to know what
others think of my current strategy. Is it "so einfach wie möglich machen,
aber nicht einfacher" or "Rube Goldberg"?
Pardon me?
IIRC, Stroustrup cautions against using RTTI for flow control. There are
places, such as in 3D graphics, where I have seen RTTI used to great
advantage. I intend to use RTTI for flow control when determining what
kind of object to create for an in-memory representation of a file. The
idea is to subclass RoleRecognizer to implement specific strategies for
resolving file roles. For example *.cpp vs *.cc, or extensionless
filesnames with file type meta information on the first line. Such as:

/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2005 Robert Osfield

Is this a path others have headed down, and found problematic?


How about using a string instead that contains e.g. the name of your file's
mimetype, like "text/x-c++src"?

Mar 3 '06 #2

P: n/a

Steven T. Hatton wrote:

[]
The first part of this has to do with a technique used in the C++ Standard
Library, so I suspect the purist will not have any objection. It's the
approach used to build the inheritance hierarchy for iterators. Understand
"Role" to mean what role a file has such as header, source, etc. I have
organized my types as follows:

namespace files {
struct FileRole {};
struct CppRole : FileRole{};
struct CppSrcRole : CppRole {};
struct CppHeaderRole: CppRole {};

// create a functor class that takes some kind of descriptive
// statement about a file, and returns role information in the
// form of a subclass of FileRole.

struct RoleRecognizer {
virtual FileRole* operator(const QFileInfo& fileInfo) const = 0;
};

// There is a problem, however. There are no virtual functions in
// any of the types derived from FileRole. The type information is,
// therefore only useful at compiletime. So I do this:
struct FileRole {virtual ~FileRole (){}};
struct CppRole : FileRole{virtual ~CppRole (){}};
struct CppSrcRole : CppRole {virtual ~CppSrcRole (){}};
struct CppHeaderRole: CppRole {virtual ~CppHeaderRole(){}};
}

I can now sniff the return value from RoleRecognizer::operator(fileInfo); to
determin, at runtime, what kind of file I have. A much simpler approach
would be to use an enum such as
[]
IIRC, Stroustrup cautions against using RTTI for flow control. There are
places, such as in 3D graphics, where I have seen RTTI used to great
advantage. I intend to use RTTI for flow control when determining what
kind of object to create for an in-memory representation of a file. The


Just dispatch to a virtual function overriden in derived classes of the
returned object, or use visitor pattern.

Mar 3 '06 #3

P: n/a
Rolf Magnus wrote:
Steven T. Hatton wrote:
I'm trying to work out a design for dynamically determining file types,
and for generating new files of a given type. I'm curious to know what
others think of my current strategy. Is it "so einfach wie möglich
machen, aber nicht einfacher" or "Rube Goldberg"?


Pardon me?


"Man soll die Dinge so einfach wie möglich machen, aber nicht noch
einfacher". See the epigraph of TC++PL, Chapter 24.

http://www.rubegoldberg.com/
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2005 Robert Osfield

Is this a path others have headed down, and found problematic?


How about using a string instead that contains e.g. the name of your
file's mimetype, like "text/x-c++src"?


I'm the victim, not the perpetrator. What I'm trying to do is break the
binding between file type determination mechanisms and the mechanisms that
depend on file types. Mimetypes will serve as the lingua Franka between
components, but I have to get there first.
--
NOUN:1. Money or property bequeathed to another by will. 2. Something handed
down from an ancestor or a predecessor or from the past: a legacy of
religious freedom. ETYMOLOGY: MidE legacie, office of a deputy, from OF,
from ML legatia, from L legare, to depute, bequeath. www.bartleby.com/61/
Mar 6 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.