N
Nick Keighley
good grief. *Thats* Pascal! Looks more like CORAL-66
good grief. *Thats* Pascal! Looks more like CORAL-66
J
John Bode
Isn't is a lame use of human time and effort to have, what,
eleventy million different programming languages in the first place?
Why stop with C and C++? Why not roll in Java and C# and Objective-C?
C and C++ are different languages with a large common subset.
Why is that a problem?
M
Malcolm McLean
בת×ריך ×™×•× ×©×‘×ª,1 בספטמבר 2012 18:35:09 UTC+1, מ×ת John Bode:
Yes, we badly need one programming language that does everything. Twenty different ways of writing a for loop is unacceptable.
K
Kaz Kylheku
Maintaining these standards is just the hobby of some people who have
been put out to pasture.
Who cares if they are wasting /their/ time; the problem is that, while they
may improve a little thing here and there, they are wrecking the languages
(because some fools in the world actually take them seriously).
I do not use any syntax or function* newer than the 1995 C technical corrigendum
(which added some badly needed wchar_t related functionality to the nearly
perfect C90 language).
In C++ programming, I stick to 1998 C++, which mostly got it right.
Just say no to these clowns.
Language standardization should be about one thing and one thing only:
surveying the existing practice (what is implemented), identifying what is
common and codifying it (perhaps with some small adjustments to bring
nearly equivalent features together).
The situation where you have a new standard, most of which is not implemented
anywhere, is completely ridiculous and wrong.
N
Nobody
Also: alignment. An implementation can impose a minimum alignment for
structures (even incomplete structures). The representation of MyVoid*
only has to allow for such alignment, meaning that (unlike void*) it may
not be possible to reliably convert a char* to a MyVoid* then back to a
char* (on a word-aligned architecture, a MyVoid* only needs enough bits
for the word address, whearas a void* must have enough bits for the offset
within a word if char is smaller than a word).
A
Anse
John said:
Well, yes, of course. But C/C++ers are like addicts and need much more
transition time and some will just never make it without their vice. So
then, a common ground for C/C++ is like step 1 of the 12-step-method for
them.
Shhhh. That is not the plan.
Many are trying that, but just like hope that a president or government can
rescue humanity is, of course, ludacrous. (BTW, after the republicans'
convention, it sure does look like Obama is a shoe-in for another 4 years,
huh.)
It's not common ENOUGH. Mostly, the C++ programmers will have to help the C
programmers adapt to a future that some of them will still see, lest they
become the next wave of homeless when the <you know whos> kick them to the
curb. Making C/C++ more like one thing is like throwing a lifesaver to the
drowning C programmers.
A
Anse
Malcolm said:
"Put your money where your mouth is!". IOW, talk is cheap. Are you asking
for something, or suggesting you know what to do?
A
Anse
Kaz said:
Which is all fine and dandy, until it negatively affects others. Like, e.g.,
the newbs who the olds are keen to impress on. IOW, smoking yourself to
death is totally up to you. Start pushing your bad habits on others, then
it's a problem.
I actually do if that is not the situation they really want to be in.
That's kinda what I said above.
The only way to use C/C++ with an eye toward the future is with a healthy
dose of macros, and the built-in preprocessors are pretty much not up to the
task. Perhaps they are crippled on purpose.
Most are actually pretty darned smart. But when they start on their "spiel",
I give it right back to them and then some, but they do not seem to be
learning from it. I think they see everything as a pissing contest. Have you
ever seen a C or C++ programmer admit that they were wrong or that someone
else actually has a good point? They see everything as a threat. I guess
that is what a focus on sports in schools and fraterneties result in. Sigh.
I think this is why much of the world sees "Americans" as stupid. Which, of
course, begs the question, "Is USA's largest export, stupidity?".
See, now I've heard that over the years, many times. I still don't think it
is true. But I'm not sure it should be that either, but maybe. If someone
starts a new thread on this, I promise to read all posts in it. You have a
fine example in progress on this: Jacob Navia and his "CCL": he is scheduled
to pitch it next month (wow, last month already, I thought it was THIS
month, but it is actually NEXT month!) but the "it" he is going to pitch is
NOT "standard practice", but rather some kind of "request to develop or
solicit proposals" or something, which goes entirely against the "codify
existing practice" mantra. Can you make heads or tails out of this?
I've suggested that maybe the ISO standard process for C/C++ is broken, but
it's probably more than that: byzantine failure.
A
Anse
Leigh said:
WTF? Just because "you can't handle the truth!", I'm fired and some
unqualified fool is to replace me?! Is this a trick? I'm NOT going to beg to
keep "my job", nor will I take a pay cut. (I'm gonna cost you twice as much
as a consultant, you know... umm, nevermind! HIRE the FOOL!
).
D
Dombo
Op 28-Aug-12 23:12, Melzzzzz schreef:
It *may* greatly reduce code size, if the compiler doesn't do this
optimization (sharing implementation of pointer templates) already for you.
It *may* greatly reduce code size, if the compiler doesn't do this
optimization (sharing implementation of pointer templates) already for you.
D
Dombo
Op 31-Aug-12 0:18, Jens Gustedt schreef:
I've been programming C++ for almost 20 years now, I don't remember
having ever having a need to use void* other than to interface with C
code (typically when registering a callback on a C API, where context
information can be passed back to the callback function via a void*).
I've been programming C++ for almost 20 years now, I don't remember
having ever having a need to use void* other than to interface with C
code (typically when registering a callback on a C API, where context
information can be passed back to the callback function via a void*).
K
Kaz Kylheku
Yes, and to prove it I'm starting an insoluble ISO committee dedicated
to buggering Up a perfectly good programming language.
I won't go so far as to quote an entire article just to add one line,
though.
J
John Bode
Any programmer who is unable or unwilling to learn and adapt to the incompatibilities between C and C++ (which will only diverge further over time) needs to get the hell out of software and find a new line of work, full stop.If I can manage it, it ain't that goddamned hard to do.
Yes, it would be nice if every legal C program was also a legal C++ programwith identical semantics. That ain't happening. Ever. Quit whining and deal with it or find another line of work.
J
John Bode
FYGG.
Let's try that again.
Let's try that again.
Ö
Öö Tiib
Not at all. Every raw pointer converts implicitly to void*. If you
need "a pointer" regardless of type at what it points then "void*"
is the thing to use. It is safer than some "unsigned char*". You
can not by some typo to do arithmetics or to dereference void*.
Download the flagship template libraries collection called "boost". I
bet you find hundreds of explicit usages of "void*" there if not
thousands.
That is also one reason why it may be is needed, but far not the main one.
You can cast void* back into T* what it was with dynamic_cast<>() in
C++. dynamic_cast<>() does check runtime that the cast is correct.
It is very safe.
reinterpret_cast said:
I repeat. Just take boost. It is all good, well tested C++, mostly
header-only libraries. Open source. Free to eyeball and to use. Lot
of things from it went straight or with minor mods into C++2011.
Then come back and tell us how you reimplement that thing in
C or assembler.
Ö
Öö Tiib
void* is the pointer to most abstract base class in C++. The base class
that is common to all classes and fundamental types.
There are very different levels of usage of C++. When I use some
C++ framework like for example QT and only need the things that the
framework already provides then I will have next to no need for void*.
The typical uses in communication, serialization, containers,
encryption, compression, threads and signals are all provided by the
framework and the internal void* usage is hidden with templates
or code generators. When something so abstract and mundane is
missing and I need to implement it for generic case then the need
for void* is there, nothing to replace it with.
J
James Kuyper
In C++, if you need "a pointer regardless of type", you can template on
T and use T*, for increased type safety on top of the same amount of
flexibility that void* gives you. As an additional bonus, you can do
(meaningful!) arithmetic on T* and even dereference it, which you can't
do with void*.
....
Yes, it is safe, but dynamic_cast<T>(v) has a number of limitations: "T
shall be a pointer or reference to a complete class type, or “pointer to
cv void.â€"(5.2.7p1), so it cannot be used to convert to, for instance,
double* or an opaque class type.
Also, "If T is a pointer type, v shall be an rvalue of a pointer to
complete class type ... If T is an lvalue reference type, v shall be an
lvalue of a complete class type ... If T is an rvalue reference type, v
shall be an expression having a complete class type ..." (5.2.7p2).
Notice that v cannot have type void*, because void is neither complete,
nor a class type.
He's not suggesting that the entire thing be implemented in C, only that
any place in the code which has a good reason for using void* could be
split into two parts: a part in C++ that makes no use of void*, and a
part that could be implemented entirely in C. His words also imply that
there might also be place where void* is used without there being a
"good C++ use case", in which case the code can probably be replaced,
not by C code, but by C++ code using T*, where T is a template type
parameter.
I don't know enough about boost internals to guess whether that would be
true, but it at least seems plausible to me.
Ö
Öö Tiib
In C++ a flexibility that is not needed is considered a bad thing. The
void* is anonymous. So when a part of software has not business to
know the nature or to dereference it then making it available is
wrong.
As similar example think of std::array<>. All it does compared to
usual array is that it removes implicit conversion to pointer and
wraps pointers into iterators. As result the code of usage compiles
into exactly same binary. Still it is lot safer because
dereferencing or doing arithmetics with it does not compile.
dynamic_cast<T>(v) has some runtime cost. So if you use pointers to
fundamental types in C++ then you likely are anyway seeking ways
to lower the cost that complete classes might have.
To void* one should cast implicitly. Explicit cast looks not good
like casting away constness and other such things.
The C++ itself can wrap and hide void* usage lot better than in
cooperation with C.
There certainly are lot of bad C++ code where void* or preprocessor
macros should be replaced with templates. void* is a tool like any
other. You can use it in harmful way. That is not the case with boost.
Boost is mostly header-only, the void* is mostly used privately.
With C it would drop being header only or the void* usage would
become public.
J
James Kuyper
....
In that paragraph, I'm talking about conversion from void*, not
conversion to void*. Implicit conversion from void* to a pointer to an
object type is allowed by C, but not by C++.
dynamic_cast<T>(v) shall not be used to cast away constness (5.2.7p1).
[Re: C++ restrictions on dynamic_cast said:
In that paragraph, I'm talking about conversion from void*, not
conversion to void*. Implicit conversion from void* to a pointer to an
object type is allowed by C, but not by C++.
dynamic_cast<T>(v) shall not be used to cast away constness (5.2.7p1).
Ö
Öö Tiib
Ok, my bad. You are correct. A proper C++ compiler just does not let me.
If it lets to dynamic cast from void* then it is some sort of extension again.