Chris ( Val ) said:
> On Mar 19, 9:54 am, Richard Heathfield <r...@[EMAIL PROTECTED]
> wrote:
>> Chris ( Val ) said:
>>
>> > On Mar 13, 1:28 am, Richard Heathfield <r...@[EMAIL PROTECTED]
> wrote:
>> >> Chris ( Val ) said:
>>
>> >> <snip>
>>
>> >> > Do you think writing a library in 'C' is easier than using C++?
>>
>> >> Yes, absolutely. Much, much, much, much easier, with la****ngs of
>> >> cleaner, lightly saute'd pleasanter, and a tasteful side salad of
>> >> simpler.
>>
>> > I disagree,
>>
>> Fair enough - that's your right...
>>
>> > and you don't really believe it yourself :)
>>
>> ...but you don't get to decide what I believe.
>
> Well, if you can find it advantageous to save one line of
> code with your "setti_getti_two_in_one_you_beaut_function",
Sarcasm aside, I do consider it a (very, very, very) small advantage to
save one line of code. Saving more lines of code is a bigger advantage.
Saving lots of lines of code is a big advantage. That's why we write
libraries in the first place.
> then I think I can say with a certain degree of confidence
> that you do not believe it yourself.
Then you have no problem saying (with a certain degree of confidence)
things that are not true?
> Sorry, but that's the perception you created for yourself.
Well, it's your perception, not mine.
>
>> > Earlier you were talking up how your function was convenient
>> > because it saved one line of typing,
>>
>> Well, I mentioned it. I don't think I was "talking it up", as in hyping
>> it. It's hardly a big deal, after all. I was astounded to find you
>> talking it down, however.
>
> I never said hyping it up, otherwise I would have used *those* words
> explicitly.
I agree that you did not say "hyping it up", but you did say "talking up",
which amounts to the same thing - at least, that's the perception you
created for yourself. :-)
> However, mentioning it as some kind of advantage or
> benefit can certainly be considered talking it up, given
> the context in which we were discussing it.
Then we have different interpretations of the phrase "talking it up", in
which case I suggest we either agree on a definition (which seems
pointless given the trivial context) or use a different term.
>> > and here you advocate creating a library.
>>
>> That's rather a non sequitur, isn't it? Anyway, what's wrong with
>> advocating the creation of libraries? Do you advocate *not* creating
>> libraries? Would you rather rewrite the same code over and over again?
>
> I have no problem with creating libraries at all, and never stated
> that to be the case.
Delighted to hear it. It's just that your "and here you advocate creating
a
library" sounded disapproving. If that wasn't what you meant, that's good.
> The only point I was asserting to, was that
> creating a library involves more work.
Not in the long run.
>> > Also, please do not snip out too much context,
>>
>> I didn't.
>>
>> > because the OP clearly states...
>>
>> I wasn't addressing what the OP stated. I was addressing *your*
>> question, not his.
>
> Well, my question was to him, given the level of his experience.
Understandable. Nevertheless, threads *do* drift in interesting directions
on occasion (which is probably a large part of the reason that so many of
us keep reading Usenet in the first place).
<snip>
>> But since you mention the OP's lack of experience, yes, I'd still say
>> that if they want to get the job done quickly, C is the way to go.
>
> Well, that's nice, but this is a "C++" thread, at least that's
> what it started out as.
True enough, but it was in fact the OP (albeit not in the root article)
who
said: "I've found that what we want to do could have been done in a much
simpler way and could have been done in C instead", to which you replied
"Do you think writing a library in 'C' is easier than using C++?" - so I
don't think I yanked the discussion too far out of true.
> C++ is also the way to go - Why do you think it isn't?
I think it's *a* way to go - and not necessarily the best.
>> Of course,
>> if they have the necessary time available to learn the whole OOP
>> religion, that's up to them.
>>
>> >> > Btw, C++ is a multi paradigm language and not OOP specific.
>>
>> >> And yet, when people post code that is not in line with your
>> >> perception of OOP best practice, you criticise it on that basis.
>> >> Seriously, Chris, you might want to think about this inconsistency.
>
> Seriously Richard, you might want to reconsider your assertions,
> because it is not *my* perception, it is what I learnt at UNI as
> well as on the job experience, and via books.
Having taught CS graduate trainees how to program (because they forgot to
learn how on their CS course), and having taught people with far more
experience than me that char * actually has to point somewhere before you
write through it, and having read a whole barrel-load of complete junk in
books, I am not overly convinced that you have demonstrated the validity
of your learning.
Now please *don't* misunderstand me - it is clear that we're not seeing
eye
to eye in this thread, so I want to make it quite clear that I do actually
respect your knowledge and experience.
But either you think that what you learned at UNI, on the job, and from
books has formed (or at least influenced) your perceptions about OOP, or
you don't. If you don't, then why raise the matter at all? And if you do,
then it *is* your perception, or at least a significant part thereof.
> Have you never heard of any of the principles I speak of in your vast
> experience? You know, cohesion, loose coupling, encapsualtion, design
> patterns, etc... I could go on and on.
Yes. That doesn't mean I follow them slavishly, though. I view them as a
guide, not a prison.
> I'd be astounded if you have never heard of these programming
> practices and *accepted best practices* idioms before, but the
> way you are presenting your arguments here indicates otherwise.
Accepted by whom? You?
>
>> > Richard, you are completely wrong, and there *is no inconsistency*
>> > with my answers.
>>
>> So you claim that C++ is not OOP specific,
>
> It's not my claim, it's a *fact*.
Fine - it's not OOP specific, IN WHICH CASE there's no reason why we can't
write non-OOP code in C++, and no reason to assume that people writing in
C++ necessarily wish to write OOP code.
>> *and* you criticise C++ code
>> posted here that does not accord with your OOP dogma, despite the fact
>> that no claim about OOPness was made for that code.
>
> You don't seem to like *constructive* criticism, which is
> all I offered.
I'm okay with constructive criticism. I'm just pointing out that there are
other ways to look at the world than OOP.
>
>> If C++ is not OOP
>> specific, it ought to be possible to post C++ code here that is not OOP
>> specific.
>
> ...and it certainly is possible, no doubt about that.
Right.
>
>> Complaining about it because it doesn't follow your OOP rules
>
> Again Richard, not *my* rules - I merely state what I have read
> and learnt over a good number of years. Maybe you should spend
> a few years programming in C++ before criticising the points I
> have presented.
I have spent more time programming in C++ than I would have liked. I'm not
criticising the points you have presented, but the assumptions inherent in
them. That is, your points are presented from the perspective of a
particular OOP-based stance. But nobody is required to adopt that same
stance, and there are very good reasons why they might choose otherwise.
>> suggests to me that you think C++ *should* be OOP specific. I don't see
>> how you reconcile these two diametrically opposed positions.
>
> Oh boy, I never stated that at all - It seems no matter how often
> I stress the point, you continually appear to claim that all these
> ideas are mine :-)
I'm making deductions based on what you say. For the record, then, would
you agree that there is NO REQUIREMENT on C++ programmers to adopt OOP
conventions such as the ones you accused my elsethread code of breaching?
>> > You have a serious problem if no one can ever
>> > question the code you write - You aren't always right you know!
>>
>> True enough. Of course people can question the code I write. That
>> doesn't mean I have to accept their criticisms. If I'm wrong, fine, I'm
>> wrong, but just *saying* I'm wrong doesn't make it so.
>
> I've tried to present to you, the reasons as to why I think your
> wrong[1], but you dismiss them completely.
I accept that you have adopted a certain set of design principles. I do
not
accept that everyone else is required to adopt them too.
<snip>
> But you did introduce a weaknesses in the code,
No, I did not.
> which maybe not be directly
> exploited by an attacker, but via other means such as bad programming,
> in turn allowing such an attacker to run wild.
>
> A function is supposed to do one thing (not two), and do that one
> thing well.
Consider printf, which writes some stuff to the standard output device
*and* yields the number of characters printed. Consider strcpy, which
copies a string from one place to another *and* yields a pointer to the
destination string. Consider modf, which writes the integer value of a
double into an object whose address is supplied for the purpose, *and*
yields the fractional part. Consider clearerr, which clears the end of
file indicator *and* the error indicator in the stream object to which a
pointer is supplied. Consider ldiv, which computes the quotient *and*
remainder of a division. And so on and so on.
You are overstating the principle you espouse - i.e. functional cohesion.
That principle is supposed to steer you away from writing functions like
CalculateAndPrintResults, ShutdownReactorAndOpenTheDoor, or
LookUpPhoneNumberAndMakeTheCoffee.
> Your function broke that principle, and the fact is that you cannot
> admit it, simple as that.
You seem to be trying hard to turn this into a personality thing, but it
isn't really. I'm actually very good at admitting when I'm wrong. I don't
think I'm wrong on this occasion, though.
>> <snip>
>>
>> >> It's not our job to pick people's paradiggums or languages for them.
>>
>> > Wrong!
>>
>> Here I must strongly disagree. You don't get to decide other people's
>> approach to programming, any more than I do.
>
> Clarification: I meant that your assertion above was wrong, in a sense
> that:
> "I have not, in any way tried to pick people's paradigm or languages
> for them"
Delighted to hear it.
<snip>
>> Using a class doesn't mean you're using OOP.
>
> In C++, a class can represent a real world object, such that it
> has a state and the data and properties travel with it.
Yes, it can. It doesn't have to, obviously.
> Since
> a class has private accessors (allowing for encapsulation), then
> I can state with a reasonable level of confidence that a program
> that incor****ates a class in C++ is using the OOP paradigm in
> some form.
Then I suggest you take it up with Alan Kay. :-)
>
>> > and writing an OOP,
>>
>> By no means necessarily true.
>
> AFAIU, everything in C++ is an object.
In C++, as in C, an object is merely a region of storage (see ISO/IEC
14882:1998 Section 1.8 if you don't believe me).
>> > and chances are that more often than not, then answers
>> > provided will involve the discussion of OOD.
>>
>> Fine by me, but saying that a non-OOD/OOP-oriented(!) reply is *wrong*
>> simply because it breaches some apparently arbitrary OOD/OOP rule is
>> just completely wrong-headed. It's like criticising a glider for not
>> having an engine.
>
> I am not saying that at all, yet you keep stating it!
*Now* I'm confused. If you're not saying that, what *are* you saying? My
understanding was that you strongly disapproved of my int setx(int x_) {
int t = x; x = x_; return t; } function, for reasons that are apparently
based entirely on OOP dogma.
> You seem to have a real problem understanding the text that I post.
It would appear so, yes.
> For your benefit, I will in future, take the time to write my replies
> in laymans terms.
That is very kind of you.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www.
+rjh@[EMAIL PROTECTED]
users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
|
