Julie said:
Do you have the liberty to choose your language? If so, I'd recommend
looking at C# (and equivalent) were unit tests and story tests are much
better supported by the language.
Story test is not a term I am familiar with. Can you please explain what
this means? If forced to guess, I might speculate that these are basically
use cases?
In our C++ projects, we use CppTest,
I gave up trying to compile CppTest for linux. I'm not sure why it's
failing, but it appears no to like my versions of autotools. I've also had
a bad time trying to use the boost test library. I believe all of these
problems are related to the failure of the C++ Standard to more clearly
define the relationship between the program and the implementation
environment. Or perhaps it would be better to say that the concept of a
translation unit, with its implicit assumption that header files and
#includes are involved, leads to these kinds of difficulties.
It's almost comical that I sent a message - actually a repost - with the
following:
//---from Message-ID:<
[email protected]> ---
Now a tricky thing that comes into play is the relationship between
declaration and definition. I have to admit that falls into the category
of religious faith for me. Under most circumstances, it simply works, when
it doesn't I play with the environment variables, and linker options until
something good happens.
//------------- END excerpt ------------------------------------
And the next thing I did was try to use the boost test library which
resulted in errors telling me the linker was unable to resolve certain
symbols used in my (trivial) program. I know now that I can compile within
the boost source tree and these symbols resolve. I have yet to figure out
how and why this happens.
I say it's almost comical. The fact of the matter is that it is actually
sad. My background in IT is not primarily coding. For the most part, I've
done integration, highlevel design, configuration, troubleshooting,
hardware maintenance, etc.
<aside>
The fact of the matter is that my work in highlevel engineering left me
rather embarrassed and somewhat ashamed that I was more-or-less 'lording
over' programmers who IMO deserved more credit and recognition for their
work than I did for mine. I wasn't supervising them, but I was certainly
treated as if they were not as significant or valuable. I knew better.
</aside>
When studying computer science in college (while working fulltime) I was
inclined at one point to learn C++ as a focus. Unfortunately that wasn't
consistent with my current employment situation. I ended up focusing on
networking and system design. I did try to get some programming experience
when I could. Unfortunately, that usually resulted in 10% of my available
time being spent on actual coding, and the remainder spent on trying to
figure out what the particular library was not behaving as expected.
I've written code in perl, bash, JavaScript, C, Mathematica, POVRay, Java,
Icon, Ada, Lisp, and probably other languages I can't think of right now.
One advantage I get from having such diverse experience is that I have seen
how things are done in different languages, and on different platforms.
One of the most frightening results of my learning C++ - and this is really
difficult to explain - is that I now seem to understand Lisp much better
than I previously did. That may seem completely irrelevant to this
discussion, and to some extend it is. But it does offer a means of
introducing Emacs which is a huge exercise in self-inflicted Lisp.
I've mentioned this before. The first C implementation of Emacs was written
by James Gosling. That is the same James Gosling who created Java. It is
clear he employed many ideas from his Emacs experience when designing Java.
It's interesting to point out that Mathematica smells a whole lot like
Emacs and Lisp. Though they take very different approaches, Mathematica
and Java share some similarity in how they implemented libraries. One of
the most significant similarities is that both rely on the use of directory
names to locate packages by name. I'm not sure this is directly traceable
to Emacs, but it seems like a logical extension of the method used by Emacs
to integrate documentation and implementation in the Lisp code. As well as
the query mechanisms used to locate resources. Introspection seems like a
logical extension of that as well. That may, however, be attributable to
SmallTalk rather than Emacs Lisp.
What is important is not how it was accomplished, or even the details of
what was accomplished in these different cases. What is important is that
Emacs, Mathematica, and Java all use libraries which are selfdescribing,
and rely on clearly defined mechanisms for integrating libraries into the
programming environment. With C++ I am required to learn not one, but
often several languages in order to manages my compilation and integration.
For example, bjam has a language of its own. Makefiles use a very
simplistic language, and when used on any significantly large scale require
the use of automake, autoconf, aclocal, etc. This typically requires some
level of understanding of the syntax and semantics of the M4 macro language
as well as bash, or whatever other command interpreter you are using(e.g.,
DOS Shell).
It is simply an unreasonable burden to place on the programmer, and, AFAIK,
(almost) completely unnecessary. Sure there is Apache Ant which can be
used for building Java. Ant is far easier to learn than anything I've seen
for C++. For the most part, that is because the underlying mechanism is
more clearly defined, and simpler. There is no objective reason - that I
am aware of - preventing the same from being done with C++. I believe the
main reason it hasn't been done is that most C++ programmers have not
encountered the difficulties I'm describing. They simply do not work with
the extensive variety of tools and libraries I work with. They typically
use one particular IDE, and rely on it to manage their resources for them.
Since they have no extensive experience working with other programming
environments created for other languages, they do not appreciate the
advantages these tools can provide. When the strengths of these features
are pointed out as advantages these languages provide over C++ development
environments, the usual response from C++ programmers is to point out the
advantages C++ has over the other language, and to explicitly or implicitly
suggest that people who can't understand pointers and unchecked array
access are the only people who could benefit from these powerful features.
but we have since decided to re-write
in C#, and unit/story tests was one of the primary motivations.
Reflection (and attribute) support in the language proper *really*
facilitates unit test frameworks.
I see no fundamental reason that a C++ library (or better still an industry
guideline or standard) could not be created to support this functionality
as well as (other) introspective facilities. My own opinion is that C++
offers valuable features that these other languages lack. In C++ there is
far more fine-grained control over how program entities are manipulated,
and how they manipulate other program entities. I find the argument for
garbage collection rather weak now that I better understand the issue. C++
forces you to manage your resources well. For the most part, a program
that needs garbage collection is probably poorly designed. The use of
pointers and references is likewise something that promotes better
understanding of what you are actually doing.
The choice to leave built-in types, including pointers, uninitialized by
default was perhaps a bad choice. But there is no reason that I can see for
a compiler not to issue warnings when a pointer or arithmetic type variable
is not initialized. Better still, the IDE could detect this and indicate
it at edit-time. The biggest problem with C++ is not a fundamental problem
with the language. It is the failure to require the implementation to
resolve types to their point of definition based on language syntax and
semantics. If I were released from that responsibility, it would save me
the majority of time I spend working with C++. IOW, I spend more time
addressing infrastructure problems than I do writing code. Any time I try
to integrate a new library into my development environment, I can expect to
spend the better part of a day resolving issues related to configuration.
This is a major reason IDE support is so weak in C++. IDE developers have
to deal with the poorly defined and unpredictable nature of C++ library
management. Yes, C++ is a more complex language, and it isn't as easy to
parse as the others, but that isn't the problem. That challenge cannot be
addressed because of the obstacles presented by the #include mechanism.
