![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> I understand that "bashing" can also be used to describe overly negative
> critique of something in a way that, while not telling any lies per se,
> makes it sound a lot worse than it really is.
Fair enough. I thought we'd already talked to death the advantages of unsafe
languages (primarily performance and control).
> Especially if the impact of
> many of these negative things is exaggerated,
I think you underestimate how much of a problem some problems are for
average programmers because you've become expert. I still occasionally get
questions from people who have been programming for decades who ask
"How do I debug something when it stops crashing after I add a printf()?"
You yourself have posted C++ code with a quiz-like "what's wrong with this
class". Clearly it takes a fair amount of expertise to write correct C++
code, doesn't it?
I can write C code that doesn't have bugs due to the unsafeness, but it
takes me much longer because I have to think a lot harder about the
boundaries. It's also something that took years of experience to learn.
I also figured it wouldn't be taken to be "bashing C++" if I pointed out the
equivalent flaws in the whole list of other languages we were talking about,
which is what led me to believe you might be a bit oversensitive or
oversensitized.
> For example, in my "I hate Java" page I'm outright bashing Java because
> I'm pointing everything that I consider negative about it, without pointing
> out anything positive to compensate (although Java does have its positive
> things as well). Someone who didn't know anything about Java could get a
> rather biased impression of the language by reading that page alone. (Guess
> twice if I care. ;) )
There's nothing wrong IMO with a good bash so labeled. I don't think
anyone's going to read a page labeled "I hate Java" and expect a balanced
presentation, any more than they're going to go to apple.com to see the pros
vs cons of apples vs windows, say. I even think something like the C++ FQA
is a valuable service, bashing as it is. I wish there were pages like that
for every language and tool.
I don't think it's a bash of any one language to say "no language strictly
enforces modularity, they're all broken in various ways, and here they are:
...." I'm hoping it's not considered bashing Y to say "I like X better than
Y because ..." It's not like I started talking about the flaws I think are
in the design of C++ that haven't anything to do with violating modularity,
or that I argued you can't violate modularity in the other languages.
--
Darren New, San Diego CA, USA (PST)
My fortune cookie said, "You will soon be
unable to read this, even at arm's length."
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> With this I mean that with the memcpy() you are not accessing the private
> members any more than you are with "a = b;".
I would disagree for the following reason:
Altho {a = b;} *might* do the same thing as memcpy(), the author of the
class has the ability to make it do something different, or to declare
operator= to be private, preventing it altogether.
memcpy() can not be "defended against" in that sense.
"Can I change the values of private variables without invoking a class
method or friend function?" "Yes." I'd say that's breaking modularity.
I think at this point we each understand what the other is saying, and now
we're just having an argument about whether to call it "really" unmodular or
only "kinda" unmodular. :-)
> They are both copying the
> state of the entire object to another instance. You could say that with
> memcpy() you still don't know *what* you are copying (what type of members,
> how they are padded inside the class, etc), only that you are copying
> everything verbatim.
Note, too, that even in this case, if you change your pixel example to be
HSV instead of RGB, the memcpy() approach still works for moving pixels
around. :-)
> The difference, and what makes the memcpy() version non-modular, is that
> the memcpy() version bypasses the normal class assignment semantics and
> instead goes to the "raw hardware level". If the class would need a more
> complex copying semantics than a bit-by-bit copy, then the copy is broken.
Sure. I'm just arguing that the ability to use memcpy() *is* non-modular.
The fact that it breaks or is non-portable in some cases would not seem to
counter that fact. It would just seem to say "it's a bad way of doing
things." :-) Which we both agree with.
> I understand your argument to be that memcpy() could be used in this
> way to *access* the private members of the object. However, it can't,
> not in a portable way anyways, because you still can't know the internal
> structure the compiler has generated for the class, and you can't point
> to individual private elements.
Agreed. Not that it's difficult to figure out. I can think of at least 3
easy ways to figure out where individual variables are: 1) use a debugger,
2) look at the generated asm code, 3) stick a friend function into the
header that returns the offset of the private instance. None of those are
particularly portable, except the last, assuming that adding a friend
function declaration doesn't rearrange the actual structure members.
I agree it's a concern in CLOS that someone will read your source code and
access the internals of your class by learning the names of private
variables and then you'll have to support it. I also contend it's about the
same level of concern that someone will look at your header file, see it's
POD, and write code that uses memcpy() to move POD-structs around (perhaps
to different address spaces or into files or something), and you'll wind up
having to support that. Neither is really common enough to worry about, and
both are trivial to avoid if you can change the module you're talking about
or avoid the need to do that altogether in the caller.
> Perhaps this could be compared to calling the CopyFile() function of
> the Windows API: Even though it copies the entire contents of a file to
> another file, I'm still not *accessing* the contents of the file with
> that function in my program. I'm just telling the system to copy it.
Sure. And my comparison would be that "Anything you can call CopyFile() on,
you can open and read and write, possibly messing up the program that uses
the file, or possibly for the purpose of bypassing DRM."
--
Darren New, San Diego CA, USA (PST)
My fortune cookie said, "You will soon be
unable to read this, even at arm's length."
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> I understand that "bashing" can also be used to describe overly negative
> critique of something
Or, to just phrase it a different way, I've been actively and consciously
attempting not to say bad things about C++ and to ensure whenever I point
out a limitation I also point out the equivalent limitation in other
languages. Yet you continue to fall back on "you're bashing C++ to annoy
me", which is kind of discouraging.
--
Darren New, San Diego CA, USA (PST)
My fortune cookie said, "You will soon be
unable to read this, even at arm's length."
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New wrote:
> I agree it's a concern in CLOS that someone will read your source code
Or, to phrase it a bit differently, I'll agree that using memset() or
memcpy() to get to the entire instance opaquely *feels* qualitatively
different than the sorts of access CLOS or Python allows.
On the other hand, it seems kind of similar to the sorts of things
reflection allows.
Even in Python, I think there's two kinds of accesses:
x = myinstance._myprivatevar
vs
"iterate over all public and private variables of this instance
and do XYZ with them."
They feel qualitatively different, with the latter feeling more like
reflection and the former feeling more like bad news, even though they
both stem from precisely the same language rules.
As an example you might be able to relate to, to see what I'm talking about,
consider http://www.boost.org/doc/libs/1_38_0/libs/serialization/doc/index.html
Look at the "class gps_position" example. It has a pair of routines named
"serialize" each of which lists the exact same variables in the routine as
are in the class. With a reflection library, adding this sort of
serialization would be done by having a mix-in multi-inheritance routine,
and you wouldn't need to code that sort of body at all. Of course, there
would likely be routines like "serialize everything" and "serialize all
public members", as well as routines like "serialize everything but X and Y,
and when you load back in from the archive, invoke fix_up() on the loaded
instance to fix X and Y." So lots of uses of this sort of thing are done
from within the class, just taking advantage of the fact that you *already*
listed the names and types of the instance variables, so why do it again?
Yeah, you can use it to get to the insides of classes from outsides, but you
kind of want that for your IDE and your debugger. :-) It's a lot of power,
and IME not a whole lot of misuse.
--
Darren New, San Diego CA, USA (PST)
My fortune cookie said, "You will soon be
unable to read this, even at arm's length."
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> Or, to just phrase it a different way, I've been actively and consciously
> attempting not to say bad things about C++ and to ensure whenever I point
> out a limitation I also point out the equivalent limitation in other
> languages. Yet you continue to fall back on "you're bashing C++ to annoy
> me", which is kind of discouraging.
I'll try to be less paranoid next time.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> I'll try to be less paranoid next time.
Thank you. I appreciate it. In return, feel free to say something early on
if it sounds like I'm not making the effort. :-)
--
Darren New, San Diego CA, USA (PST)
My fortune cookie said, "You will soon be
unable to read this, even at arm's length."
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> Warp wrote:
> > I'll try to be less paranoid next time.
>
> Thank you. I appreciate it. In return, feel free to say something early on
> if it sounds like I'm not making the effort. :-)
whoa! A lot of kicks, punches and bruises later and you almost feel in love...
:P
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
nemesis wrote:
> whoa! A lot of kicks, punches and bruises later and you almost feel in love...
I'm not offended by anything Warp has said. He's a smart and insightful guy
with lots of knowledge. I learn enough from him I want to stay on his good
side. Occasionally his conversations style is annoying, but I'm pretty sure
mine is moreso. :-)
--
Darren New, San Diego CA, USA (PST)
My fortune cookie said, "You will soon be
unable to read this, even at arm's length."
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New wrote:
> http://vijaymathew.wordpress.com/2009/03/13/dangerous-designs/
Why write
(define (addn n) (lambda (k) (+ n k)))
when you can just say
addn n = (+n)
? ;-)
Seriously though, adding completely new features to a system not
designed to support them is not an easy thing to do. This is not news. I
do, however, agree that a simple design that is widely powerful is
better than a huge raft of special-purpose rules for specific situations.
(This is one of the reasons why Haskell's ever-expanding set of features
worries me. If people need all these extra features, doesn't that kind
of indicate that the language is broken?)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> "The argument is that, using a very small number of rules for forming
> expressions and with a minimal syntax it is possible to support all
> possible programming paradigms. For instance, if the language has
> support for higher-order functions, closures and dynamic typing, we
> can implement object oriented programming without special language
> level syntactic support. Tail-call optimization elude the need for
> special looping constructs."
>
> sounds like you could argue in favor of languages like brainfuck which
> have a minimal set of instructions, yet are still Turing-complete.
>
> Eg. just because tail recursion is enough to perform any kind of
> looping construct doesn't necessarily mean that special looping constructs
> wouldn't be a useful tool.
If a language is "powerful enough", you can create the abstractions you
need from within the language and use that. If the language is not
powerful enough, the things you need must be hard-coded into the
language, which is less flexible.
On the other hand, a compiler can take advantage of the specific
features of a specific language, but can't easily take advantage of the
properties of some custom abstraction that you designed yourself.
(Although some languages allow the programmer to specify compile-time
transformations that go some of the way.)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |