None of which you stated anywhere in this thread. If you are going
rant in vague unclear terms then you should expect some "reading
between the lines". And if someone misreads you (note "unless I'm
misreading the rants" above) most likely it was because you were
ranting instead of presenting clear points.
I didn't state it, because it isn't relevant to the topic, which by
the way is C++ Exceptions and where to handle them.
I replied once to your post, which is an attempt to derail the topic
into some C vs C++ argument that has already been done to death in
other threads. My point was and still is that usage of exceptions
require OO design, OO design requires OO design, and C-style code has
no business being mixed in with OO design. If a modual is programmed C-
style, than fine, the entire module needs to be consistant. However it
is poor practice to mix C-style and OO together in the same module.
The topic, which is exception handling, is one example of how mixing
the two foobars a project.
Indeed, most of this thread has centered on how /you/ were going
to /convince/ one or more of the team to follow this-and-such. Now
we are hearing for the first time that "it was officially decided".
The point of the thread was to gather evidence to back up my argument
and to ask if my argument was a valid one. Read the first post. We've
seen that my argument was not a valid one. Good! Isn't that the point
of the newsgroup? To discuss and learn?
And there you continue to repeat the fallacy that "C-Style" code
stands in oppostion to OO. That misunderstanding lies at the heart
of your ranting in my opinion.
It isn't a fallacy. It's an experience.
Who said I don't accept that C++ lends itself to different programming
stlyes? Who says I don't know the proper place for each? Who says I am
not familiar with free functions? Who says I am not familiar with
Macros? You? Evidence? Did you review my code as well?
Here are your exact words:
Where does it say "depend on a particular instance of an object
and it's member data"? And w.t.h does that even mean? How would
a function /not depend/ on the value of a object? Maybe you mean
it's accessing member variables directly? But who can know given
how vague and unclear the rant is. Again, if you are going to
rant, don't be surprised when you are misread.
It doesn't have to. The first paragraph points out bad design. The
second points out worse design. Why is that sentence hard to follow
for you? It's in pretty simple terms. What does hell have to do with
it?
---------------------------
"There are classes where the functionality is partly handled by global
functions and partly handled by class"
Or in other worse, crappy C-style code being mixed with OO code
breaking things and making life hell:
// Crappy code made a global pointer to data that should be owned by
MyClass
MyResource * resource = NULL;
// Crappy code performs functionality that should belong to MyClass
void DoSomethingElse()
{
// Crappy code doesn't check the pointer
resource->JumpUpAndDown();
// Crappy code makes calls that throw exceptions without
documentation
resource->CauseChaosAndThrowExceptions();
// Crappy code doesn't care about resource cleanup
if( resource->BadState() )
throw MyGenericException("Something unknown has happened");
}
class MyClass
{
public:
MyClass()
{
// Crappy code allocates and releases with no concept of
ownership
resource = new Resource();
}
void DoSomething()
{
// More Crappy Code
// Crappy code still doesn't care about cleanup
if( resource->IsTheSunUp() )
{
throw MyGenericException("I like nighttime");
}
}
private:
int m_number;
}
// Crappy code always seems to think main returns void
void main()
{
// Crappy code makes memory leaks
resource = new Resource();
MyClass mine;
mine.DoSomething();
// Crappy code loves unsafe casting
BYTE * data = (BYTE *)&mine;
// Crappy code loves appending things to allocated memory in an
unsafe manner
MyStructure * dataToSend = GetSomeStructure();
memcopy(dataToSend + 48, data, sizeof(data));
// Crappy code doesn't know about stringstreams or streams in
general even when they are already used in the same function
std::cout << "Ready to send data.";
sprintf("It contains %d items", dataToSend.Count());
// Crappy code loves using its own types unecessarilly
unsigned myVar = 0;
INT32_TXTP myOtherVar = 12;
myOtherVar = myVar;
delete resource;
}
// Crappy code is probably full of other errors, but is an example of
the crappy code that occurs when C-style is mixed with OO.
// It probably has syntax errors too, but who cares? It is crappy
code.
-----------------------------------------------------
Modern thinking has is that free functions can /increase/
modularity and encapsulation compared to member functions.
That seems far from your way of thinking.
Whose modern thinking?
Then you will never be able to achieve some sophisticated goals.
See for example Boost which has some macros. And you might also
bend over backwards and jump through hoops to avoid them even if
they happen to be the right tool for the job. That's certainly
not what I would call a professional attitude.
I'll live.
That's why it was a parenthetical remark as there are many vendors
of OO-Kool-Aid. Java just happens to be a common one. Whatever the
source, it seems clear you are drinking OO and anti-"C-Style" Kool-
Aid from somewhere.
If I wanted to be a C programmer, I would have spent a decade learning
C instead of C++. I'd probably have also gotten a job doing device
drivers instead of middle-tier services. I never liked kool-aid. Much
of what I drink has come from being on this newsgroup for many many
years.
Sure, rolling your own "virtual functions" in "C-Style" (as used
to be done) would not make sense in C++, most of the time. But you
haven't touched on any such topics. So far there have just been
vague asperions cast on free functions, pointers, macros, global
variables, etc (ie all the usual suspects for OO zealots) with no
substance and all of which are legitimate /C++/ tools.
Such topics aren't the topic, so why touch them?
You even began this thread with an attitude of "I'm right and
need some Kool-Aid arguments to 'convince' this [stupid] 'C-Guy'
how wrong he is." Turns out you were the one who was wrong ...
I think that signals a need for introspection, don't you?
I belive I started this topic with "I believe I am right. How do I
convince this other guy I am right? Is there support for my argument?
Is my argument incorrect?" Pay attention to the last question there
and try roleplaying again.
The goal is to hypothesize about and understand better the origin
(in this case you a person) of these rants. Since the rants are so
vague and unclear, full fallacies such as "C-Style" etc, it is
necessary to fill in the blanks and/or speculate a bit.
You'd probably have a better chance accomplishing your goal in a
thread about C-style programming vs OO programming. Your purpose does
not match mine any more than your preferences on programming style.
