Wednesday, September 9, 2020

Digest for comp.lang.c++@googlegroups.com - 19 updates in 7 topics

olcott <NoOne@NoWhere.com>: Sep 09 11:45AM -0500

For all "c" programmers to get the maximum benfit from c++ with the
least learning curve cost you only need to learn three things about c++
(1) C++ classes
(2) std::vector
(3) std::string
 
I spoke with someone on the comp.lang.c recently about the benefits of
c++. Her objections was that c++ has a huge learning curve.
 
I have been a "c" programmer since K&R was the official standard and
only learned those very few things about c++ that make programming much
easier. In two decades as a c++ programmer I don't hardly use anything
else besides those three things.
 
I learned about c++ classes, std::vector and std::string, that is the
tiny subset of c++ that makes "c" programming much easier. I have
continued to use the stdio.h I/O library of "c" in all my c++ programs.
I just started calling this library <cstdio> by its c++ name.
 
C++ classes implement the key most important and useful aspect of Object
Oriented Programming (OOP). I have never found any other aspect of OOP
useful.
 
C++ classes are just "c" structs having their own member functions that
operate only on this data. Code and data can be kept together in the
same place eliminating the possibility of data dependency side-effects.
With OOP you can create self-contained units of modularity. This is ht e
greatest thing about c++ and OOP.
 
With std::vector you can have an array of anything that totally handles
all of its own memory management that can be kept in a tiny little
pointer in a stack (local) variable. You can use normal "c" substripts
to access elements.
 
The array always knows its current size: size() and you can append
another element with memory management automatically handled for you
with push_back(). The allocation algorithm is an optimal balance between
time and space can be easily superseded with resize() or reserve().
 
std::string is a string of characters that can grow as large as needed
and has the same interface as std::vector. The above three things is all
the c++ that "c" programmer ever needs to know.
 
--
Copyright 2020 Pete Olcott
Bonita Montero <Bonita.Montero@gmail.com>: Sep 09 06:54PM +0200

> another element with memory management automatically handled for you
> with push_back(). The allocation algorithm is an optimal balance between
> time and space can be easily superseded with resize() or reserve().
 
If you're talking about std::array - its size can't be changed.
olcott <NoOne@NoWhere.com>: Sep 09 12:06PM -0500

On 9/9/2020 11:54 AM, Bonita Montero wrote:
>> between time and space can be easily superseded with resize() or
>> reserve().
 
> If you're talking about std::array - its size can't be changed.
 
I am referring back to std::vector as a type of array, I am using terms
that "c" programmers know and mapping these terms to the most useful c++
equivalent.
 
 
--
Copyright 2020 Pete Olcott
James Kuyper <jameskuyper@alumni.caltech.edu>: Sep 09 10:08AM -0700

On Wednesday, September 9, 2020 at 12:54:58 PM UTC-4, Bonita Montero wrote:
 
[missing attribution restored:]
> > with push_back(). The allocation algorithm is an optimal balance between
> > time and space can be easily superseded with resize() or reserve().
 
> If you're talking about std::array - its size can't be changed.
 
The paragraph you quoted was immediately preceded by this one:
 
> > all of its own memory management that can be kept in a tiny little
> > pointer in a stack (local) variable. You can use normal "c" substripts
> > to access elements.
 
Which makes it quite clear that the array he was talking about in the
paragraph you quoted is the array managed by std::vector, which has a
size that quite definitely can change. Note, in particular, that he's
fairly careful about prefixing standard library identifiers with
"std::", so it was clear that the array he was talking about was not
std::array<>. Other clues that this is the case are his mentions of
push_back(), resize(), and reserve(), none of which are members of
std::array<>, but they are members of std::vector<>.
olcott <NoOne@NoWhere.com>: Sep 09 12:26PM -0500

On 9/9/2020 12:08 PM, James Kuyper wrote:
> std::array<>. Other clues that this is the case are his mentions of
> push_back(), resize(), and reserve(), none of which are members of
> std::array<>, but they are members of std::vector<>.
 
It was a good idea to make it even clearer though so I updated it.
The std::vector array always knows its current size...
 
 
--
Copyright 2020 Pete Olcott
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Sep 09 10:46AM -0700

olcott <NoOne@NoWhere.com> writes:
[...]
> It was a good idea to make it even clearer though so I updated it.
> The std::vector array always knows its current size...
 
You can't really update a Usenet post. What you did was post a
new version of it, with no visible indication of what had changed.
If you want to clarify something from a previous post, I suggest
posting a followup quoting the post and adding interspersed notes
as needed.
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
olcott <NoOne@NoWhere.com>: Sep 09 01:14PM -0500

On 9/9/2020 12:46 PM, Keith Thompson wrote:
> If you want to clarify something from a previous post, I suggest
> posting a followup quoting the post and adding interspersed notes
> as needed.
 
For cases like this one you are right.
I use the other new version convention when the discussion involves
hundreds of revisions that totally supersede and replace everything said
before.
 
--
Copyright 2020 Pete Olcott
wyniijj@gmail.com: Sep 09 01:25PM -0700

olcott於 2020年9月10日星期四 UTC+8上午12時45分34秒寫道：
> the c++ that "c" programmer ever needs to know.
 
> --
> Copyright 2020 Pete Olcott
 
C++ is just combination of tricks, magic show, like all UTM's are
essentially the same. You can build your own C++ program without using "std::"
like I do (C++ may try to make this statement false). That said, GUI and thread
programing using C is a nightmare.
For learning c++, those fundamental ones (before c++11) should be sufficient
enough for most programmers.
olcott <NoOne@NoWhere.com>: Sep 09 03:37PM -0500

> programing using C is a nightmare.
> For learning c++, those fundamental ones (before c++11) should be sufficient
> enough for most programmers.
 
Before I found std::vector I utterly shunned all dynamic memory
allocation as a huge source of "make the system crash" errors.
 
Now that I have been programming in c++ for a couple of decades I never
use its destructors or "new". I always simply have a local stack
variable store the address of a std::vector on the stack. I never need
"new", I merely invoke the constructor of the object directly inside
push_back().
 
I even met Bjarne Stroustrup when he came to Omaha many years ago to
promote his new language: c++. He is a tee-shirt and blue jeans kind of
guy.
 
--
Copyright 2020 Pete Olcott
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 09 10:09PM +0100

On 09/09/2020 21:37, olcott wrote:
>> enough for most programmers.
 
> Before I found std::vector I utterly shunned all dynamic memory allocation as a huge source of "make the system crash" errors.
 
> Now that I have been programming in c++ for a couple of decades I never use its destructors or "new". I always simply have a local stack variable store the address of a std::vector on the stack. I never need "new", I merely invoke the constructor of the object directly inside push_back().
 
We are not really interested in how you use C++ inappropriately. I suggest you lean how to use MODERN C++.
 
/Flibble
 
--
¬
olcott <NoOne@NoWhere.com>: Sep 09 04:18PM -0500

On 9/9/2020 4:09 PM, Mr Flibble wrote:
 
> We are not really interested in how you use C++ inappropriately. I
> suggest you lean how to use MODERN C++.
 
> /Flibble
 
I created this thread because one of the respondents of these two groups
said that they would never bother to learn c++ because of the learning
curve of its enormous complexity. I am pointing out that "c" programmers
can get 90% of the benefit of c++ for 2% of the learning curve cost.
 
Using just the three aspects of c++ that I mentioned would make "c"
programs at least 500% more maintainable than their "c" counter parts.
 
Because "c" is a subset of c++, "c" programs can be gradually migrated
to the subset of c++ that I specified.
 
--
Copyright 2020 Pete Olcott
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 09 02:09PM -0700

On 9/9/2020 12:51 AM, David Brown wrote:
> user interfaces are blinking LED's and push-buttons, rather than guis on
> a PC. But I can see it being useful to many others, and maybe it will
> be useful to me too in the future.)
[...]
 
Simulating the blinking LED's and push buttons might be useful? The GUI
user interface can look just like the device. Think of a GUI for a
device in 3d. You can spin it around... Hook up cords, test the lights,
push buttons... Would that kind of be useful to you?
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 09 02:14PM -0700

On 9/9/2020 2:09 PM, Chris M. Thomasson wrote:
> user interface can look just like the device. Think of a GUI for a
> device in 3d. You can spin it around... Hook up cords, test the lights,
> push buttons... Would that kind of be useful to you?
 
Basically, you can simulate it... Get it working, then upload the
program to the device, and test again. Do something on the device, and
do the same thing in the simulator. Compare notes...
Richard Damon <Richard@Damon-Family.org>: Sep 09 01:30PM -0400

On 9/9/20 10:37 AM, Christian Hanné wrote:
>> system call into the kernel and much of the overhead of a task switch to
>> EVERY method call, and return.
 
> Security always rules over performance.
 
If you are using this sort of 'access rule' for 'security', you have
already lost. Access rules are to limit what the PROGRAMMER needs to
think about, so makes things easier for them.
 
It is designed to help block mistakes, not determined attacks.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Sep 09 08:04PM

On Wed, 2020-09-09, James Kuyper wrote:
>> But as I see you're a person that easily offers security for nothing.
 
> Those comments display as little knowledge about me as they do about
> security.
 
Scott Newman again, surely.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
olcott <NoOne@NoWhere.com>: Sep 09 01:10PM -0500

Would meeting this spec refute all the halting problem proofs:
I (will soon) have an x86 partial halt decider sufficiently equivalent
to the Linz H correctly deciding halting on the Linz Ĥ thus proving the
H/Ĥ template does not prevent a correct halting decision.
 
The Linz H is defined on page 318 and the Linz Ĥ is defined on page 319:
http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
 
I wrote a "c" program that is translated into x86 machine language that
is executed on an x86 emulator that has been adapted to be equivalent to
a universal Turing machine for all computations not requiring more
memory than is available.
 
These are the only x86utm operating system functions provided:
 
// Saves the state of the current virtual-machine
void SaveState(u32* s);
 
// Loads the state of a saved virtual-machine
void LoadState(u32* s);
 
// Allocates memory from the heap
u32* Allocate(u32 size);
 
// The master machine executes the slave machine
void DebugStep(u32* master_state, u32* slave_state);
 
 
 
The solution will be provided as:
(a) The "c" source code of the whole halt deciding system.
 
(b) The x86 machine language generated by the "c" compiler disassembled
to x86 assembly language for the whole halt deciding system.
 
(c) A repository link to the whole x86utm system as open source.
 
(d) The full x86 assembly language execution trace of a partial halt
decider sufficiently equivalent to H correctly deciding halting on the
adaptation of itself specified by the Linz Ĥ template.
 
This assembly language execution trace will be augmented by "c" function
names for every function call. All values returned by any function are
placed in the EAX register.
 
 
 
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company.
 
--
Copyright 2020 Pete Olcott
olcott <NoOne@NoWhere.com>: Sep 09 12:08PM -0500

For all "c" programmers to get the maximum benfit from c++ with the
least learning curve cost you only need to learn three things about c++
(1) C++ classes
(2) std::vector
(3) std::string
 
I spoke with someone on the comp.lang.c recently about the benefits of
c++. Her objections was that c++ has a huge learning curve.
 
I have been a "c" programmer since K&R was the official standard and
only learned those very few things about c++ that make programming much
easier. In two decades as a c++ programmer I don't hardly use anything
else besides those three things.
 
I learned about c++ classes, std::vector and std::string, that is the
tiny subset of c++ that makes "c" programming much easier. I have
continued to use the stdio.h I/O library of "c" in all my c++ programs.
I just started calling this library <cstdio> by its c++ name.
 
C++ classes implement the key most important and useful aspect of Object
Oriented Programming (OOP). I have never found any other aspect of OOP
useful.
 
C++ classes are just "c" structs having their own member functions that
operate only on this data. Code and data can be kept together in the
same place eliminating the possibility of data dependency side-effects.
With OOP you can create self-contained units of modularity. This is ht e
greatest thing about c++ and OOP.
 
With std::vector you can have an array of anything that totally handles
all of its own memory management that can be kept in a tiny little
pointer in a stack (local) variable. You can use normal "c" subscripts
to access elements.
 
The std::vector array always knows its current size: size() and you can
append another element with memory management automatically handled for
you with push_back(). The allocation algorithm is an optimal balance
between time and space can be easily superseded with resize() or reserve().
 
std::string is a string of characters that can grow as large as needed
and has the same interface as std::vector. The above three things is all
the c++ that "c" programmer ever needs to know.
 
--
Copyright 2020 Pete Olcott
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 09 05:51PM +0100

I absolutely cannot wait to see Stellan Skarsgård's turn as Baron Vladimir Harkonnen in Dune (2020). https://www.youtube.com/watch?v=PFyhkabcwBY
 
"I consider the notion of God absurd and that if a real God were actually so vain as to constantly demand worship, then he would not be worthy of it." -- Stellan Skarsgård
 
--
¬
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 09 05:29PM +0100

https://www.youtube.com/watch?v=PFyhkabcwBY Pink Floyd Joy <3
 
--
¬
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)