Re: C++ private/protected hack
On 12 Mai, 11:12, bji-gg...@ischo.com wrote:
On May 12, 3:03 pm, John Moeller <fishc...@gmail.com> wrote:
And in the context of C++, redefining keywords makes no sense either.
It seems to be a far-too-common hack, and its adoption should be
discouraged. If you don't like the access model, you shouldn't be
using C++.
But I disagree. There is a certain sense in saying "even though I
said when I defined this class that no one else should have access to
this data member ... well, I'm the programmer, and I say that here,
this code should really be given access too. Trust me, I know what I
am doing." I think that could be construed as a reasonable thing,
whereas trying to treat a floating point value as a class and call a
destructor method on it, when the concept of a floating point value
doesn't include anything *like* a destructor - now to me, that just
doesn't make sense. I think there is a difference between "stretching
the rules" in a way that makes some kind of sense (even if it has
flaws when certain aspects of the language are considered - and it is
these flaws that I am interested in discussing here), and something
completely nonsensical, as the example you gave.
I think that you overlook in your "trust me" reasoning the fact,
that it is not *your* code that decides to trust you, in fact your
approach seems to be: Everyone *and* everything *must* trust
me, otherwise don't use my library. This is a quite strong and
IMO an inacceptable demand. I absolutely don't understand
why it shouldn't be possible and reasonable, that your library
would require that every class of the client code needs simply
to declare friendship to a dedicated class (template) which is
part of your library. If you would do this, every user understands
what is going on in her code. And she could *decide* to remove
this friendship if she don't want that any longer. Your
requirements could be described as an "enforced friendship"
which is a bad design and in non-programming-related situation
usually a bad starting base for some form of relationship...
And - as an aside - there are many things about C++ that I don't
like. In fact it disheartens me to see the direction that the
language has taken; instead of becoming more simple and concise (ala
Java), the addition of complex template syntax, template meta-
programming, more comprehensive support for shoot-yourself-in-the-foot
constructs like multiple inheritence and "diamond" inheritence ...
these things I just don't agree with. When I look at some modern C++
code, and especially the trends present in widely accepted tools and
libraries (Boost), it makes me not want to program C++ any more.
This is a somewhat funny and contradictory point of view.
If you don't like selected feature of a language - simply
don't use them!
And if you really think that this language is too complex
for you, you should not use it. Please note that this is *not*
meant as an affront, I simply repeat your own description
without any form of degrading implication.
That being said, there is an aspect of C++ that I love - the comfort
of C-style syntax with all of the expressive power of object oriented
programming.
I try to write all of my C++ code within certain
boundaries of what the language allows; and conveniently, these
boundaries also allow all of the "hacks" I have defined to work. I am
just trying to understand what aspects of these boundaries I may not
realize or may not be thinking about which make this stuff not
actually work even within my happy little world of "rational subset of
C++" (as I like to think of the language I program in when I write C++
code).
It seems that your approach is, that everything, what a compiler
accepts, should be a feasible program invoking some form of
defined behaviour. This is not so. C++ and most of the classic
languages (C, Pascal, Fortran, etc) do have large parts of the
language which is *only* ruled by the written rules (if you are
lucky, and this language is standardized or at least well
documented), so the corresponding compiler/executor (or
whichever name the tool has, which transforms your textual
program into a "binary") accepts a lot of program constructs
which are publicly announced as not to be allowed (aka
"cause UB"). If you prefer a language which should be
constructed in a way that allows everything what the
compiler (or its equivalent) allows, than use this one. I
don't know whether there exists one which does give you
a 100% guarantee (James Kanze sometimes ago mentioned
that threading issues are practically impossible to define in
that way and I guess that there exist some forms of resource
limitations on the execution system, which cannot be controlled
by the compiler), but several come at least near to that.
After this, you might find out that
- these languages often have even stricter limitations than
C++, which makes you sugg.
- you will also make programmer errors and you will
curse the compiler/language for allowing that "obviousity".
Not long ago, Francis Glassborow used the picture of
jaywalking, which I really liked (I forgot the actual thread).
My own more far-reaching use of this example is:
You could demand that any form of jaywalking immediatly
causes the jaywalker to be transferred to jail (or maybe to
the execution of the person? - There was an episode of
"Next generation" which had a similar theme) or you simply
trust common sense.
It was a long time ago, in college, when a friend and I discussed C++
and we agreed that it was a language that gives you more than enough
rope to hang yourself. It seems like over the years the rope has
gotten longer and longer - so long in fact, that it's hard not to trip
and fall into a noose even with the greatest of care. It doesn't help
that everyone else's libraries, tools, and methodologies for C++ seem
to be getting better and better at making really hard-to-see and ever-
more-pervasive nooses :)
Taking this position you also forbid car-driving, street-walking
and similar stuff, because any inproper form of doing that can
lead to harm or possible early death.
Well I thought the whole thing was kind of funny really. What I meant
in all seriousness is, the concensus on the kinds of hacks I am trying
are that they are well outside the realm of "legal" C++. Even though
I recognize this, I am not going to patently reject these hacks as
worthless if they end up solving my problem in a way that works with
all compilers I ever encounter. Sure, there's the chance that some
compiler can compeltely hose me - but if it's harder to hose me than
to not hose me, this leaves me with confidence that no one will ever
really bother.
You often describe that the language seems not to
allow some forms of programming you would like/need
to do. Please consider that the C++ standard (and most
other programming language standards) do this arbitrarily.
Actually there are real reasons behind these rules and
it needs more than a handwaving argument to throw them
away. It might be possible that some of those restrictions
are no more valid today. If you can reason about that,
you can (and should!) write a corresponding defect report!
But it wouldn't modify the behavior of your code, as far as I know; it
uses read-only access to your class definitions and instances. It
just tries to compile code which can describe your classes, without
resorting to inheritence or friend or macro tricks. It does leave
your code alone. It doesn't *touch* your original header files, or
ask you to; it just generates an innocuous C++ source file which uses
lots of hacks to try to give you some functionality that you will find
useful.
I don't consider these as "tricks". I assume that it is possible
to demand an astonishingly little efford on the user-side to
realize that. You already expressed that you don't like boost,
but IMO you should study e.g. its serialization library. It has
astonishingly little requirementson user-code to perform the task.
Despite my assertions that I want to use
these hacks, please understand that I only want to do so because I can
see no other way to implement the tool with the properties that I want
it to have. If and when a means can be discovered to use language-
conforming methods to do these things, I will gladly throw away my
hacks and not shed even the smallest tear.
This is a good intention. But please reconsider your
actual use-case and what *really* is needed to realize
it. You might find out that you can do hack after hack
and finally must throw in the towel - or that you need
to write your own C++ compiler or another language
to realize it.
Although I have critized you a lot in this answer, I
would like to express that I praise the tone you
choose and this open - but friendly - discussion on
that problem.
Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]