"Death to C, ++"

[Lynn McGuire]

"Death to C, ++"
https://techcrunch.com/2017/07/16/death-to-c/

"The C programming language is terrible. I mean, magnificent, too. Much
of the world in which we live was built atop C. It is foundational to
almost all computer programming, both historically and practically;
there’s a reason that the curriculum for Xavier Niel’s revolutionary
“42” schools begins with students learning how to rewrite standard C
library functions from scratch. But C is no longer suitable for this
world which C has built."

I disagree. True, working in C and C++ is like walking on a tight rope.
But, if one cannot walk the tightrope then one should find something
else to do in life. After all, working on the high wire is not for
everyone.

Lynn

[Rick C. Hodgin]

On Tuesday, July 18, 2017 at 1:34:48 PM UTC-4, Lynn McGuire wrote:
> "Death to C, ++"
> https://techcrunch.com/2017/07/16/death-to-c/
>

> I disagree. True, working in C and C++ is like walking on a tight rope.
> But, if one cannot walk the tightrope then one should find something
> else to do in life. After all, working on the high wire is not for
> everyone.

I agree with you completely, Lynn. Certain people are tailored for
certain tasks, but not everyone is tailored for every task. In my
experience you can't really teach someone to be a developer. They
either are or they aren't innately. The only thing you can do is
teach people policies and procedures to follow, whereas with the
innate developer, they will understand things implicitly, and be
able to build and expand upon ideas they're exposed to, making the
final form of their contribution something greater than the parts
it's comprised of.

C is not for the weak, but it is essential, and it is exactly for
those who are able to wield it.

Thank you,
Rick C. Hodgin

[Melzzzzz]

If you’re a developer you already know where I’m going, of course: to
tout the virtues of Rust, which is, in fact, a viable C/C++ replacement.
"
Rust is pain. That language is worst nightmare I had misfortune to program in.
Inability to implement doubly linked list and take two mutable references to
single array is just one example. Rust is abomination of language, pure
and simple.


--
press any key to continue or any other to quit...

[Öö Tiib]

Yes, strange language that did born after D and Go (that both are IMHO
more pleasant). Rust is I think for people who don't want to program but
to solve a puzzle that does not let them to program. How it is better
than C++? No idea.

[Öö Tiib]

The decades with C have caused lot of great code checking, testing
and debugging tools to raise that make even C quite safe to use.
It feels just bit inconvenient language (and not like on high wire).

C++ additionally contains such convenience subset with what the
feeling is like running in park. Memory corruptions with buffer
overflows or dangling pointers are not possible when using that
subset. But C++ is large and so it takes years to learn the borders
with it and rest of the "technically valid" C++ language.

Rust however has replaced that with a painful ball and chain that
don't let one to run nor to get to high wire. If someone likes
that pain then there are still bad news. Rust's inter-operation with
C++ (if programmer for example wants to refactor legacy C++ into
Rust step by step) is stinky. Rest of the competition that are
supposedly made with similar goals (like D, Go and Swift)
interop with C++ way better.

So unless the C community decides to switch to Rust for unknown
reason I don't think it will live very long.

[jacobnavia]

Le 18/07/2017 à 19:40, Melzzzzz a écrit :
> Rust is pain. That language is worst nightmare I had misfortune to program in.
> Inability to implement doubly linked list

You can see an implementation of a double linked list here:

http://bluss.github.io/ixlist/target/doc/ixlist/struct.List.html

A double linked list has 2 indices into an array of elements.

A correct implementation would allow you to grow the array as you index
it, an index bigger than 1 of the last elements implies an extension of
the array, using memory as the list grows.

What is a pointer?

It is an index into an array of addressable bits, consecutively. Modern
CPUs offer virtual memory, where the OS gives you a huge adressable
space. Underlying the virtual memory is the real memory, that could have
some GB in most machines.

[jacobnavia]

Le 18/07/2017 à 20:58, Öö Tiib a écrit :
> Rust is I think for people who don't want to program but
> to solve a puzzle that does not let them to program.

Parse error...

I can't figure out that sentence.

What do you want to say?

[Jerry Stuckle]

Agreed that Rust is a pain. But there are programmers which can't
handle the responsibilities C places on them, and need some other
language that better holds their hand.

--
==================
Remove the "x" from my email address
Jerry Stuckle
jstu...@attglobal.net
==================

[woodb...@gmail.com]

On Tuesday, July 18, 2017 at 2:42:20 PM UTC-5, Öö Tiib wrote:
> On Tuesday, 18 July 2017 20:34:48 UTC+3, Lynn McGuire wrote:
> > "Death to C, ++"
> > https://techcrunch.com/2017/07/16/death-to-c/
> >
> > "The C programming language is terrible. I mean, magnificent, too. Much
> > of the world in which we live was built atop C. It is foundational to
> > almost all computer programming, both historically and practically;
> > there’s a reason that the curriculum for Xavier Niel’s revolutionary
> > “42” schools begins with students learning how to rewrite standard C
> > library functions from scratch. But C is no longer suitable for this
> > world which C has built."
> >
> > I disagree. True, working in C and C++ is like walking on a tight rope.
> > But, if one cannot walk the tightrope then one should find something
> > else to do in life. After all, working on the high wire is not for
> > everyone.
>
> The decades with C have caused lot of great code checking, testing
> and debugging tools to raise that make even C quite safe to use.

No mention of the free enterprise system that has been the
soil for the development of the tools. They just happened
over time, right? If I hadn't adopted an on line business
model years ago, I would have been devoured by the entitlement
mentality that you promote.

> It feels just bit inconvenient language (and not like on high wire).
>
> C++ additionally contains such convenience subset with what the
> feeling is like running in park. Memory corruptions with buffer
> overflows or dangling pointers are not possible when using that
> subset. But C++ is large and so it takes years to learn the borders
> with it and rest of the "technically valid" C++ language.
>

On-line code generators are intended to help with that. Users
provide a high-level description of what they want and get
back a low-level implementation.


Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net

[woodb...@gmail.com]

I like some of C, but I like it primarily as a part of C++.


Brian
Ebenezer Enterprises - I'm thankful for Jerry as he
has reminded me to be thankful for C++.

http://webEbenezer.net

[Öö Tiib]

I wanted to say that with Rust one is constantly stuck for
seemingly artificial reasons imposed by language. So it is
perhaps fine language for people who don't want to program
at all.

[Öö Tiib]

On Wednesday, 19 July 2017 00:58:12 UTC+3, woodb...@gmail.com wrote:
> On Tuesday, July 18, 2017 at 2:42:20 PM UTC-5, Öö Tiib wrote:
> > On Tuesday, 18 July 2017 20:34:48 UTC+3, Lynn McGuire wrote:
> > > "Death to C, ++"
> > > https://techcrunch.com/2017/07/16/death-to-c/
> > >
> > > "The C programming language is terrible. I mean, magnificent, too. Much
> > > of the world in which we live was built atop C. It is foundational to
> > > almost all computer programming, both historically and practically;
> > > there’s a reason that the curriculum for Xavier Niel’s revolutionary
> > > “42” schools begins with students learning how to rewrite standard C
> > > library functions from scratch. But C is no longer suitable for this
> > > world which C has built."
> > >
> > > I disagree. True, working in C and C++ is like walking on a tight rope.
> > > But, if one cannot walk the tightrope then one should find something
> > > else to do in life. After all, working on the high wire is not for
> > > everyone.
> >
> > The decades with C have caused lot of great code checking, testing
> > and debugging tools to raise that make even C quite safe to use.
>
> No mention of the free enterprise system that has been the
> soil for the development of the tools. They just happened
> over time, right? If I hadn't adopted an on line business
> model years ago, I would have been devoured by the entitlement
> mentality that you promote.

What you mean? Software on what people work gets inevitably better
over time. No difference if there is tyranny or free market or
communism and who has what rights or privileges. Right here where I
now live was fully blossoming Communism when I first wrote a
program in C.

[Melzzzzz]

Heh, never thought to implement it like that ;)
What about tree ? ;)
In my experience in Rust you use raw pointers for everything that wrap
it up in "safe" code ;)

[Jerry Stuckle]

I do both. It just depends on the project, and if I'm working with a
group, the skill set of the other programmers.

[bitrex]

On 07/18/2017 08:56 PM, Jerry Stuckle wrote:

>> I like some of C, but I like it primarily as a part of C++.
>>
>>
>> Brian
>> Ebenezer Enterprises - I'm thankful for Jerry as he
>> has reminded me to be thankful for C++.
>>
>> http://webEbenezer.net
>>
>
> I do both. It just depends on the project, and if I'm working with a
> group, the skill set of the other programmers.
>

C got a bad rap because while it was developed before personal
networking/Internet became commonplace, it was still used millions of
times over with its regular insecure stdlib library implementations from
1983 or whenever in every type of product under the sun where anything
and everything from God knows where on the network was allowed to "talk"
directly with those functions.

The author doesn't acknowledge however that there are many many
applications where security from Internet attackers is just not a
concern, where C is a perfectly appropriate systems programming language
and the best tool for the job. My microwave oven doesn't need to talk to
the Internet. My car's ECU doesn't need to talk to the Internet. My
polyphonic digital synthesizer doesn't need to talk to the Internet.

I've found that the x86 desktop/web coders I'm acquainted with are
remarkably ignorant of "how things are" in the embedded world these
days; oh an embedded processor? I thought you hand wrote asm for those?
Good grief no, we use C and C++ the same as anyone else. Yes you can use
C++ on a modern 32 (or 16, or even 8) bit microcontroller. No it's not
slow. Yes you can use templates and virtual functions and OOP.

The complaint basically seems to be that what is essentially a
bare-metal systems programming language isn't also intrinsically good at
sanitizing weird-ass SQL injection attacks or whatever coming in over a
network infrastructure 30 years more advanced than the language itself.
Um duh? Your blazing fast bare-metal code shouldn't be in charge of
gatekeeping too, that's not its job.

"What I’m advocating for is much simpler: surgically replace weaker
parts but keep most of the project intact. […] You can actually take a
piece of C code inside an existing project, import the C structures and
functions to access them from Rust, rewrite the code in Rust, export the
functions and structures from Rust, compile it and link it with the rest
of the project."

If you need both blazing speed and strong security delegating
responsibility like that is sort of what one should have been doing all
along, yeah? Multiplayer game engines have been doing this for years,
sandboxing the users away from the high performance graphics/physics
code by only allowing interaction with it thru a well-defined set of
calls processed by a scripting language/virtual machine.

[Richard]

[Please do not mail me a copy of your followup]

Lynn McGuire <lynnmc...@gmail.com> spake the secret code
<oklgjm$foc$1...@dont-email.me> thusly:

>"Death to C, ++"

Meh. Glancing through the article, the author seems to conflate C
with C++. Every time a programmer in another language tells me how
horribly unmaintainable C++ code is based on some experience in their
company, I ask them to show me the code. The code is invariably C
code (or C++ written in C code style). I'm sorry, but I can't help
you if you insist on using bad programming habits that were obsolete
at the time C++ was first released for general use in the mid 80s.

If this is your problem, then switching languages won't help. You can
write horrible code in any language. If you don't know how to write
maintainable code, then no language can help you. It is possible to
write maintainable, secure, testable, etc., code in C. It is easier
in C++ to achieve those goals than it is in C IMO. Every time I'm
forced to go back and program in C, I remember why I left it for C++
in the early 90s.

Languages have never been, and IMO never will be, silver bullets that
solve all your problems. Java didn't solve everyone's problems and
neither did C#. Similarly, neither did Modula-2, Ada, RPG II,
FORTRAN, LISP, Erlang, Clojure, etc., etc. Each of these languages
have their own strenths and weaknesses and using them appropriately is
part of being a polyglot programmer. Trying to find one language to
rule them all is a silly endeavour.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[jacobnavia]

Le 19/07/2017 à 05:20, Richard a écrit :
> Meh. Glancing through the article, the author seems to conflate C
> with C++. Every time a programmer in another language tells me how
> horribly unmaintainable C++ code is based on some experience in their
> company, I ask them to show me the code. The code is invariably C
> code (or C++ written in C code style).

Thanks for repeating the mantra of all incompetent C++ programmers:

C is bad.

Yeah.

And that is not backed up with any real data. Just stories as they like
to tell, to mask their lies.

There is not a single thread of evidence that C code is "unmaintainable"
any more than C++ code is. C is readable, C++ is NOT.

You just cannot go into all those nested templates, classes, whatever.
You MUST use the debugger to see where that code is going.

This is a fact.

[Ian Collins]

I don't... I look at C and C++ code with the same source browser.

Foreign code is equally opaque no matter the language.

--
Ian

[Manfred]

On 7/19/2017 5:20 AM, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Lynn McGuire <lynnmc...@gmail.com> spake the secret code
> <oklgjm$foc$1...@dont-email.me> thusly:
>
>> "Death to C, ++"
>
> Meh. Glancing through the article, the author seems to conflate C
> with C++. Every time a programmer in another language tells me how
> horribly unmaintainable C++ code is based on some experience in their
> company, I ask them to show me the code. The code is invariably C
> code (or C++ written in C code style). I'm sorry, but I can't help
> you if you insist on using bad programming habits that were obsolete
> at the time C++ was first released for general use in the mid 80s.

I don't share your blame for C, but I agree that the author is wrong in
his perspective of C and C++ - obviously he does not know them well
enough, if in 2017 he keeps on conflating them into each other.
One thing that C and C++ share in common is that they are both languages
that are not meant to be handled superficially or without enough
knowledge. They give a lot of potential to the programmer, but the
programmer is expected to know what he/she is doing - the criticism of
the author seems pretty much stemming from missing this point.
IMHO the superficiality of the author also emerges when he reports that
the single best feature of C is "getting down to the bare metal and
working at mach speed"

Specifically about code security, I also do not agree that C and C++ (at
their respective levels) are inherently unsafe.
If used properly, in their respective area of operation, code written on
these languages is very well safe, actually it can be safer than other
languages that rely on some runtime that is out of the control of the
programmer.

AFAIK the Linux kernel is one of the safest available, and it is
entirely written in C/asm, not a single line in Rust or any other fancy
language that is supposed to "oxidize away" C (and C++)

[jacobnavia]

Well, that confirms what I said. You need a machine to see where it is
going. Yes, a source code browsing software will tell you where is
going, the same as the debugger.

[Ian Collins]

On 07/19/17 11:21 PM, jacobnavia wrote:
> Le 19/07/2017 à 12:00, Ian Collins a écrit :
>> On 07/19/17 08:59 PM, jacobnavia wrote:
>
>>> You just cannot go into all those nested templates, classes, whatever.
>>> You MUST use the debugger to see where that code is going.
>>
>> I don't... I look at C and C++ code with the same source browser.
>>
>
> Well, that confirms what I said. You need a machine to see where it is
> going. Yes, a source code browsing software will tell you where is
> going, the same as the debugger.

As I said, the same for both C and C++.

--
Ian

[Mr Flibble]

That short article is not only lazy, it is egregious. There is no such
language as C/C++. Security exploits are a lot harder to accidentally
create in C++ than in C if you use C++ properly (RAII, iterators etc).

/Flibble

[Jerry Stuckle]

The same is true of any library code for any language. The whole idea
of object oriented programming is you don't HAVE to know what happens
inside - the object takes care of itself.

How do you determine the system computes pow(3.4,5.6)?

[Bill Dugan]

An important factor which most of the posts here have been ignoring.
The writer is almost never the last person to touch the code, and
shouldn't assume too much about the skill of someone modifying it
years later.

[jacobnavia]

Le 19/07/2017 à 15:40, Jerry Stuckle a écrit :
> How do you determine the system computes pow(3.4,5.6)?

log(pow(3.4,5.6))/log(3.4)
5.6

That means the system is working OK.

[Öö Tiib]

On case of gcc it more likely shows that the compiler is cheating.
Just tried on gcc 7.1.0:

static_assert(log(pow(3.4,5.6))/log(3.4) == 5.6, "Magic must work");

Compiles.

[bartc]

Not necessarily:

#include <stdio.h>

double pow(double x,double y){return x*y;}
double log(double x){return x;}

int main(void) {
printf("%f\n", log(pow(3.4,5.6))/log(3.4));
}

Output: 5.60000

--
bartc

[Real Troll]

Why do you say "Not necessarily? you mixing the two functions: pow is
just power of a number while log is the log of the number so clearly the
answer you get is correct. I just ran it in VS2017 and this is what I got:

pow(3.4, 5.6) = 946.851639
Log ( pow(3.4, 5.6) ) = 6.853142
log(pow(3.4,5.6))/log(3.4) = 5.600000
Press any key to continue . . .

This is the full program:

#include <stdio.h>
#include <math.h>

int main(void)
{


double num1 = pow(3.4, 5.6);
printf("pow(3.4, 5.6) = %f \n", num1);

double num2 = log(num1);
printf("Log ( pow(3.4, 5.6) ) = %f \n", num2);

double num3 = log(num1) / log(3.4);
printf("log(pow(3.4,5.6))/log(3.4) = %f\n", num3);

return 0;
}

[Gareth Owen]

jacobnavia <ja...@jacob.remcomp.fr> writes:

> There is not a single thread of evidence that C code is
> "unmaintainable" any more than C++ code is. C is readable, C++ is NOT.

[Jerry Stuckle]

That didn't answer my question.

[Juha Nieminen]

In comp.lang.c++ jacobnavia <ja...@jacob.remcomp.fr> wrote:
> C is readable, C++ is NOT.

Clearly you haven't seen any C projects out there.

Take something like mplayer, with its thousand-line-long
functions with zero comments and completely cryptic logic
(not to talk about variable names).

[Öö Tiib]

,--[quote]
| Besides, the determined Real Programmer can write FORTRAN programs
| in any language.
'-- http://web.mit.edu/humor/Computers/real.programmers

[jacobnavia]

Le 19/07/2017 à 22:20, Juha Nieminen a écrit :
> In comp.lang.c++ jacobnavia <ja...@jacob.remcomp.fr> wrote:
>> C is readable, C++ is NOT.
>
> Clearly you haven't seen any C projects out there.
>

Yes, I know, I am a novice. I have always been actually. There is always
something new to learn for me.

> Take something like mplayer, with its thousand-line-long
> functions with zero comments and completely cryptic logic
> (not to talk about variable names).
>

Yes, but those problems are easy to solve. By the way there is nothing
in C that forbids to write comments, just people in a hurry (like many
programmers) that do not have the time to comment anything.

Software can be difficult to follow, granted, but the complexity of C++
adds several layers of language specific problems.

c = foo(pData,42);

Is this a macro or a function call? Here C++ shares the lack of
distinction between macros and function calls of C.

In C, the declarations of pData, foo and c are mostly in the local
frame. Or maybe not and you have to hunt for that in the headers, that
in any significant project, are always a mess.

But in C++ foo could be a method of the current object too. Normally you
add an "m_" to the method's name, but not all people follow that. And if
you see the 'm_', indicating a method call, you have to figure out where
in the class hierarchy a method has been defined with that name.

This can no longer be done with vi and grep. Yes, I should put into that
computer (an embedded system) a super-duper dev system that does that,
but it would overwhelm the micro-sd card with 64GB that I bought for it.

Yes, I could send the sources to my mac, and there make an Xcode project
to figure out the C++, but that would complexify the dev system, that is
running ok with Unix, vi and grep.

Worst, the clang c++ compiler behaves differently than the g++ of the
arm system

Besides, it is fun. I feel that I am really having fun, ignoring all the
new stuff and just using vi, make, gcc, and grep.

I am writing a JIT compiler for that system: you pass it a buffer of C
code, and it will return a buffer full of machine instructions that you
can execute on the fly. The C code is generated by a C++ SQL database,
that translates each SQL statement into C code, that is compiled and
executed on the fly.

That is the context: I am trying to compile the database.

[Siri Cruise]

In article <okoeuv$2o5d$1...@adenine.netfront.net>,

Juha Nieminen <nos...@thanks.invalid> wrote:

> In comp.lang.c++ jacobnavia <ja...@jacob.remcomp.fr> wrote:
> > C is readable, C++ is NOT.
>
> Clearly you haven't seen any C projects out there.

I don't know what the problem is, but C++ isn't the answer.


In article <oklgjm$foc$1...@dont-email.me>, Lynn McGuire <lynnmc...@gmail.com>
wrote:

> I disagree. True, working in C and C++ is like walking on a tight rope.
> But, if one cannot walk the tightrope then one should find something
> else to do in life. After all, working on the high wire is not for
> everyone.

You're not going to improve on C without changing some deeply held ideas about
what is 'efficient', like array bound checking and garbage collection. C++ sucks
because, besides the rampaging featurism, it tries to do automatic storage
collection without garbage collection. It means things like closures cannot be
implemented without considerable work by the programmer.

--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
Free the Amos Yee one. This post / \
Yeah, too bad about your so-called life. Ha-ha. insults Islam. Mohammed

[Melzzzzz]

On 2017-07-19, Siri Cruise <chine...@yahoo.com> wrote:
> In article <okoeuv$2o5d$1...@adenine.netfront.net>,
> Juha Nieminen <nos...@thanks.invalid> wrote:
>
>> In comp.lang.c++ jacobnavia <ja...@jacob.remcomp.fr> wrote:
>> > C is readable, C++ is NOT.
>>
>> Clearly you haven't seen any C projects out there.
>
> I don't know what the problem is, but C++ isn't the answer.
>
>
> In article <oklgjm$foc$1...@dont-email.me>, Lynn McGuire <lynnmc...@gmail.com>
> wrote:
>
>> I disagree. True, working in C and C++ is like walking on a tight rope.
>> But, if one cannot walk the tightrope then one should find something
>> else to do in life. After all, working on the high wire is not for
>> everyone.
>
> You're not going to improve on C without changing some deeply held ideas about
> what is 'efficient', like array bound checking and garbage collection. C++ sucks
> because, besides the rampaging featurism, it tries to do automatic storage
> collection without garbage collection. It means things like closures cannot be
> implemented without considerable work by the programmer.

But C++ already has closures ;p
GC is not in fashion any more as both Rust and Swift does not have it.
Rust had it, but they dropped it later... There is lot of pressure on
Walter (D author) to make D std lib GC free and language to work without it.

[Chris Ahlstrom]

Lynn McGuire wrote this copyrighted missive and expects royalties:

> "Death to C, ++"
> https://techcrunch.com/2017/07/16/death-to-c/
>
> "The C programming language is terrible. I mean, magnificent, too. Much
> of the world in which we live was built atop C. It is foundational to
> almost all computer programming, both historically and practically;
> there’s a reason that the curriculum for Xavier Niel’s revolutionary
> “42” schools begins with students learning how to rewrite standard C
> library functions from scratch. But C is no longer suitable for this
> world which C has built."
>

> I disagree. True, working in C and C++ is like walking on a tight rope.
> But, if one cannot walk the tightrope then one should find something
> else to do in life. After all, working on the high wire is not for
> everyone.

All languages have a valid domain.

--
Q: What do you call a boomerang that doesn't come back?
A: A stick.

[Paavo Helde]

On 19.07.2017 23:51, jacobnavia wrote:
> Le 19/07/2017 à 22:20, Juha Nieminen a écrit :
>> In comp.lang.c++ jacobnavia <ja...@jacob.remcomp.fr> wrote:
>>> C is readable, C++ is NOT.
>>
>> Clearly you haven't seen any C projects out there.
>>
>
> Yes, I know, I am a novice. I have always been actually. There is always
> something new to learn for me.
>
>> Take something like mplayer, with its thousand-line-long
>> functions with zero comments and completely cryptic logic
>> (not to talk about variable names).
>>
>
> Yes, but those problems are easy to solve. By the way there is nothing
> in C that forbids to write comments, just people in a hurry (like many
> programmers) that do not have the time to comment anything.
>
> Software can be difficult to follow, granted, but the complexity of C++
> adds several layers of language specific problems.
>
> c = foo(pData,42);
>
> Is this a macro or a function call? Here C++ shares the lack of
> distinction between macros and function calls of C.

In C++ there is about zero need for function macros and they bring
increased danger of name clashes, so in proper C++ code foo() is a
function, with a very high probability (unless the name is long, ugly
and fully capitalized).

>
> In C, the declarations of pData, foo and c are mostly in the local
> frame. Or maybe not and you have to hunt for that in the headers, that
> in any significant project, are always a mess.
>
> But in C++ foo could be a method of the current object too. Normally you
> add an "m_" to the method's name, but not all people follow that. And if
> you see the 'm_', indicating a method call, you have to figure out where
> in the class hierarchy a method has been defined with that name.

In C++ most functions tend to be members of some class, so the
probability that foo() is a class member function is way higher than
50%. It's the free functions that are the exception, and these are often
marked specially with the namespace name, e.g. std::lower_bound() or
::ShellExecuteW().

Note however that the fact that a function is a class member does not
tell very much without knowing if it is also static or const.

>
> This can no longer be done with vi and grep. Yes, I should put into that
> computer (an embedded system) a super-duper dev system that does that,
> but it would overwhelm the micro-sd card with 64GB that I bought for it.

The feature which I very often use for such code lookup in my IDE is
"find in all project files". This is basically just a grep and it finds
me all the overloads and overrides of foo. Of course, in order to know
which one is called at any point requires some familiarity with the
relevant class hierarchies.

Admittedly, this is because my IDE is too stupid and its "go to
definition" feature does not work correctly half of the time or is just
unbearably slow.

>
> Yes, I could send the sources to my mac, and there make an Xcode project
> to figure out the C++, but that would complexify the dev system, that is
> running ok with Unix, vi and grep.

TANSTAAFL. If you want to save on the hardware by using a small embedded
system, then you have to pay somewhere else.

[Ian Collins]

On 07/20/17 08:51 AM, jacobnavia wrote:
>
> Yes, but those problems are easy to solve. By the way there is nothing
> in C that forbids to write comments, just people in a hurry (like many
> programmers) that do not have the time to comment anything.
>
> Software can be difficult to follow, granted, but the complexity of C++
> adds several layers of language specific problems.

What I don't get is why you can't recognise that C++ can simplify
spaghetti C code.

You only have to take a brief look through something like the Linux
kernel, which is good well reviewed C, and you will find many cases of
almost identical goto ridden code like:

struct autogroup *ag = kzalloc(sizeof(*ag), GFP_KERNEL);
struct task_group *tg;

if (!ag)
goto out_fail;

tg = sched_create_group(&root_task_group);

if (IS_ERR(tg))
goto out_free;

Which could be rewritten in a clean, goto free, manner by adding RAII.

C + a little bit of C++ is a great way to write cleaner, goto free, code.

--
Ian

[Paavo Helde]

On 19.07.2017 23:55, Siri Cruise wrote:
> In article <okoeuv$2o5d$1...@adenine.netfront.net>,
> Juha Nieminen <nos...@thanks.invalid> wrote:
>
>> In comp.lang.c++ jacobnavia <ja...@jacob.remcomp.fr> wrote:
>>> C is readable, C++ is NOT.
>>
>> Clearly you haven't seen any C projects out there.
>
> I don't know what the problem is, but C++ isn't the answer.
>
>
> In article <oklgjm$foc$1...@dont-email.me>, Lynn McGuire <lynnmc...@gmail.com>
> wrote:
>
>> I disagree. True, working in C and C++ is like walking on a tight rope.
>> But, if one cannot walk the tightrope then one should find something
>> else to do in life. After all, working on the high wire is not for
>> everyone.
>
> You're not going to improve on C without changing some deeply held ideas about
> what is 'efficient', like array bound checking and garbage collection. C++ sucks
> because, besides the rampaging featurism, it tries to do automatic storage
> collection without garbage collection. It means things like closures cannot be
> implemented without considerable work by the programmer.

What's so special about closures that they would not be able to manage
any needed storage automatically, similar to all other C++ features?
(Hint: they are not special).

And what's so special about garbage collection that one should
definitely embrace it? It's just a sloppy fallback mechanism if the
language or the programmer is not able to manage the object lifetimes
properly. But thanks to RAII C++ is fully capable to manage the object
lifetimes properly.

[Siri Cruise]

In article <Q6KdnWzp9tvHfvLE...@giganews.com>,

Try directed graphs that can include cycles. You can't free a node until all
incoming edges are cut. So you have to keep a count of incoming edges (reference
count), but reference counts can't reclaim an isolated cycle. This is a well
known limitation of reference count.

Apple's ObjC does it by distinguish forward edges and back edges, with only
forward edges contributing to reference count. However no general way
distinguishes which should be which, so you have to encode domain information
into a generic graph package.

Another way is to reimplement mark and sweep, poorly, by linking all the active
and inactive nodes in a list and then sweeping the list with domain knowledge to
decide which nodes can be deleted.

Any data structure which can be a cyclic directed graph cannot be handled with a
single generic graph package which isolates all graph construction from domain
specific nodes and edges.

[Richard]

[Please do not mail me a copy of your followup]

Manfred <non...@invalid.add> spake the secret code
<okndu4$naq$1...@gioia.aioe.org> thusly:

>One thing that C and C++ share in common is that they are both languages
>that are not meant to be handled superficially or without enough
>knowledge.

One reason I think this attitude is prevalent is because people learn
C++ by learning C first. Either it is explicitly taught to them that
way in a C++ course, or they keep seeing crappy C-style C++ code and
think that is C++.

Seriously, I haven't had resource leak errors since I learned the
standard library for containers and used smart pointers for managing
heap storage. It just doesn't happen anymore. Anyone who teaches C++
by starting you out with new/delete, or even worse malloc/free, is
someone who isn't teaching you C++. Hell, they aren't even teaching
you C++98, never mind C++17.

I've written a lot of code in C. I'm more productive without any loss
of performance (measure twice, optimize once) when I write code in
C++. This is due to the abstraction facilities available to me in C++
-- which are many -- compared to the paucity of such facilities in C
-- structs and functions.

It is possible to write a large OO-oriented application in C. The
best example is the X11 Window Server sample implementation from MIT.
Really. Go read it, it's awesome. But it's clear that you could do
the same thing with simpler coding and less error-prone mechanisms in
C++ than they did in C. They used C because it was the least common
denominator of the day (mid 80s). They used OO-oriented programming
because it makes sense for an extensible GUI server.

[Richard]

[Please do not mail me a copy of your followup]

ja...@jacob.remcomp.fr spake the secret code
<okn6ro$uug$1...@dont-email.me> thusly:

>Le 19/07/2017 à 05:20, Richard a écrit :
>> Meh. Glancing through the article, the author seems to conflate C
>> with C++. Every time a programmer in another language tells me how
>> horribly unmaintainable C++ code is based on some experience in their
>> company, I ask them to show me the code. The code is invariably C
>> code (or C++ written in C code style).
>
>Thanks for repeating the mantra of all incompetent C++ programmers:
>
>C is bad.

C itself is fine. C requires a significant amount of personally
imposed disciplnie to keep it maintainable. I've written tons of C
code. C has weak abstraction mechanisms, therefore you have to impose
self discipline to create those abstractions yourself and implement
the mechanics yourself. As I said earlier in this thread, go read the
X Window System server sample implementation. It's great.

However, it is easier to do the same thing in C++. That is, after
all, what C++ was designed to do: retain the direct map to the
hardware that C provides while adding the higher level abstraction
facilities that C is missing.

>And that is not backed up with any real data. Just stories as they like
>to tell, to mask their lies.

Well it's nice to have you put words in my mouth.

>There is not a single thread of evidence that C code is "unmaintainable"
>any more than C++ code is. C is readable, C++ is NOT.

This is a straw man. I never said this. I simply said that when
other people show me their examples of horrible code, it is flagrant
examples of the kinds of poorly written code that comes from people
who have C programming habits. They didn't have discipline imposed on
them by a strong type system and they also didn't impose any
discipline on themselves and they wrote crap. This, in turn, is used
by the C# or Java afficionado as "proof" that C/C++ is a "bad
language" because it allowed such undisciplined programming to
compile. I already addressed earlier that you can write shit in any
language, but my point was that when fans of other languages show me
examples of why "C++ is bad", they are showing me code that isn't even
typical of C++ code written 15 years ago, much less typical C++ code
that is written today. They're laying the blame on the language and
not the author.

>You just cannot go into all those nested templates, classes, whatever.
>You MUST use the debugger to see where that code is going.
>
>This is a fact.

No, it's an opinion. But hey, you must be one of those people that
can't leave the Christian religion trolls alone without feeding them
because you've already ended up in my KILL file for some reason, so I
am probably not going to spend any more time replying to your messages
on this thread.

[Alf P. Steinbach]

* On 20.07.2017 02:20, Siri Cruise wrote:
> * In article <Q6KdnWzp9tvHfvLE...@giganews.com>,

> Paavo Helde <myfir...@osa.pri.ee> wrote:
>>
>> And what's so special about garbage collection that one should
>> definitely embrace it? It's just a sloppy fallback mechanism if the
>> language or the programmer is not able to manage the object lifetimes
>> properly. But thanks to RAII C++ is fully capable to manage the object
>> lifetimes properly.
>
> Try directed graphs that can include cycles.

In the case of a graph where the number of added nodes (from creation of
the graph) is never unreasonably large, one can simply let the graph's
nodes be owned by a graph object, and defer destruction of individual
nodes until the graph as a whole is destroyed.

But what if nodes in a graph may refer to nodes in other graphs, or the
number of added nodes, over time, can be Really Great?

Well then one needs garbage collection, unless there is some special
property that can be leveraged. But a garbage collector that's special
purposed for graph nodes, can probably be far more efficient and in tune
with the application requirements for responsiveness etc., than a
completely general garbage collector. So, since this is the only problem
that over the years has popped up showing a definite need for garbage
collection, I think we need a sort of standardized set of requirements
on graph nodes, that support a standard graph node collector. ;-)


Cheers!,

- Alf

[Juha Nieminen]

In comp.lang.c++ Siri Cruise <chine...@yahoo.com> wrote:
> C++ sucks because, besides the rampaging featurism, it tries to do automatic storage
> collection without garbage collection. It means things like closures cannot be
> implemented without considerable work by the programmer.

I have always loved the oxymoronic argument of "C++ is too large! And it doesn't
have feature X!"

So which is it, it has too many features, or it doesn't have enough features?
It needs less programming paradigms, or more of them? Make up your mind.

If the criticism is this contradictory, then it doesn't sound very valid.

[Juha Nieminen]

In comp.lang.c++ Siri Cruise <chine...@yahoo.com> wrote:

> Try directed graphs that can include cycles. You can't free a node until all
> incoming edges are cut. So you have to keep a count of incoming edges (reference
> count), but reference counts can't reclaim an isolated cycle. This is a well
> known limitation of reference count.

Yeah, that makes things like automatically managed double-linked lists
impossible.

Oh, wait...

[Siri Cruise]

In article <okpbm4$1vf6$2...@adenine.netfront.net>,

That's a form of a cyclic directed graph, with distinct forward and back edges.

[Gareth Owen]

Ian Collins <ian-...@hotmail.com> writes:

> On 07/20/17 08:51 AM, jacobnavia wrote:
>>
>> Yes, but those problems are easy to solve. By the way there is nothing
>> in C that forbids to write comments, just people in a hurry (like many
>> programmers) that do not have the time to comment anything.
>>
>> Software can be difficult to follow, granted, but the complexity of C++
>> adds several layers of language specific problems.
>
> What I don't get is why you can't recognise that C++ can simplify
> spaghetti C code.

Because - as he has proven over and over again - he has literally no
interest in anything that challenges how he has already made his mind
up. C++ is bad and unreadable, C is smooth and elegant

[Paavo Helde]

On 20.07.2017 8:05, Siri Cruise wrote:
> In article <okpbm4$1vf6$2...@adenine.netfront.net>,
> Juha Nieminen <nos...@thanks.invalid> wrote:
>
>> In comp.lang.c++ Siri Cruise <chine...@yahoo.com> wrote:
>>> Try directed graphs that can include cycles. You can't free a node until
>>> all
>>> incoming edges are cut. So you have to keep a count of incoming edges
>>> (reference
>>> count), but reference counts can't reclaim an isolated cycle. This is a
>>> well
>>> known limitation of reference count.
>>
>> Yeah, that makes things like automatically managed double-linked lists
>> impossible.
>>
>> Oh, wait...
>
> That's a form of a cyclic directed graph, with distinct forward and back edges.

Yes, but this distinction is not required or utilized by std::list
implementations, they handle both edges very much symmetrically.

You also appear to claim that C++ graph classes like
boost::adjacency_list are impossible.

If you want to have cyclic graphs, then use a graph class instead of
inventing your own mess. And if you have an heterogeneous net of objects
which can contain cycles then you should better make up your mind in
advance and decide which links are to be handled by std::weak_ptr. If
you do not, then you will get more problems than just memory leaks,
starting from infinite loops and stack overflows.

[Siri Cruise]

In article <_7qdnZo87OSLz-3E...@giganews.com>,

Paavo Helde <myfir...@osa.pri.ee> wrote:

> On 20.07.2017 8:05, Siri Cruise wrote:
> > In article <okpbm4$1vf6$2...@adenine.netfront.net>,
> > Juha Nieminen <nos...@thanks.invalid> wrote:
> >
> >> In comp.lang.c++ Siri Cruise <chine...@yahoo.com> wrote:
> >>> Try directed graphs that can include cycles. You can't free a node until
> >>> all
> >>> incoming edges are cut. So you have to keep a count of incoming edges
> >>> (reference
> >>> count), but reference counts can't reclaim an isolated cycle. This is a
> >>> well
> >>> known limitation of reference count.
> >>
> >> Yeah, that makes things like automatically managed double-linked lists
> >> impossible.
> >>
> >> Oh, wait...
> >
> > That's a form of a cyclic directed graph, with distinct forward and back
> > edges.
>
> Yes, but this distinction is not required or utilized by std::list
> implementations, they handle both edges very much symmetrically.

In a SLIP list node, links in one direction are forward edges, and links in the
other are back edges. Discounting back edges, they are acyclic and not
branching, so you can apply that knowledge to their management. That's why you
can make a SLIP garbage collector which is not mark-sweep. And trees are acyclic
and do not rejoin branches, so you can apply that knowledge to make a tree
garbage collector.

Gosh! What a surprise! For data structures that cannot be cyclic DGs, you can
write a specialised collector for each one.

> You also appear to claim that C++ graph classes like
> boost::adjacency_list are impossible.

If they support cyclic DGs, you can't collect all garbage without some form of
mark-sweep or encoding domain specific knowledge about when a cycle becomes
garbage.

> If you want to have cyclic graphs, then use a graph class instead of
> inventing your own mess. And if you have an heterogeneous net of objects
> which can contain cycles then you should better make up your mind in
> advance and decide which links are to be handled by std::weak_ptr. If

Quoth:

Apple's ObjC does it by distinguish forward edges and back edges,
with only forward edges contributing to reference count. However
no general way distinguishes which should be which, so you have
to encode domain information into a generic graph package.

[Chris M. Thomasson]

Fwiw, proxy garbage collection is fairly nice, and can be implemented
using pure C++:

https://groups.google.com/d/topic/lock-free/X3fuuXknQF0/discussion
(read all)

[Richard Heathfield]

On 20/07/17 04:36, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> ja...@jacob.remcomp.fr spake the secret code
> <okn6ro$uug$1...@dont-email.me> thusly:
>

>> Le 19/07/2017 à 05:20, Richard a écrit :

>>> Meh. Glancing through the article, the author seems to conflate C
>>> with C++. Every time a programmer in another language tells me how
>>> horribly unmaintainable C++ code is based on some experience in their
>>> company, I ask them to show me the code. The code is invariably C
>>> code (or C++ written in C code style).
>>
>> Thanks for repeating the mantra of all incompetent C++ programmers:
>>
>> C is bad.
>
> C itself is fine. C requires a significant amount of personally
> imposed disciplnie to keep it maintainable.

Agreed. C and C++ are, in this respect, like any other language - it is
possible to write readable code, and it is possible to write unreadable
code, in either C or C++.

>> There is not a single thread of evidence that C code is "unmaintainable"
>> any more than C++ code is. C is readable, C++ is NOT.
>
> This is a straw man. I never said this.

Fine. But it's partly true anyway. A more accurate rendition would be:

Some C is readable. Some is not.

Some C++ is readable. Some is not.

<snip>

>> You just cannot go into all those nested templates, classes, whatever.
>> You MUST use the debugger to see where that code is going.
>>
>> This is a fact.
>
> No, it's an opinion. But hey, you must be one of those people that
> can't leave the Christian religion trolls alone without feeding them

He is.

> because you've already ended up in my KILL file for some reason,

No, he hasn't. If he had, you would not have replied to him, because you
would not even have seen his message. That's the joy of kill files. I
suggest you read up on what they are, what they're for, and why it's a
good idea to use them.

> so I
> am probably not going to spend any more time replying to your messages
> on this thread.

If you had a kill file, you could s/ probably//

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[Bo Persson]

On 2017-07-19 22:51, jacobnavia wrote:
> Le 19/07/2017 à 22:20, Juha Nieminen a écrit :
>> In comp.lang.c++ jacobnavia <ja...@jacob.remcomp.fr> wrote:
>>> C is readable, C++ is NOT.
>>
>> Clearly you haven't seen any C projects out there.
>>
>
> Yes, I know, I am a novice. I have always been actually. There is always
> something new to learn for me.
>
>> Take something like mplayer, with its thousand-line-long
>> functions with zero comments and completely cryptic logic
>> (not to talk about variable names).
>>
>
> Yes, but those problems are easy to solve. By the way there is nothing
> in C that forbids to write comments, just people in a hurry (like many
> programmers) that do not have the time to comment anything.
>
> Software can be difficult to follow, granted, but the complexity of C++
> adds several layers of language specific problems.
>
> c = foo(pData,42);
>
> Is this a macro or a function call? Here C++ shares the lack of
> distinction between macros and function calls of C.
>

In C++ this would be

c = pData->foo(42);

and pretty obvious that it is a member function. So obvious that you
might even remove the p prefix from pData.



Bo Persson

[James Kuyper]

On 07/20/2017 12:29 AM, Juha Nieminen wrote:
> In comp.lang.c++ Siri Cruise <chine...@yahoo.com> wrote:
>> C++ sucks because, besides the rampaging featurism, it tries to do automatic storage
>> collection without garbage collection. It means things like closures cannot be
>> implemented without considerable work by the programmer.
>
> I have always loved the oxymoronic argument of "C++ is too large! And it doesn't
> have feature X!"
>
> So which is it, it has too many features, or it doesn't have enough features?

Neither - when people say that, what they actually mean is that it has a
bunch of features they don't want, as well as lacking certain features
they do want.
It's the same problem as the government budget - it would be trivial to
avoid running a deficit if the government did everything I want it to
do, and nothing that I didn't want it to do - but then there's all of
those other voters who have different opinions about what the government
should and should not do, and the best you can hope for is a compromise
that leaves everyone equally unhappy (and expenditures exceeding tax
revenues).

With C++, the same mechanism leaves you with a language with two many
features for everyone to become fully familiar with all of them in a
reasonable amount of time. Everyone seems to program in their own chosen
subset of C++, and to be confused by code which uses a different subset.

[Mr. Man-wai Chang]

On 19/7/2017 1:34 AM, Lynn McGuire wrote:
>
> I disagree. True, working in C and C++ is like walking on a tight rope.
> But, if one cannot walk the tightrope then one should find something
> else to do in life. After all, working on the high wire is not for
> everyone.

Both C and C++ have proven their values. No reasonable doubts.

--
@~@ Remain silent! Drink, Blink, Stretch! Live long and prosper!!
/ v \ Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
^ ^ (x86_64 Ubuntu 9.10) Linux 2.6.39.3
不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

[Richard]

[Please do not mail me a copy of your followup]

Richard Heathfield <r...@cpax.org.uk> spake the secret code
<okpv8r$4f3$1...@dont-email.me> thusly:

>On 20/07/17 04:36, Richard wrote:
>> ja...@jacob.remcomp.fr spake the secret code
>> <okn6ro$uug$1...@dont-email.me> thusly:

>>> There is not a single thread of evidence that C code is "unmaintainable"
>>> any more than C++ code is. C is readable, C++ is NOT.
>>
>> This is a straw man. I never said this.
>
>Fine. But it's partly true anyway. A more accurate rendition would be:
>
>Some C is readable. Some is not.
>
>Some C++ is readable. Some is not.

A tautology is a thing that is tautological.

You can make similar statements for any language.

Saying this isn't adding anything to the conversation, however.

>> because you've already ended up in my KILL file for some reason,
>
>No, he hasn't. If he had, you would not have replied to him, because you
>would not even have seen his message.

I saw his reply quoted in someone else's message on the thread and
went back to respond to some of the points. So yes, he is in my KILL
file, but that doesn't prevent me from going back and reading a KILLed
message and replying to it if I so choose.

>If you had a kill file, you could s/ probably//

My KILL file serves me, not the other way around :).

[Richard Heathfield]

On 20/07/17 16:30, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Richard Heathfield <r...@cpax.org.uk> spake the secret code
> <okpv8r$4f3$1...@dont-email.me> thusly:
>
>> On 20/07/17 04:36, Richard wrote:
>>> ja...@jacob.remcomp.fr spake the secret code
>>> <okn6ro$uug$1...@dont-email.me> thusly:
>>>> There is not a single thread of evidence that C code is "unmaintainable"
>>>> any more than C++ code is. C is readable, C++ is NOT.
>>>
>>> This is a straw man. I never said this.
>>
>> Fine. But it's partly true anyway. A more accurate rendition would be:
>>
>> Some C is readable. Some is not.
>>
>> Some C++ is readable. Some is not.
>
> A tautology is a thing that is tautological.
>
> You can make similar statements for any language.

Quite so. In other words, Jacob's claim was without merit, despite being
partly true.

> Saying this isn't adding anything to the conversation, however.

The conversation, too, is without merit. Language wars are pointless.
Everybody has likes and dislikes, and what attracts some people to a
language will repel others from it. That's /why/ we have different
languages.

>
>>> because you've already ended up in my KILL file for some reason,
>>
>> No, he hasn't. If he had, you would not have replied to him, because you
>> would not even have seen his message.
>
> I saw his reply quoted in someone else's message on the thread and
> went back to respond to some of the points. So yes, he is in my KILL
> file, but that doesn't prevent me from going back and reading a KILLed
> message and replying to it if I so choose.

Fair enough. It's quite common for people to claim that they have added
a subscriber to their killfile when in fact they don't even /have/ a
killfile. It is now clear that you don't fall into that category, so I
withdraw the insinuation and apologise for it.

De gustibus non est disputandum and all that, but despite many exchanges
with Jacob that have bordered on the acrimonious (and indeed crept over
that border on occasion) I have never killfiled him, because I have a
considerable amount of respect for him (although this may come as a
surprise to him!). I think many of his communication difficulties in
comp.lang.c come down to the fact that his English is very, very good,
and so we tend to forget that it is his /second/ language, and instead
wrongly assume that he has the usual native mastery of idiom and
phrasing. This is almost certainly at the root of quite a few breakdowns
in communication. Given that he has maintained lccwin32 more or less
single-handedly for at least 20 years and it *still works*, I am
inclined to cut him a little slack.

<snip>

[Gareth Owen]

legaliz...@mail.xmission.com (Richard) writes:

> A tautology is a thing that is tautological.
>
> You can make similar statements for any language.
>
> Saying this isn't adding anything to the conversation, however.

Actually, it is, because its clear truth refutes the childish notion
that it is not possible to write readable C++.

[Siri Cruise]

In article <okqia1$ev4$1...@news.xmission.com>,

legaliz...@mail.xmission.com (Richard) wrote:

> >Some C is readable. Some is not.
> >
> >Some C++ is readable. Some is not.
>
> A tautology is a thing that is tautological.
>
> You can make similar statements for any language.

Except Intercal.


And APL.

[Keith Thompson]

Bo Persson <b...@gmb.dk> writes:
[...]

>> Software can be difficult to follow, granted, but the complexity of C++
>> adds several layers of language specific problems.
>>
>> c = foo(pData,42);
>>
>> Is this a macro or a function call? Here C++ shares the lack of
>> distinction between macros and function calls of C.
>>
>
> In C++ this would be
>
> c = pData->foo(42);
>
> and pretty obvious that it is a member function. So obvious that you
> might even remove the p prefix from pData.

c = foo(pData, 42);

could be a valid call from one member function to another. A pointer to
the current instance is passed implicitly, so pData would be something
else. Without more context, you can't tell whether foo is a member
function or not.

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[James R. Kuyper]

On 07/20/2017 11:30 AM, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Richard Heathfield <r...@cpax.org.uk> spake the secret code
> <okpv8r$4f3$1...@dont-email.me> thusly:

...

>> Some C is readable. Some is not.
>>
>> Some C++ is readable. Some is not.
>
> A tautology is a thing that is tautological.
>
> You can make similar statements for any language.

Are you sure? Could you provide examples of readable code for each of
the languages described at
<https://en.wikipedia.org/wiki/Esoteric_programming_language>?

In fact, I'd be amused to see a readable example for any of those
languages. After a quick review of the list, I think that LOLCODE comes
closest to being readable.

[Chris M. Thomasson]

On 7/20/2017 3:09 AM, Richard Heathfield wrote:
> On 20/07/17 04:36, Richard wrote:
>> [Please do not mail me a copy of your followup]
>>
>> ja...@jacob.remcomp.fr spake the secret code
>> <okn6ro$uug$1...@dont-email.me> thusly:
>>
>>> Le 19/07/2017 à 05:20, Richard a écrit :
>>>> Meh. Glancing through the article, the author seems to conflate C
>>>> with C++. Every time a programmer in another language tells me how
>>>> horribly unmaintainable C++ code is based on some experience in their
>>>> company, I ask them to show me the code. The code is invariably C
>>>> code (or C++ written in C code style).
>>>
>>> Thanks for repeating the mantra of all incompetent C++ programmers:
>>>
>>> C is bad.
>>
>> C itself is fine. C requires a significant amount of personally
>> imposed disciplnie to keep it maintainable.
>
> Agreed. C and C++ are, in this respect, like any other language - it is
> possible to write readable code, and it is possible to write unreadable
> code, in either C or C++.
>
>>> There is not a single thread of evidence that C code is "unmaintainable"
>>> any more than C++ code is. C is readable, C++ is NOT.
>>
>> This is a straw man. I never said this.
>
> Fine. But it's partly true anyway. A more accurate rendition would be:
>
> Some C is readable. Some is not.

I have had to work on hard core macro laced code in C before. Think of
something along the lines of:

https://github.com/rofl0r/chaos-pp

It was basically unreadable, until I backtracked through all of the
macros. Even then, it was difficult.

> Some C++ is readable. Some is not.

Hard core template meta-programming can be pretty gnarly, especially
when its mixed with a boat load of macros.

[...]

[Ben Bacarisse]

Richard Heathfield <r...@cpax.org.uk> writes:

> On 20/07/17 16:30, Richard wrote:
>> [Please do not mail me a copy of your followup]
>>
>> Richard Heathfield <r...@cpax.org.uk> spake the secret code
>> <okpv8r$4f3$1...@dont-email.me> thusly:
>>
>>> On 20/07/17 04:36, Richard wrote:
>>>> ja...@jacob.remcomp.fr spake the secret code
>>>> <okn6ro$uug$1...@dont-email.me> thusly:
>>>>> There is not a single thread of evidence that C code is "unmaintainable"
>>>>> any more than C++ code is. C is readable, C++ is NOT.
>>>>
>>>> This is a straw man. I never said this.
>>>
>>> Fine. But it's partly true anyway. A more accurate rendition would be:
>>>
>>> Some C is readable. Some is not.
>>>
>>> Some C++ is readable. Some is not.
>>
>> A tautology is a thing that is tautological.
>>
>> You can make similar statements for any language.
>
> Quite so. In other words, Jacob's claim was without merit, despite
> being partly true.
>
>> Saying this isn't adding anything to the conversation, however.
>
> The conversation, too, is without merit. Language wars are
> pointless.

Wars are, but conversations are not. I would hope that c.l.c still has
enough reasonable posters that discussion of C in the context of other
programming languages could produce some insights. Obviously it will
produce a lot of rubbish as well, but that will be true of almost any
topic.

> Everybody has likes and dislikes, and what attracts some
> people to a language will repel others from it. That's /why/ we have
> different languages.

This is not a reasonable position. It makes language choice appear to
be largely a matter of taste, and suggests that the panoply of languages
available today simply reflects this diversity. I'm having a hard time
believing that that is what you wanted to say.

The technical merits and capabilities of programming languages have had
far more impact than taste. And social and economic forces are all too
often forgotten. C is successful, in part, because Unix was written in
it and hundreds of CS departments had small machines running Unix.
Algol 68 failed because it was too complex to implement. Initially on
all machines but then particularly on small ones just as they became
more and more important. K&R (the book) helped C enormously. There was
nothing like it for Algol 68 (partly because implementations were slow
to become available).

Quite apart from these, professional programmers must overcome their
likes and dislikes. I disliked FORTRAN in 1978 but what else are you
going to use to solve large systems of differential equations when the
NAG library is sitting there ready to use?

In the case of the core issue of the thread -- writing safe, correct
code -- I don't believe that anyone considers the language chosen to be
irrelevant. The question is whether there is anything that can be done
to make matters better. Whatever it is will have to be a long-term
strategy because there is a lot of social inertia in programming. There
is also a lot of unavoidable technical inertia. Many bugs have been
added to otherwise correct C code during the normal software life-cycle
and using another language is simply not an option is these cases.

In the sort term, the best solutions may be social -- improving the
dynamics of programming groups, more technical code reviews and so on.

<snip>

--
Ben.

[Richard Heathfield]

On 20/07/17 21:45, Ben Bacarisse wrote:
> Richard Heathfield <r...@cpax.org.uk> writes:

<snip>

>> The conversation, too, is without merit. Language wars are
>> pointless.
>
> Wars are, but conversations are not.

Indeed. But this conversation more or less started out as a war.

> I would hope that c.l.c still has
> enough reasonable posters that discussion of C in the context of other
> programming languages could produce some insights. Obviously it will
> produce a lot of rubbish as well, but that will be true of almost any
> topic.

No argument there.

>> Everybody has likes and dislikes, and what attracts some
>> people to a language will repel others from it. That's /why/ we have
>> different languages.
>
> This is not a reasonable position. It makes language choice appear to
> be largely a matter of taste, and suggests that the panoply of languages
> available today simply reflects this diversity. I'm having a hard time
> believing that that is what you wanted to say.

I think it's a big factor. Of course I don't think it's the /only/
factor, or even necessarily the biggest, but it's very significant.
People wouldn't design new languages (except, perhaps, for fun or the
experience of doing it) unless they thought that by doing so they could
improve on the flaws of existing languages. (If an existing language has
no flaws, why not use that?) And what constitutes a flaw is often a
matter of taste. For example, we have seen in this very discussion that
some people object to function-like macros, which were deliberately
designed to be function-like, presumably because the designers thought
this to be a good quality.

[Daniel]

On Tuesday, July 18, 2017 at 1:34:48 PM UTC-4, Lynn McGuire wrote:
> "Death to C, ++"
> https://techcrunch.com/2017/07/16/death-to-c/
>
C++ is the only language I can recall that some very smart people have
described as an abomination, notably on comp.lang.functional. But while
comp.lang.functional is largely defunct, this one is still going.

Some day in the future we'll have more languages with more coherent, less
vexed, abstractions than C++, but in the meantime it may not be worth
anyone's time to produce a stop gap to C++ where other languages still won't
do.

Daniel

[Chris M. Thomasson]

On 7/18/2017 10:34 AM, Lynn McGuire wrote:
> "Death to C, ++"
> https://techcrunch.com/2017/07/16/death-to-c/
>

> "The C programming language is terrible. I mean, magnificent, too. Much
> of the world in which we live was built atop C. It is foundational to
> almost all computer programming, both historically and practically;
> there’s a reason that the curriculum for Xavier Niel’s revolutionary
> “42” schools begins with students learning how to rewrite standard C
> library functions from scratch. But C is no longer suitable for this
> world which C has built."

>
> I disagree. True, working in C and C++ is like walking on a tight rope.
> But, if one cannot walk the tightrope then one should find something
> else to do in life. After all, working on the high wire is not for
> everyone.

The Joint Strike Fighter:

http://www.stroustrup.com/JSF-AV-rules.pdf

C++, oh yeah! :^)

[Ian Collins]

The lack of a response certainly backs that up!

--
Ian

[Öö Tiib]

On Friday, 21 July 2017 01:00:43 UTC+3, Daniel wrote:
> On Tuesday, July 18, 2017 at 1:34:48 PM UTC-4, Lynn McGuire wrote:
> > "Death to C, ++"
> > https://techcrunch.com/2017/07/16/death-to-c/
> >
> C++ is the only language I can recall that some very smart people have
> described as an abomination, notably on comp.lang.functional. But while
> comp.lang.functional is largely defunct, this one is still going.

It may be matters nothing. Over times I have heard "abomination" said
by smart people about other most popular programming languages at that
time as well. These were COBOL, PL/I, Perl, Visual Basic, PHP and
lately Javascript.

C++ has also been popular to bash. I don't know why. People who don't want
to use C++ don't need to use it.

> Some day in the future we'll have more languages with more coherent, less
> vexed, abstractions than C++, but in the meantime it may not be worth
> anyone's time to produce a stop gap to C++ where other languages still won't
> do.

We have large pile of programming languages. Soon likely more than alive
human languages.

[Daniel]

On Thursday, July 20, 2017 at 1:07:55 AM UTC-4, gwowen wrote:
>
> he has literally no interest in anything that challenges how he has
> already made his mind up.

Of course, that's not unique to that poster :-)

[Richard]

[Please do not mail me a copy of your followup]

Ben Bacarisse <ben.u...@bsb.me.uk> spake the secret code
<87bmoe7...@bsb.me.uk> thusly:

>In the case of the core issue of the thread -- writing safe, correct
>code -- I don't believe that anyone considers the language chosen to be
>irrelevant.

While I don't consider the language irrelevant, I've found that
practicing test-driven development has done more to help me product
safe, correct code than the choice of any particular language.

Between C and C++, my preference for C++ comes from the "zero overhead
abstraction" facilities more than anything else that differs between
the two languages.

One of the earliest open source contributions I ever made was an Xt
widget for hosting a PEX 3D viewport. You can find it under PEXt in
this contrib tarball on the x.org site:
<https://www.x.org/releases/X11R5/contrib-2.tar.Z>

Learning Xt and learning the internals of the X Window System server
were very instructive in teaching me OO design principles, even though
it was all implemented by hand in C. The server code has a mechanism
for doing derive-and-override in C using function pointers. The
server has good abstractions around various resources: bitmaps, fonts,
graphics contexts, windows, etc., to allow for extension to those
basic items as well as customization by a vendor server.

It's all quite nice and is a good example of how you can write good
code in C. But man, it really imposes lots of personal discipline and
it's easy to get things wrong in the boilerplate. It's simply much
more productive to have the compiler do the boiler-plate for you
instead of managing polymorphic function pointers yourself.

>In the sort term, the best solutions may be social -- improving the
>dynamics of programming groups, more technical code reviews and so on.

This is why I do plenty of coaching on TDD. It's not a testing
activity, it is a design activity. Testing just comes for free.
Desirable design qualities (SOLID principles, DRY, etc.) fall out
naturally instead of having to impose personal discipline to achieve
them.

[Daniel]

On Thursday, July 20, 2017 at 6:48:08 PM UTC-4, Öö Tiib wrote:
>
> Over times I have heard "abomination" said
> by smart people about other most popular programming languages at that
> time as well. These were COBOL, PL/I, Perl, Visual Basic, PHP and
> lately Javascript.
>
> C++ has also been popular to bash. I don't know why.

All of the aforementioned languages can be regarded as legacy. Everybody hates legacy. In fact, the only redeeming thing about legacy is that it
works.

Daniel

[Chris Vine]

On Thu, 20 Jul 2017 22:53:11 +0000 (UTC)
legaliz...@mail.xmission.com (Richard) wrote:
[snip]

> Between C and C++, my preference for C++ comes from the "zero overhead
> abstraction" facilities more than anything else that differs between
> the two languages.

The original poster posted to both comp.lang.c and comp.lang.c++,
presumably as troll bait, as it is more of less guaranteed to start yet
another useless C v C++ debate. You have repeated your cross-posted
view on that particular issue in this thread I think around 4 times now.

Very little useful further debate is going to emerge from it.

[Öö Tiib]

How? There were 2 legacy languages (COBOL and PL/I) 2 bit younger than C++
(Perl and Visual Basic) and 2 quite modern and popular programming
languages (PHP and JavaScript).

[Daniel]

On Thursday, July 20, 2017 at 8:00:20 PM UTC-4, Öö Tiib wrote:
> On Friday, 21 July 2017 02:06:38 UTC+3, Daniel wrote:
> >
> > All of the aforementioned languages can be regarded as legacy.
>

> How? There were 2 legacy languages (COBOL and PL/I) 2 bit younger than C++
> (Perl and Visual Basic) and 2 quite modern and popular programming
> languages (PHP and JavaScript).

We thought of COBOL as legacy when I started programming in the mid eighties, that gave it what, 25 years? JavaScript has been around almost that many years :-)

[Jerry Stuckle]

There are many more than 2 legacy languages - FORTRAN, RPG, ALGOL and
IBM Assembler for a start. Plus many you've probably never heard of
such as SNOBOL, MVS's JCL, REXX (about as old as C), EXEC and EXEC2
(another IBM language).


--
==================
Remove the "x" from my email address
Jerry Stuckle
jstu...@attglobal.net
==================

[Daniel]

On Thursday, July 20, 2017 at 10:44:45 PM UTC-4, Jerry Stuckle wrote:
>
> There are many more than 2 legacy languages - FORTRAN, RPG, ALGOL and
> IBM Assembler for a start. Plus many you've probably never heard of
> such as SNOBOL, MVS's JCL, REXX (about as old as C), EXEC and EXEC2
> (another IBM language).
>

My first language was BASIC, with two letter variable names, my second was
FORTRAN 66, with six. I only used JCL in school, but it gave me nightmares. I've heard of all the others you mentioned, except EXEC and EXEC2. ALGOL was
nice.

Daniel

[Daniel]

On Thursday, July 20, 2017 at 10:44:45 PM UTC-4, Jerry Stuckle wrote:

> EXEC and EXEC2 (another IBM language).
>

IBM's names for programming languages were great: APL (A Programming
Language), PL1 (Programming Language #1), and now I learn EXEC and EXEC2.
I once heard that someone had copyrighted the names PL2 ... PL10, anticipating
a run on them in the future, but it never happened.

Daniel

[Paavo Helde]

On 21.07.2017 1:04, Chris M. Thomasson wrote:
>
> The Joint Strike Fighter:
>
> http://www.stroustrup.com/JSF-AV-rules.pdf
>
> C++, oh yeah! :^)

These guidelines are not for those weak in the heart!

- Allocation/deallocation from/to the free store (heap) shall not
occur after initialization (rationale: defragmentation causing
unpredictable delays).

- C++ exceptions shall not be used (rationale: tool support not adequate).

- The basic types of int, short, long, float and double shall not be used.

- Pointer arithmetic will not be used.

- Unsigned arithmetic shall not be used.

etc.

[David Brown]

On 19/07/17 01:28, Melzzzzz wrote:
> On 2017-07-18, jacobnavia <ja...@jacob.remcomp.fr> wrote:
>> Le 18/07/2017 à 19:40, Melzzzzz a écrit :
>>> Rust is pain. That language is worst nightmare I had misfortune to program in.
>>> Inability to implement doubly linked list
>>
>> You can see an implementation of a double linked list here:
>>
>> http://bluss.github.io/ixlist/target/doc/ixlist/struct.List.html
>>
>> A double linked list has 2 indices into an array of elements.
>>
>> A correct implementation would allow you to grow the array as you index
>> it, an index bigger than 1 of the last elements implies an extension of
>> the array, using memory as the list grows.
>>
>> What is a pointer?
>>
>> It is an index into an array of addressable bits, consecutively. Modern
>> CPUs offer virtual memory, where the OS gives you a huge adressable
>> space. Underlying the virtual memory is the real memory, that could have
>> some GB in most machines.
>>
> Heh, never thought to implement it like that ;)
> What about tree ? ;)

I have no experience with Rust, but long ago I had need for trees and
lists in Basic with no pointers. I had an array that was large enough
for everything that was needed, and indices into the array took the
place of pointers. I can't remember how I did the memory management.
If it is possible in Basic, it is surely possible in Rust!


> In my experience in Rust you use raw pointers for everything that wrap
> it up in "safe" code ;)
>

[woodb...@gmail.com]

On Friday, July 21, 2017 at 7:33:01 AM UTC-5, Paavo Helde wrote:
> On 21.07.2017 1:04, Chris M. Thomasson wrote:
> >
> > The Joint Strike Fighter:
> >
> > http://www.stroustrup.com/JSF-AV-rules.pdf
> >
> > C++, oh yeah! :^)
>
> These guidelines are not for those weak in the heart!
>
> - Allocation/deallocation from/to the free store (heap) shall not
> occur after initialization (rationale: defragmentation causing
> unpredictable delays).

This is a pretty good one if you can follow the spirit of it,
but still have a few heap allocations.

>
> - C++ exceptions shall not be used (rationale: tool support not adequate).
>
> - The basic types of int, short, long, float and double shall not be used.
>
> - Pointer arithmetic will not be used.
>
> - Unsigned arithmetic shall not be used.

I could live with this one also.


Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net

[Jorgen Grahn]

["Followup-To:" header set to comp.lang.c.]
On Wed, 2017-07-19, jacobnavia wrote:

> Le 19/07/2017 à 05:20, Richard a écrit :
>> Meh. Glancing through the article, the author seems to conflate C
>> with C++. Every time a programmer in another language tells me how
>> horribly unmaintainable C++ code is based on some experience in their
>> company, I ask them to show me the code. The code is invariably C
>> code (or C++ written in C code style).
>
> Thanks for repeating the mantra of all incompetent C++ programmers:
>
> C is bad.
>

> Yeah.

That's not what he wrote. For the record, he also wrote:

> > It is possible to write maintainable, secure, testable, etc., code
> > in C. It is easier in C++ to achieve those goals than it is in C
> > IMO.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Bo Persson]

On 2017-07-22 04:10, woodb...@gmail.com wrote:
> On Friday, July 21, 2017 at 7:33:01 AM UTC-5, Paavo Helde wrote:
>> On 21.07.2017 1:04, Chris M. Thomasson wrote:
>>>
>>> The Joint Strike Fighter:
>>>
>>> http://www.stroustrup.com/JSF-AV-rules.pdf
>>>
>>> C++, oh yeah! :^)
>>
>> These guidelines are not for those weak in the heart!
>>
>> - Allocation/deallocation from/to the free store (heap) shall not
>> occur after initialization (rationale: defragmentation causing
>> unpredictable delays).
>
> This is a pretty good one if you can follow the spirit of it,
> but still have a few heap allocations.

I have seen a similar approach to this:

Use pooled memory managers, then for each program module calculate the
theoretical maximum number of allocations for each block size. Sum up
the numbers and then install that amount or RAM. Meaning huge amounts!

Seems like the military can afford that kind of systems, while we mere
mortals will not.


Bo Persson

[Öö Tiib]

Some things die more young than others. Until there are new commercial
projects started that write (at least part of) codebase in Lisp or in
Fortran these are not legacy programming languages.

[Jens Stuckelberger]

On Tue, 18 Jul 2017 12:34:25 -0500, Lynn McGuire wrote:

> "Death to C, ++"
> https://techcrunch.com/2017/07/16/death-to-c/

The opening salvo for a language war. Cool. Let's enjoy watching
people getting entangled in endless arguments that will solve absolutely
nothing. Well, at least they will be good for some mental masturbation.

[GOTHIER Nathan]

On Tue, 18 Jul 2017 12:34:25 -0500
Lynn McGuire <lynnmc...@gmail.com> wrote:

> "Death to C, ++"
> https://techcrunch.com/2017/07/16/death-to-c/
>

> "The C programming language is terrible. I mean, magnificent, too. Much
> of the world in which we live was built atop C. It is foundational to
> almost all computer programming, both historically and practically;
> there’s a reason that the curriculum for Xavier Niel’s revolutionary
> “42” schools begins with students learning how to rewrite standard C
> library functions from scratch. But C is no longer suitable for this
> world which C has built."

WTF Xavier Niel has coded in his life? Who does really care about his fake
school "42"? IIRC he started business in the "minitel rose" providing sexually
advertised chat services.

[Richard]

[Please do not mail me a copy of your followup]

Jens Stuckelberger <Jens_Stuc...@nowhere.net> spake the secret code
<ol3cpc$oqd$1...@news.albasani.net> thusly:

It's also good clickbait for developers.

[Richard]

[Please do not mail me a copy of your followup]

GOTHIER Nathan <nathan....@gmail.com> spake the secret code
<20170724020425.e78a...@gmail.com> thusly:

>WTF Xavier Niel has coded in his life? Who does really care about his fake
>school "42"? IIRC he started business in the "minitel rose" providing sexually
>advertised chat services.

OK, this is making me laugh because I'm old enough to have experienced
minitel when it was the sexting outlet of its day. LOL!

[SG]

On Tuesday, July 18, 2017 at 7:34:48 PM UTC+2, Lynn McGuire wrote:
> "Death to C, ++"
> https://techcrunch.com/2017/07/16/death-to-c/
>

> "The C programming language is terrible. I mean, magnificent, too. Much
> of the world in which we live was built atop C. It is foundational to
> almost all computer programming, both historically and practically;
> there’s a reason that the curriculum for Xavier Niel’s revolutionary
> “42” schools begins with students learning how to rewrite standard C
> library functions from scratch. But C is no longer suitable for this
> world which C has built."
>

> I disagree. True, working in C and C++ is like walking on a tight rope.
> But, if one cannot walk the tightrope then one should find something
> else to do in life. After all, working on the high wire is not for
> everyone.

Hmm, that analogy makes me wonder. Generally one assumes that safety
comes with other downsides. Sticking with that analogy, a bridge would
be a safer way to cross a canyon than a tight rope. But you might not
be able to afford building one (higher cost = higher runtime or memory
overhead).

The analogy of bridge vs tight rope does kind of fit for languages
that protect you better than C and C++ but intrinsically incur costs
due to design choices. It's not a secret that programs in interpreted
languages or even statically compiled languages such as Java are at a
disadvantage compared to C++ since they make it difficult to avoid
pointer-heavy data structes. Every variable in Python is a reference.
Every variable of a non-primitive type in Java is a reference.
Composing an object out of subobjects in Java doesn't give you a
single chunk of memory but a tree of objects linked by those kinds of
references. The cost is bad memory layout and potential cache misses.
In addition you usually have a garbage or cycle collector of some sort
which does have its own trade-offs.

But I don't think this analogy of a bridge fits with respect to Rust.
Rust would be like a tight rope that's safer than a normal tight rope
but still as cheap (or almost as cheap) as the normal one. Even if you
are good at walking on a tight rope and only very rarely loose your
balance by accident, why wouldn't you pick the safer one unless you
don't value your life? That's the whole point about Rust's existence!

* fearless concurrency
* memory safety without garbage collection
* zero-overhead abstractions

Frankly, I don't understand the opposition. I've programmed in C and
C++ for over 10 years. Yes, I care about performance. That's why I
switched to C++. And yes, I care about the three things I listed
above. C++ got that "zero-overhead principle" down. But its story
w.r.t. memory safety and data race freedom is lacking. Sure, there are
efforts in C++ (static checking for guideline adherence) but to be
honest, I'm not holding my breath. I start believing Stroustrup and
Herb Sutter when I get ahold of a working static analyzer and
annotated standard library that prevents use-after-free errors at
compile-time. Yes, effective use of C++ makes leaking resources by
accident pretty hard. That's cool. Thank you RAII. But we still deal
with things like references, non-owning pointers, iterators etc that
might be invalidated earlier than expected—even in "modern C++".
Sure, you could replace some of that with a std::weak_ptr that is
smart enough to figure out if the pointee is gone. But that's IMHO an
undesirable performance regression. Wouldn't it be cool if the
compiler could verify for you that non-owning pointers are never
going to be invalid if the program actually compiles?

So, before you dismiss Rust based on preconceived notions along the
lines of "higher overhead" or "not close enough to the metal", you
should probably stop and consider taking a closer look at Rust.

No, I don't buy into the idea that only incompetent programmers make
mistates. That's just nonsense.

my two cents,

SG

[Mr Flibble]

On 02/08/2017 14:27, SG wrote:

> Every variable of a non-primitive type in Java is a reference.

Pointer not reference.

/Flibble

[SG]

Not sure if you're trolling or not. In computer science terms, a
pointer *is* a kind of reference. The term reference is more general.

[Daniel]

On Wednesday, August 2, 2017 at 12:14:54 PM UTC-4, Mr Flibble wrote:
>
> Pointer not reference.
>
As Winston Churchill might have said, "Young man, that is the sort of
nonsense to which I must refer."

Daniel

[Jerry Stuckle]

It is a reference. Java does not have pointers.

[Alf P. Steinbach]

On 03.08.2017 20:14, Jerry Stuckle wrote:
> On 8/2/2017 12:14 PM, Mr Flibble wrote:
>> On 02/08/2017 14:27, SG wrote:
>>
>>> Every variable of a non-primitive type in Java is a reference.
>>
>> Pointer not reference.
>>
>> /Flibble
>
> It is a reference. Java does not have pointers.

The Java language specification uses both terms.

Incompetent Java programmers, of which there is an abundance, use only
“reference”, and have the idiotic idea that Java does not have pointers.
They will argue that ad nauseam. I think not primarily because they're
unfamiliar with the specification of their chosen main programming
language (although there's that too, that they're incompetents) but
because they're /conformists/ at heart, and the group has decided on an
alternative reality, just like any religious or other conformists group.


Cheers! & hth.,

- Alf

[Mr Flibble]

Nonsense?

java.lang.NullPointerException

(A reference( value) is a pointer [JLS8, 4.3.1].)

Now GTFO.

/Flibble

[Jerry Stuckle]

Then please show how to define a pointer to an object in Java. And if
it is truly a pointer, show how you can use those pointers to do things
like step through an array by incrementing and decrementing them.

Also - just where in the Java documentation does it say it has pointers?

[Richard]

[Please do not mail me a copy of your followup]

SG <s.ges...@gmail.com> spake the secret code
<03695385-9478-491c...@googlegroups.com> thusly:

I thought it was just standard Java terminology: primitive types and
reference types.

[woodb...@gmail.com]

A good example of a thoughtful religious guy is Ben Shapiro.
And if you think he's simply a G-dly, intelligent, articulate
young man, you would be mistaken. He's also a great musician --
check out his tribute to Game of Thrones.

https://duckduckgo.com/?q=game+of+thrones+tribute+dailywire&atb=v72-1__&ia=
videos&iax=1&iai=WoSvVDQJGv4


Brian
Ebenezer Enterprises
http://webEbenezer.net

[David Brown]

On 03/08/17 21:22, Jerry Stuckle wrote:
> On 8/3/2017 2:25 PM, Alf P. Steinbach wrote:
>> On 03.08.2017 20:14, Jerry Stuckle wrote:
>>> On 8/2/2017 12:14 PM, Mr Flibble wrote:
>>>> On 02/08/2017 14:27, SG wrote:
>>>>
>>>>> Every variable of a non-primitive type in Java is a reference.
>>>>
>>>> Pointer not reference.
>>>>
>>>> /Flibble
>>>
>>> It is a reference. Java does not have pointers.
>>
>> The Java language specification uses both terms.
>>
>> Incompetent Java programmers, of which there is an abundance, use only
>> “reference”, and have the idiotic idea that Java does not have pointers.
>> They will argue that ad nauseam. I think not primarily because they're
>> unfamiliar with the specification of their chosen main programming
>> language (although there's that too, that they're incompetents) but
>> because they're /conformists/ at heart, and the group has decided on an
>> alternative reality, just like any religious or other conformists group.
>>
>>
>> Cheers! & hth.,
>>
>> - Alf
>
> Then please show how to define a pointer to an object in Java. And if
> it is truly a pointer, show how you can use those pointers to do things
> like step through an array by incrementing and decrementing them.

I don't know Java at all, but I would not say that the ability to
/change/ a pointer or use it to step through an array is an essential
quality of a pointer.

In C or C++, if you have:

int x;
int *p = &x;

Then "p" is a pointer. You can use it to access the value of "x"
through indirection. But you cannot increment it, decrement it, or step
through an array by changing it. Well, you /can/ increment or decrement
"p" - but dereferencing it would be undefined behaviour.

[Öö Tiib]

In Java all variables of Object type (or derived types) are pointers.

Object someObj = null;
// there are no objects pointed at by someObj
someObj = new ArrayList<String>();
// now there is object pointed at by someObj
someObj = SomeOtherClass();
// now some other object is pointed at by it
someObj = null;
// again nothing

Since almost all things are Object in Java that leaves only variables
of few fundamental types that are not pointers (and so can be
used without that constant 'new' spam of Java):

int a = '1';
char b = (char) a;

[Jerry Stuckle]

The Java documentation calls these references. And that's what they are
- they must always point at an object or null. You can't, for instance,
set someObj an address.

[Mr Flibble]

Of course you can set someObj to an address: the address of a new'd
object. Just because pointers in Java aren't the same as pointers in
C/C++ it doesn't mean they aren't pointers.

It's java.lang.NullPointerException not java.lang.NullReferenceException.

Java uses pointers; deal with it.

/Flibble