Why should a "c" programmer learn c++ ? (V2)

[olcott]

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

[olcott]

On 9/9/2020 8:36 PM, Thiago Adams wrote:

> On Wednesday, September 9, 2020 at 2:09:11 PM UTC-3, olcott wrote:
>> 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
>>

> To use these features correctly you also need to understand and use
> Exceptions, namespaces and templates and a LOT more, like move semantics
>

To use those features as simply augmentations to "c" thus increasing the
quality and maintainability of what would otherwise be "c" code you need
none of those things.

There are many great "c" programmers that could easily become great c++
programmers if they were not burdened by inessential details.

One week of skimming these three essentials in one's spare time and any
"C" programmer could become a c++ programmer. The most important thing
to know is C++ classes.

[Ben Bacarisse]

olcott <No...@NoWhere.com> writes:

> There are many great "c" programmers that could easily become great
> c++ programmers if they were not burdened by inessential details.
>
> One week of skimming these three essentials in one's spare time and
> any "C" programmer could become a c++ programmer. The most important
> thing to know is C++ classes.

Why does "C" get the scare quotes and C++ doesn't?

--
Ben.

[olcott]

A "c" by itself looks like it may be a typo.

[Öö Tiib]

It is common typo, as the language is named C not c.

[David Brown]

Try spelling it correctly - the language is called C, with a capital.
(C++ also has a capital.) When posting in a C newsgroup, or even a C++
newsgroup, people will not misinterpret it. If you are writing about it
in a different newsgroup or context where it might not be obvious what
you mean, then referring to "the C programming language" is far better
than "c". You may also like to refer to the particular version of the
standards - C99, C11, etc.


As to your original point, it is certainly possible for people to write
in a language that is basically "C with simple classes", and some people
find that gives them clearer and more maintainable code than they get
with C alone due to better structuring and encapsulation. I think that
is missing out a lot of the potential benefits of C++, and it certainly
will not lead to someone becoming a "great C++ programmer". There is no
doubt that the C++ language is big, and few if any programmers have need
for all the features. But the subset that gives the most benefits
varies enormously from programmer to programmer and task to task.

[bol...@nuttyella.co.uk]

On Thu, 10 Sep 2020 01:04:31 -0500
olcott <No...@NoWhere.com> wrote:
>Copyright 2020 Pete Olcott

Why do you put a copyright in your posts? Firstly they're not copyrightable as
usenet is in the public domain and secondly who do you think is going to rip
off your tedious waffle anyway?

[Anton Shepelev]

boltar to Pete Olcott:

> Why do you put a copyright in your posts? Firstly they're

> not copyrightable as usenet is in the public domain [...]

You are confusing content and medium. Any content is in
principle copyrightable regardless of the medium that
contains it.

--
() ascii ribbon campaign - against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]

[bol...@nuttyella.co.uk]

On Thu, 10 Sep 2020 12:59:30 +0300
Anton Shepelev <anton.txt@g{oogle}mail.com> wrote:
>boltar to Pete Olcott:
>
>> Why do you put a copyright in your posts? Firstly they're
>> not copyrightable as usenet is in the public domain [...]
>
>You are confusing content and medium. Any content is in
>principle copyrightable regardless of the medium that
>contains it.

Wrong. All usenet providers will have a public domain clause in their terms
and conditions because thats how usenet has worked since its inception.

[Juha Nieminen]

Citation needed.

I don't think a platform has the legal right to tell to its users
"if you publish anything in this platform, it will be in the public domain",
especially since most jurisdictions do not even support the concept of
individuals publishing anything with no copyright. A company cannot remove
copyright from a work (not its own, not other people's).

(Yes, even if you say "this work of mine is in the Public Domain", in most
jurisdictions that means jack squat. It will still be copyrighted, and
"public domain" is not a valid legally-binding usage license. In these
jurisdictions ever original work is automatically copyrighted and you cannot
get rid of it, no matter what you do. It's copyrighted, period. The only
thing you can do is to publish it under a copyright-based usage license
that gives everybody the freedom to do with it whatever they want.)

A company can claim that by publishing on their platform you automatically
*transfer* your copyright to the company. How legally binding that is
depends, but it's still *not* "public domain". It's simply a copyright
transferral. A company cannot legally declare your work to be PD,
because that's not how copyright law works.

(Publishing under PD is recognized by most jurisdictions, but restricted
to many/most publications made by the government and certain government
sub-contractors. In most jurisdictions individuals and private
companies do not have this "right". Their work is automatically and
irrevocably copyrighted.)

[David Brown]

On 10/09/2020 11:59, Anton Shepelev wrote:
> boltar to Pete Olcott:
>
>> Why do you put a copyright in your posts? Firstly they're
>> not copyrightable as usenet is in the public domain [...]
>
> You are confusing content and medium. Any content is in
> principle copyrightable regardless of the medium that
> contains it.
>

In fact, whatever you write on Usenet (and most other places) is
implicitly copyrighted by you, unless there is some prior claim or
explicit transfer of copyrights. It is certainly not "public domain"
unless you say so explicitly.

(At least, that is my understanding - IANAL.)

So the real question is, why bother putting a copyright message on the
post when it is already covered automatically? If someone feels that
their messages are being abused - copied and used in different contexts,
quoted by someone who does not follow the expected conventions, etc., -
then perhaps it's easier to get legal help if the copyright is marked
explicitly. But hopefully that is not something that is going to be a
likely issue here!

[Richard Damon]

Yes, everything you produce, if classifiable as a creative work, is
automatically under copyright protection, but some of those protections
are easier to enforce if an explicit claim is made. On the other hand,
because of the media being used, there are a lot of implied grants of
use, and just asserting the automatic copyright won't change those.

[Anton Shepelev]

boltar to Anton Shepelev:

> > You are confusing content and medium. Any content is in
> > principle copyrightable regardless of the medium that
> > contains it.
>
> Wrong. All usenet providers will have a public domain
> clause in their terms and conditions because thats how
> usenet has worked since its inception.

And again, you do not say with regard to what content public
domain is mentioend in the terms & conditions of Usenet
provider. In fact, I don't think it is mentioned at all.
Can you quote, for example, the relevant part of the terms
of two popular Usenet servers? --

Eternal September: www.eternal-september.org
AIOE: www.aioe.org

[bol...@nuttyella.co.uk]

On Thu, 10 Sep 2020 14:08:02 +0200
David Brown <david...@hesbynett.no> wrote:
>On 10/09/2020 11:59, Anton Shepelev wrote:
>> boltar to Pete Olcott:
>>
>>> Why do you put a copyright in your posts? Firstly they're
>>> not copyrightable as usenet is in the public domain [...]
>>
>> You are confusing content and medium. Any content is in
>> principle copyrightable regardless of the medium that
>> contains it.
>>
>
>In fact, whatever you write on Usenet (and most other places) is
>implicitly copyrighted by you, unless there is some prior claim or
>explicit transfer of copyrights. It is certainly not "public domain"
>unless you say so explicitly.

If all usenet posts were copyright to their author then including those posts
in further posts would be technically illegal withoug getting permission
from the author first. Though it probably varies by country. It would be same
as claiming a telephone conversation was copyright.

[olcott]

C with classes is very much better than C without classes (if done
properly) and because it provides such a great benefit at such a low
learning curve cost could get many C programmers to start C++.

[Bonita Montero]

> A "c" by itself looks like it may be a typo.

From here I thought this threads ends in pure idiocracy.
As I read the first follow-ups I got the confirmation.

[Ben Bacarisse]

David Brown <david...@hesbynett.no> writes:

> So the real question is, why bother putting a copyright message on the
> post when it is already covered automatically?

It's just one of the things such people do. What they write is so Very
Important that it needs to be marked as special in some way. It's been
that way since before the Internet boom. I refer you to "What To Do
When the Trisector Comes" by Underwood Dudley.

--
Ben.

[Lew Pitcher]

On Thu, 10 Sep 2020 16:01:08 +0100, Ben Bacarisse wrote:

> "What To Do When the Trisector Comes" by Underwood Dudley

What a wonderful essay; I loved it.


Thanks, Ben.
--
Lew Pitcher
"In Skills, We Trust"

[olcott]

Because much of what I say is brand new material that no one has ever
said before my copyright notice establishes first use.

[olcott]

On 9/10/2020 5:22 AM, bol...@nuttyella.co.uk wrote:

This doesn't seem to be true and if it was true it doesn't seem to be
legal. It would seem that for it to be legal I would had to have been
notified and agree.

[Bonita Montero]

Am 10.09.2020 um 11:59 schrieb Anton Shepelev:

> () ascii ribbon campaign - against html e-mail
> /\http://preview.tinyurl.com/qcy6mjc [archived]

www.asciiribbon.org is an example of how ugly even rudimentary HTML
could look like. Now imagine this would be ASCII. This is why I prefer
HTML in certain E-Mail-types like newsletters; it's just magnitutes
more convenient to read.

[Anton Shepelev]

boltar:

> If all usenet posts were copyright to their author then
> including those posts in further posts would be
> technically illegal withoug getting permission from the
> author first.

Since anything posted to Usenet becomes available to
everybody to free, copying a post with a proper attribution
cannot violate the author's copyright. You cannot make the
content any more available than it already is, contrary to
books, movies, music, or any digital content that is not
made universally available by its author.

--

[olcott]

On 9/10/2020 12:23 PM, Anton Shepelev wrote:
> boltar:
>
>> If all usenet posts were copyright to their author then
>> including those posts in further posts would be
>> technically illegal withoug getting permission from the
>> author first.
>
> Since anything posted to Usenet becomes available to
> everybody to free, copying a post with a proper attribution
> cannot violate the author's copyright.

I do this so that my original work will have proper attribution.

> You cannot make the
> content any more available than it already is, contrary to
> books, movies, music, or any digital content that is not
> made universally available by its author.
>


--

Copyright 2020 Pete Olcott

[David Brown]

As has been noted by others, by posting on Usenet you can be assumed
implicitly to be granting certain rights of usage of the post. (This is
in addition to standard "fair use" of copyrighted material, which
includes allowing quotations for various purposes.) That includes
copying the post between newsservers, making it available publicly,
including in archives, and allowing other posters the right to quote the
post when replying according to common Usenet conventions. I don't know
of any place that these might be found written down, except perhaps if
they are discussed in an RFC on Usenet.

This is all getting way off-topic in these groups. I suggest you look
it up if you are interested - it should not be hard to find references.

[Juha Nieminen]

In comp.lang.c++ David Brown <david...@hesbynett.no> wrote:
> It is certainly not "public domain" unless you say so explicitly.

It's not "public domain" even if you say so. Most jurisdictions
do not recognize it as a valid form of publication. You have
copyright to your work whether you want it or not.

[Juha Nieminen]

In comp.lang.c++ bol...@nuttyella.co.uk wrote:
> If all usenet posts were copyright to their author then including those posts
> in further posts would be technically illegal withoug getting permission
> from the author first.

No, because fair use statutes step in.

[Kaz Kylheku]

On 2020-09-10, bol...@nuttyella.co.uk <bol...@nuttyella.co.uk> wrote:
> On Thu, 10 Sep 2020 01:04:31 -0500
> olcott <No...@NoWhere.com> wrote:
>>Copyright 2020 Pete Olcott
>
> Why do you put a copyright in your posts? Firstly they're not
> copyrightable as usenet is in the public domain and secondly who do

That is simply not true. The exact laws vary from country to country,
but there is no general principle by which an expressive work passes
automatically into the public domain, even if it is broadcast by the
author.

Even a statement like "this work is assigned into the public domain" is
not necessarily valid, and if the work carries no other statement, then
it might not be considered properly licensed for anyone to redistribute.

Peter Olcott's copyright header is in fact valid.

> you think is going to rip off your tedious waffle anyway?

Agreed.

[David Brown]

That varies from place to place. In some countries, stating that the
post is in public domain is enough (assuming you owned the copyright to
start with) - in others, "public domain" is only possible when the
copyright time has run out. I don't know which viewpoint is held by
"most" countries. In any country following the Berne Convention - which
is most of them - any creative work is automatically copyrighted by the
author or by whoever paid the author to make the work. So my point was
primarily that things you write are not public domain if you have not
said so explicitly - but you are absolutely right that sometimes they
won't be public domain even if you /do/ say they are.

[Chris Vine]

On Thu, 10 Sep 2020 22:49:40 +0200
David Brown <david...@hesbynett.no> wrote:
> On 10/09/2020 20:59, Juha Nieminen wrote:
> > In comp.lang.c++ David Brown <david...@hesbynett.no> wrote:
> >> It is certainly not "public domain" unless you say so explicitly.
> >
> > It's not "public domain" even if you say so. Most jurisdictions
> > do not recognize it as a valid form of publication. You have
> > copyright to your work whether you want it or not.
> >
>
> That varies from place to place. In some countries, stating that the
> post is in public domain is enough (assuming you owned the copyright to
> start with) - in others, "public domain" is only possible when the
> copyright time has run out. I don't know which viewpoint is held by
> "most" countries. In any country following the Berne Convention - which
> is most of them - any creative work is automatically copyrighted by the
> author or by whoever paid the author to make the work.

I don't think the Berne Convention has the effect you mention in
relation to "whoever paid the author to make the work" - the position
on that as far as the Convention is concerned is I believe optional. I
happen to know that a well drawn contract which provides for the
production of a copyrightable work such as software for payment must
provide explicitly for the copyright in the work to transfer to the
payer, otherwise the payer has a right of use for the purposes for
which the software was written but not the ownership of it.

It is some time ago since I needed to know this kind of thing but there
was a case in the UK involving an architect producing plans for a
development and the developer wanted to sell them on for another similar
development. The architect required further payment before allowing
them to be used for that purpose, in that the contract did not provide
for transfer of copyrights, so the developer only had an implied
licence to use their drawings and designs for the purposes of building
out the development and not for other purposes. You can probably
google the case online as it was a well-known "gotcha" that I had to be
aware of.

[Richard Damon]

On 9/10/20 1:23 PM, Anton Shepelev wrote:
> boltar:
>
>> If all usenet posts were copyright to their author then
>> including those posts in further posts would be
>> technically illegal withoug getting permission from the
>> author first.
>
> Since anything posted to Usenet becomes available to
> everybody to free, copying a post with a proper attribution
> cannot violate the author's copyright. You cannot make the
> content any more available than it already is, contrary to
> books, movies, music, or any digital content that is not
> made universally available by its author.
>

That is clearly false. Anything shown of broadcast TV was freely
available to anyone with a TV, and if you used a cheap VCR you could
easily have recorded the program. No essential difference.

That broadcast is clearly under copyright, and if it was something like
a Disney movie, and you started selling copies of it, watch how fast you
get sued (and you will lose).

Same for everything on the web not under a paywall, anyone can go to it,
but it is protected by copyright.

Freely available isn't the same as free of copyright.

Having posted to Usenet, you have given implied permission for the
network to do the things that networks do and readers can do things that
they normally do, so transfer around Usenet, quote for a reply.

What you can't do (probably, depending on things like far use) would be
make something like a book out of things said.

[Juha Nieminen]

In comp.lang.c++ David Brown <david...@hesbynett.no> wrote:
> On 10/09/2020 20:59, Juha Nieminen wrote:
>> In comp.lang.c++ David Brown <david...@hesbynett.no> wrote:
>>> It is certainly not "public domain" unless you say so explicitly.
>>
>> It's not "public domain" even if you say so. Most jurisdictions
>> do not recognize it as a valid form of publication. You have
>> copyright to your work whether you want it or not.
>
> That varies from place to place. In some countries, stating that the
> post is in public domain is enough (assuming you owned the copyright to
> start with) - in others, "public domain" is only possible when the
> copyright time has run out. I don't know which viewpoint is held by
> "most" countries.

I think there's a lot of confusion about what it means, legally speaking,
when an author declares his work to be "public domain". Most of this
confusion sparks from the fact that many people don't understand what
"public domain" means, or how copyright law works (in most countries).

"Public domain" means "has no copyright". It's not a usage license. It
does not mean "I give you permission to do with this work of mine
whatever you want". It would mean, if the law supported the concept,
"this work is not copyrighted".

Many people think that one can simply declare his own work to "not be
copyrighted" and that makes it so. Maybe that was the case in the 60's
or so, when works had to be explicitly registered as copyrighted, but
in most jurisdictions that hasn't been the case in like 40 or so years.
In most jurisdictions copyright is automatic and, moreover, there is
no mechanism by which you can get rid of it and toss the work into the
public domain.

That being said, it's very probable that no court will judge in your
favor if you publish something under "public domain" and then try to
sue someone for copyright infringement: Yes, you still own the
copyright to your work, and no, "public domain" is not a valid usage
license, but most courts will probably read intent, the spirit of
the law, rather than the letter of it, and judge against you. Courts
will probably judge that by saying "this is in the public domain" you
implicitly gave permission for people to use it, and trying to sue
them afterwards would be akin go fraud.

Anyway, if you want to publish your work with a very free usage license,
it's safest to use one of the existing copyright-based licenses (like
the Creative Commons ones). This makes it clearest from a legal
perspective.

[Öö Tiib]

On Friday, 11 September 2020 10:38:35 UTC+3, Juha Nieminen wrote:
>
> Anyway, if you want to publish your work with a very free usage license,
> it's safest to use one of the existing copyright-based licenses (like
> the Creative Commons ones). This makes it clearest from a legal
> perspective.

That is obviously rather tedious to write every time we post some
code snippet for to illustrate our (doomed to be ambiguous) words
that it is licensed under Creative Commons.

I don't think it is needed. Our attempt to sue someone with such
snippet would maximally result with sued party stopping usage
of verbatim equivalent of said snippet. I suspect that real courts
would support our copyright claims only if someone second used
equivalent to that particular snippet to sue ourselves or some
third party with incorrect copyright claim.

[David Brown]

On 11/09/2020 09:38, Juha Nieminen wrote:
> In comp.lang.c++ David Brown <david...@hesbynett.no> wrote:
>> On 10/09/2020 20:59, Juha Nieminen wrote:
>>> In comp.lang.c++ David Brown <david...@hesbynett.no> wrote:
>>>> It is certainly not "public domain" unless you say so explicitly.
>>>
>>> It's not "public domain" even if you say so. Most jurisdictions
>>> do not recognize it as a valid form of publication. You have
>>> copyright to your work whether you want it or not.
>>
>> That varies from place to place. In some countries, stating that the
>> post is in public domain is enough (assuming you owned the copyright to
>> start with) - in others, "public domain" is only possible when the
>> copyright time has run out. I don't know which viewpoint is held by
>> "most" countries.
>
> I think there's a lot of confusion about what it means, legally speaking,
> when an author declares his work to be "public domain". Most of this
> confusion sparks from the fact that many people don't understand what
> "public domain" means, or how copyright law works (in most countries).
>

Agreed.

> "Public domain" means "has no copyright". It's not a usage license.

Yes.

> It
> does not mean "I give you permission to do with this work of mine
> whatever you want". It would mean, if the law supported the concept,
> "this work is not copyrighted".
>

AFAIK all countries support the idea of public domain - there is always
a time limit on copyright. The actual limit varies - a typical limit is
"death of the author plus 50 years". After that time limit, the work
falls into public domain. So Shakespeare's works are all public domain
in all countries. Particular renderings of the text can still be
copyrighted - you can't buy a Complete Shakespeare, scan the pages, and
publish it as your own. But you /can/ copy out the text into your PC,
print it out yourself and publish it. (That's what Project Gutenberg
has done.)

(The USA has had a series of "Mickey Mouse" laws - any time the
copyright on Mickey Mouse is nearing its end, they raise the limit.)


What varies significantly between countries is whether you can make
something "public domain" /before/ the copyright runs out. Some
countries let you do this, others do not.

> Many people think that one can simply declare his own work to "not be
> copyrighted" and that makes it so. Maybe that was the case in the 60's
> or so, when works had to be explicitly registered as copyrighted, but
> in most jurisdictions that hasn't been the case in like 40 or so years.

The Berne convention is from the 19'th century, and under that you never
need an explicit copyright notice for work to be copyrighted. (Though
it is typically vastly easier to prove and enforce copyright if there is
an explicit notice.) The USA, as I understand it, used to be different
and required explicit copyright notices - otherwise the work was
automatically public domain. This was an exception from the Berne
convention. But they changed to follow the convention in 1989. Some
other countries have had varying degrees to which they implement the
convention in their laws.

> In most jurisdictions copyright is automatic and, moreover, there is
> no mechanism by which you can get rid of it and toss the work into the
> public domain.

With the proviso that I don't know if "most" is accurate or it should be
"some jurisdictions", this is almost correct. Copyrighted work becomes
public domain automatically after a given time. (Assuming we don't find
a way to live forever, and assuming the Mickey Mouse laws eventually
stop - or at least other countries stop following the USA.)

>
> That being said, it's very probable that no court will judge in your
> favor if you publish something under "public domain" and then try to
> sue someone for copyright infringement: Yes, you still own the
> copyright to your work, and no, "public domain" is not a valid usage
> license, but most courts will probably read intent, the spirit of
> the law, rather than the letter of it, and judge against you. Courts
> will probably judge that by saying "this is in the public domain" you
> implicitly gave permission for people to use it, and trying to sue
> them afterwards would be akin go fraud.

This will also vary from jurisdiction to jurisdiction - some legal
systems put more favour on the letter of the law, some emphasise the
wording of the author's statements, others pay more attention to the
authors presumed intentions. It's also going to be heavily influenced
by the lawyers involved. (Writing your intentions clearly is usually a
good idea, however.)

>
> Anyway, if you want to publish your work with a very free usage license,
> it's safest to use one of the existing copyright-based licenses (like
> the Creative Commons ones). This makes it clearest from a legal
> perspective.
>

Agreed - it makes a lot of sense to copy existing practice from groups
that have had /real/ lawyers from many countries look at the issues, and
copy practices from the Creative Commons folk, the GPL licensing and
copyright notices, or perhaps the NoSQL project if you want to make some
software "public domain".

[Juha Nieminen]

Just don't do what the SQLite project does: They essentially punish you if
you live in a jurisdiction that doesn't recognize "public domain" as a
valid license and you want to do things by the book.

Their official license is "public domain" (ignoring the fact that it isn't
a license), and for reasons known to nobody they seemingly refuse to offer
the software under any other open source license.

If, however, you live in a jurisdiction that doesn't support the ability
of individuals to publish work in the public domain, and you want to do
things by the book, they generously offer to sell you a legally-binding
individual license for the meager price of US$6000.

This is not just me saying it, or reading between the lines or interpreting.
This is explicitly stated by them. They say that they will sell you a legal
license (for US$6000) if: "You are using SQLite in a jurisdiction that does
not recognize the right of an author to dedicate their work to the public
domain."

Why they can't offer you the software eg. using the MIT or BSD license,
or any other such license, is a completely mystery. Essentially they are
punishing you for living in the wrong jurisdiction and wanting to do the
legally right thing.

[Öö Tiib]

Perhaps by their (unsaid out) philosophy traders in such jurisdiction
deserve to be taxed for the laws (or maybe even whole existence) of
that jurisdiction. Indeed ... whom else to tax for unfair trademark,
copyright and/or patent laws but traders? Said taxing process however
is trouble and for it to be profitable they ask for sum that SQLite
is anyway well worth of in my experience.

[anti...@math.uni.wroc.pl]

In comp.lang.c David Brown <david...@hesbynett.no> wrote:
>
> AFAIK all countries support the idea of public domain - there is always
> a time limit on copyright. The actual limit varies - a typical limit is
> "death of the author plus 50 years". After that time limit, the work
> falls into public domain.

In Poland once copyright expires work effectively goes to state.
One is supposed to pay a fee for use of such works. There is
state agency for collecting fees and there is official rate,
something like few percent of price. I do not know if anybody
actually pays and if they have rules what to do with derived
works. But certainly this is a big legal landmine for anybody
who thinks in terms of "public domain".

--
Waldek Hebisch

[Richard Damon]

One issue is that to provide a license under MIT or BSD, they would need
to assert their rights under copyright to give such a license, which
might impede their ability to disclaim that right in the other
jurisdictions.

They might want to look at the CC0 license, which I think deals with
these sorts of issues, but not being a lawyer or knowing all their
thought, they may have reasons not to want or be able to use it.

[Anton Shepelev]

Juha Nieminen:

> Just don't do what the SQLite project does: They
> essentially punish you if you live in a jurisdiction that
> doesn't recognize "public domain" as a valid license and
> you want to do things by the book.

It makes no sense to me. No one may deny me the right to
give away a creative work of mine to the whole world under
no conditions, restrictions, or limitations. No one may
force me to put any limitations on the usage by others of my
creative work.

> Their official license is "public domain" (ignoring the
> fact that it isn't a license), and for reasons known to
> nobody they seemingly refuse to offer the software under
> any other open source license.

Perhaps they should consider a license equivalent to public
domain:

https://en.wikipedia.org/wiki/Public-domain-equivalent_license

[Anton Shepelev]

Richard Damon to Anton Shepelev:

> > Since anything posted to Usenet becomes available to
> > everybody to free, copying a post with a proper
> > attribution cannot violate the author's copyright. You
> > cannot make the content any more available than it
> > already is, contrary to books, movies, music, or any
> > digital content that is not made universally available
> > by its author.
>
> That is clearly false. Anything shown of broadcast TV was
> freely available to anyone with a TV, and if you used a
> cheap VCR you could easily have recorded the program. No
> essential difference.

The essential difference from the TV is that a TV broadcast
is temporal: it is available only at a specific time.
Recording it on a persistent medium for later re-
broadcasting, or distribution surely makes it more available
than it was.

> Freely available isn't the same as free of copyright.

Yes. My idea about copyring is that it is partly about
one's right to increase the availability of a creative work,
you cannot increase the availability of a Usenet post,
except the way Google does by maintaing an archive of it so
that it remains available after it has expired from all
Usenet servers. You can, however, increase the availability
of a printed book, a music record publiched on CD, or an
article retained behind a paywall.

> Having posted to Usenet, you have given implied permission
> for the network to do the things that networks do and
> readers can do things that they normally do, so transfer
> around Usenet, quote for a reply.
>
> What you can't do (probably, depending on things like far
> use) would be make something like a book out of things
> said.

What is the essential difference from the quoting with a
proper attribution of a single Usenet post, entire, on a
personal web page? Can one be sued for that?

[Juha Nieminen]

Öö Tiib <oot...@hot.ee> wrote:
>> Why they can't offer you the software eg. using the MIT or BSD license,
>> or any other such license, is a completely mystery. Essentially they are
>> punishing you for living in the wrong jurisdiction and wanting to do the
>> legally right thing.
>
> Perhaps by their (unsaid out) philosophy traders in such jurisdiction
> deserve to be taxed for the laws (or maybe even whole existence) of
> that jurisdiction. Indeed ... whom else to tax for unfair trademark,
> copyright and/or patent laws but traders? Said taxing process however
> is trouble and for it to be profitable they ask for sum that SQLite
> is anyway well worth of in my experience.

If they have a problem with countries/jurisdictions where you cannot
publish works into the public domain, why do they want to punish the
people living in those places who have done nothing wrong? It's not
their fault.

[Juha Nieminen]

In comp.lang.c++ Anton Shepelev <anton.txt@g{oogle}mail.com> wrote:
>> Just don't do what the SQLite project does: They
>> essentially punish you if you live in a jurisdiction that
>> doesn't recognize "public domain" as a valid license and
>> you want to do things by the book.
>
> It makes no sense to me. No one may deny me the right to
> give away a creative work of mine to the whole world under
> no conditions, restrictions, or limitations. No one may
> force me to put any limitations on the usage by others of my
> creative work.

You can publish your work under a (legally-binding) license that
imposes no restrictions, limitations or requirements. It's just
that it has to be copyright-based in order to be recognized in
many countries in the modern world. It's just a formality, really.

[James Kuyper]

On 9/11/20 9:16 AM, Anton Shepelev wrote:
> Juha Nieminen:
>
>> Just don't do what the SQLite project does: They
>> essentially punish you if you live in a jurisdiction that
>> doesn't recognize "public domain" as a valid license and
>> you want to do things by the book.
> It makes no sense to me. No one may deny me the right to
> give away a creative work of mine to the whole world under
> no conditions, restrictions, or limitations. No one may
> force me to put any limitations on the usage by others of my
> creative work.

You've got it backwards. The problem is that no one can safely take
advantage of the fact that you've released your creative work, because
(in those jurisdictions which don't recognize "public domain") you're
always free to change your mind and enforce your copyright.

[Eli the Bearded]

In comp.lang.c, Juha Nieminen <nos...@thanks.invalid> wrote:
> Why they can't offer you the software eg. using the MIT or BSD license,
> or any other such license, is a completely mystery. Essentially they are
> punishing you for living in the wrong jurisdiction and wanting to do the
> legally right thing.

They are giving people in those areas a US$6000 incentive to lobby for
law changes.

I don't know about them, but I know when I'm wearing my public software
development hat, I really don't want to think hard about international
laws and their implication on my choice of license.

Elijah
------
has never contributed anything as widely useful as sqlite

[Joe Pfeiffer]

Ben Bacarisse <ben.u...@bsb.me.uk> writes:

> David Brown <david...@hesbynett.no> writes:
>
>> So the real question is, why bother putting a copyright message on the
>> post when it is already covered automatically?
>
> It's just one of the things such people do. What they write is so Very
> Important that it needs to be marked as special in some way. It's been
> that way since before the Internet boom. I refer you to "What To Do
> When the Trisector Comes" by Underwood Dudley.

I hadn't come across that little article before. Thanks, it was fun.

[Juha Nieminen]

In comp.lang.c++ Eli the Bearded <*@eli.users.panix.com> wrote:
> In comp.lang.c, Juha Nieminen <nos...@thanks.invalid> wrote:
>> Why they can't offer you the software eg. using the MIT or BSD license,
>> or any other such license, is a completely mystery. Essentially they are
>> punishing you for living in the wrong jurisdiction and wanting to do the
>> legally right thing.
>
> They are giving people in those areas a US$6000 incentive to lobby for
> law changes.

Punishing people who have done nothing wrong is not the right way to go.

The only thing that it causes is for people to "pirate" the software,
technically speaking, under the assumption that the sqlite team will
never sue them.

[Öö Tiib]

As there are no monarchs whom to punish. The laws are what people made
these to be.

[David Brown]

Yes, indeed. Sometimes small gems come out of even the most useless
threads!

[Anton Shepelev]

olcott:

> 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.

It is inevitable for such a multi-paradigm moster of a
language. One need only compare the relative thickness of
books describing C and C++. There is a fundamental argument
for the simplicity of a language. It appeals to the
universal criterium of perfection, which is also the basis
of the unviverse, -- the supremacy of the whole over the sum
of its parts. A complex system is beautiful when built with
a small number of simle building blocks and ugly when built
with a large nubmer of building blocks of which some are
more complex than the system itself.

> I have been a "c" programmer since K&R was the official
> standard ->

You had better had been C programmer. A "c" programmer reads
like a disparaging parody on the former term.

> -> 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.

A approve of this approach, if one must use C++ at all. I
myself program in C#, but employ a very limited set of its
features. As far as I know, C++ began as a light-weight
preprocessing wrapper around plain C that added one thing
only: classes. It therefore did not even have a dedicated
compliler, relying on existing C compilers, and wasn't that
convenient? I can understnand why that language was called
C++ -- a small addition to C. Now it something else.

This feature-ascetism, however, has the downside that other
programmers will have their own opinions about which
features are useful, and will make fun of you for using 1%
instead of, say, 4% of C++. That may be a problem if you
work in a team. A colleague of mine told me a horror story
about his friend who did not pass an interview for a C++
programming job because he employed normal iteration instead
of some funcional-based and query-like facility where it was
obviously not needed. The employer wanted an over-engineered
solution the easier to adapt it to hypothetical new
requirements in the hypothetical future.

> 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.

What other aspects are there? Well, I have never found any
aspect of OOP useful, anyway. Heavy use of classes dictates
a totally different program structure. While they are not
very difficult to understand, the way of thinking required
to design good object-oriented software is radically
different and takes a long time to acquire, if at all.

But if one must have OOP, one need not append ++ to C. Axel-
Tobias Schreiner describes an OO-framework for plain C in
his book "Object-oriented programming in C":

https://www.cs.rit.edu/~ats/books/ooc.pdf

> 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.

I consider this a fault rather than advantage: data and
operations belong in different domains and shall not be
mixed. This is so fundamental a principle that Niclaus Wirth
put it in the title of his book:

Algorithhms + Data structures = Programs

> With OOP you can create self-contained units of
> modularity. This is ht e greatest thing about c++ and OOP.

It is ironical that a C++ programmer should talk about
modularity. Header files are a parody of modules. Whereas
true modules have been added to C++ no so long ago, they had
been available way before OOP in such langugages as ALGOL
and Modula.

> 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().

C can do abstract dynamic arrays with exponential memory
allocation that are transparent and substitutable for normal
C arrays. I have implemented such dymamic arrays as a C
"module", with the help of several members of CLC. The
example below creates a dymamic array, adds elelements to it
in three different ways, and prints the contents:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "dynarray.h"
/* ... */
int *a, v, i, l; /* arrary, value, index, length */
void* vP; /* poiter to array value */

da_new ( &a, sizeof( int ) ); /* create new array */

da_setlen( &a, 2 ); /* set a length of 2 */
a[0] = 0;
a[1] = 1;

da_setlen( &a, 4 ); /* set a length of 4 */
a[2] = 2;
a[3] = 3;

v = 4;
da_add( &a, &v ); /* add element with value */

v = 5;
da_addemp( &a, &vP ); /* add an empty element and */
memcpy( vP, &v, sizeof( int ) ); /* fill it */

l = da_len( &a ); /* read the length */
for( i = 0; i < l; i++ )
{ printf("%i ", a[i]); }

da_free( &a );

Observe that my dynamic arrays are declared as normal C
arrays, and their elements are read and assigned to exactly
as if they were a normal C arrays. Error handling is
omitted for simplicity, but pray do not mentioned
exceptions.

> The allocation algorithm is an optimal balance between
> time and space can be easily superseded with resize() or
> reserve().

Interesting. Is it a grow-only or grow-and-shrink algorithm?
Can you delineate it for me if will not take more that three
paragraphs, or refer me to a description? In my dynamic
arrays, the da_setlen() function performes the office of
reserve(): in addition to setting the exact length, it makes
sure that enough memory is allocated.

> std::string is a string of characters that can grow as
> large as needed and has the same interface as std::vector.

The lack of a string type is a deficiency in C, but one can
be implemented, for example on top of my dynamic arrays. I
will not take the banana of std::string if the entire jungle
of C++ has to come with it.

--
() ascii ribbon campaign -- against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]

[olcott]

Inhertance.

> aspect of OOP useful, anyway. Heavy use of classes dictates
> a totally different program structure. While they are not
> very difficult to understand, the way of thinking required
> to design good object-oriented software is radically
> different and takes a long time to acquire, if at all.
>

It was very natural for me.
We just added containment to top down design.

> But if one must have OOP, one need not append ++ to C. Axel-
> Tobias Schreiner describes an OO-framework for plain C in
> his book "Object-oriented programming in C":
>
> https://www.cs.rit.edu/~ats/books/ooc.pdf
>
>> 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.
>
> I consider this a fault rather than advantage: data and
> operations belong in different domains and shall not be
> mixed. This is so fundamental a principle that Niclaus Wirth
> put it in the title of his book:
>

Without containment we have side-effects.

> Algorithhms + Data structures = Programs
>
>> With OOP you can create self-contained units of
>> modularity. This is ht e greatest thing about c++ and OOP.
>
> It is ironical that a C++ programmer should talk about
> modularity. Header files are a parody of modules. Whereas
> true modules have been added to C++ no so long ago, they had
> been available way before OOP in such langugages as ALGOL
> and Modula.
>

I just wrote a whole COFF object file library as a single header file.

>> 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().
>
> C can do abstract dynamic arrays with exponential memory
> allocation that are transparent and substitutable for normal
> C arrays. I have implemented such dymamic arrays as a C
> "module", with the help of several members of CLC. The
> example below creates a dymamic array, adds elelements to it
> in three different ways, and prints the contents:
>

Without templates its clumsier to create an array of anything.

It enlarges the memory allocation by a factor of 1.5 to 2.0 and copies
all the elements whenever totally memory is used up. It does this
automatically on std::vector::push_back();

Or you can allocate enough memory in advance with reserve() or resize().
With resize you can just use it like an array with subscripts. If you
index out-of-bounds it crashes.

With reserve() adding an element requires push_back() yet it is much
faster because the memory is already allocated. You use
std::vector::size() to always know the current boundary.

> Can you delineate it for me if will not take more that three
> paragraphs, or refer me to a description? In my dynamic
> arrays, the da_setlen() function performes the office of
> reserve(): in addition to setting the exact length, it makes
> sure that enough memory is allocated.
>
>> std::string is a string of characters that can grow as
>> large as needed and has the same interface as std::vector.
>
> The lack of a string type is a deficiency in C, but one can
> be implemented, for example on top of my dynamic arrays. I
> will not take the banana of std::string if the entire jungle
> of C++ has to come with it.
>

I have hardly every used any aspect of C++ (in my own code) besides the
above three things in two decades as a C++ programmer. std::vector is
the only way I ever use dynamically allocated memory.

--
Copyright 2020 Pete Olcott

[Anton Shepelev]

olcott to Anton Shepelev:

> > > 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.
> >
> > What other aspects are there?
>

> Inhertance.

I thought classes had inheritance by definition; they would
not be classes otherwise. So you use classes with methods
but without inheritcance? -- interesting.

> > > 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.
> >
> > I consider this a fault rather than advantage: data and
> > operations belong in different domains and shall not be
> > mixed. This is so fundamental a principle that Niclaus
> > Wirth put it in the title of his book:
>
> Without containment we have side-effects.

I beg pardon for overlooking your mention of side effects
the first time. I don't understand what side effects are
inevitable in procedural programming that classes help to
avoid.

Speaking of modules and modularity:

> I just wrote a whole COFF object file library as a single
> header file.

Is it not an abuse of headers? Can it be considered modular
design if the header is simply pasted into code by the macro
processor, has no separation of interface and
implementation, and cannot be compiled separattely?

> Without templates its clumsier to create an array of
> anything.

You surely mean a dynamic array. In my previous post I have
shown how a universal dynamic array can be implemented in C.

About the memory management in std:vector:

> It enlarges the memory allocation by a factor of 1.5 to
> 2.0 and copies all the elements whenever totally memory is
> used up. It does this automatically on
> std::vector::push_back();

So do my C dynamic arrays, although the factor is constant.

> Or you can allocate enough memory in advance with
> reserve() or resize(). With resize you can just use it
> like an array with subscripts. If you index out-of-bounds
> it crashes.

So do my C dynamic arrays, where you can set capacity and
actual length.

> With reserve() adding an element requires push_back() yet
> it is much faster because the memory is already allocated.
> You use std::vector::size() to always know the current
> boundary.

It is very simlar with my dynamic arrays in C.

> std::vector is the only way I ever use dynamically
> allocated memory.

Indeed. Anything else is hardly needed for most
applications.

[olcott]

On 9/12/2020 9:50 AM, Anton Shepelev wrote:
> olcott to Anton Shepelev:
>
>>>> 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.
>>>
>>> What other aspects are there?
>>
>> Inhertance.
>
> I thought classes had inheritance by definition; they would
> not be classes otherwise. So you use classes with methods
> but without inheritcance? -- interesting.
>

http://wiki.c2.com/?InheritanceBreaksEncapsulation

>>>> 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.
>>>
>>> I consider this a fault rather than advantage: data and
>>> operations belong in different domains and shall not be
>>> mixed. This is so fundamental a principle that Niclaus
>>> Wirth put it in the title of his book:
>>
>> Without containment we have side-effects.
>
> I beg pardon for overlooking your mention of side effects
> the first time. I don't understand what side effects are
> inevitable in procedural programming that classes help to
> avoid.
>

If every function depends on the same global data pool changes to one
function can break other functions.

> Speaking of modules and modularity:
>
>> I just wrote a whole COFF object file library as a single
>> header file.
>
> Is it not an abuse of headers? Can it be considered modular
> design if the header is simply pasted into code by the macro
> processor, has no separation of interface and
> implementation, and cannot be compiled separattely?
>
>> Without templates its clumsier to create an array of
>> anything.
>
> You surely mean a dynamic array. In my previous post I have
> shown how a universal dynamic array can be implemented in C.
>

I did not pay much attention because std::vector is already perfect.

> About the memory management in std:vector:
>
>> It enlarges the memory allocation by a factor of 1.5 to
>> 2.0 and copies all the elements whenever totally memory is
>> used up. It does this automatically on
>> std::vector::push_back();
>
> So do my C dynamic arrays, although the factor is constant.

With a constant growth size is prioritized over time.

>
>> Or you can allocate enough memory in advance with
>> reserve() or resize(). With resize you can just use it
>> like an array with subscripts. If you index out-of-bounds
>> it crashes.
>
> So do my C dynamic arrays, where you can set capacity and
> actual length.
>
>> With reserve() adding an element requires push_back() yet
>> it is much faster because the memory is already allocated.
>> You use std::vector::size() to always know the current
>> boundary.
>
> It is very simlar with my dynamic arrays in C.
>
>> std::vector is the only way I ever use dynamically
>> allocated memory.
>
> Indeed. Anything else is hardly needed for most
> applications.
>

In other words I never ever use new, malloc() or calloc().
I did try using std::list once yet the benchmarks proved that
std::vector is much more efficient even for most linked list things.

[Bonita Montero]

> I did not pay much attention because std::vector is already perfect.

I derived a class gvector. It has a growth-factor of n and m. n is an
integral growth-factor that the vector's capacity is lineary incremented
every time it gets full. m is a float that the vector's capacity is mul-
tiplied by if it gets full. Whichever size is chosen depends on which is
greater.
Usually n is chosen that it determines the allocation-steps which are
backed by the memory-pool of the allocator. When the memory-allocator
begin to allocate the memory directly from the kernel as the block-size
gets large enough, the capacity is resized by an appropriately chosen m.
One might think that multiplying the vector's capacity by a constant
factor is a waste of memory, but keep in mind that the kernels don't
really physically allocate pages demanded from the kernel until you
really touch the memory; and memory that is only allocated to reserve
for a certain capacity isn't touched until you add elements to the
vector.

So here's my gvector:

#pragma once
#include <vector>
#include <utility>
#include <new>
#include <cassert>

template<typename T, typename Allocator = std::allocator<T>>
struct gvector : public std::vector<T, Allocator>
{
using super = std::vector<T, Allocator>;
using iterator = typename super::iterator;
using const_iterator = typename super::const_iterator;
using size_type = typename super::size_type;
explicit gvector( std::size_t growConst = 1, float growExp = 1.0,
Allocator const &alloc = Allocator() );
explicit gvector( Allocator const &alloc = Allocator() );
explicit gvector( size_type count, T const &value, Allocator const
&alloc = Allocator() );
explicit gvector( size_type count );
template<typename InputIt>
gvector( InputIt first, InputIt last, Allocator const &alloc =
Allocator() );
gvector( super const &other );
gvector( super const &other, Allocator const &alloc =
Allocator() );
gvector( super const &&other );
gvector( std::initializer_list<T> init, Allocator const &alloc
= Allocator() );
iterator insert( iterator pos, T const &value );
iterator insert( const_iterator pos, T const &value );
iterator insert( const_iterator pos, T const &&value );
iterator insert( const_iterator pos, size_type count, T const &value );
template<typename InputIt>
iterator insert( const_iterator pos, InputIt first, InputIt last );
iterator insert( const_iterator pos, std::initializer_list<T> ilist );
template<typename ... Args>
iterator emplace( const_iterator pos, Args &&...args );
void push_back( T const &value );
void push_back( T &&value );
template<typename ... Args>
void emplace_back( Args &&...args );
void set_grow( std::size_t growConst = 1, float growExp = 1.0 );
private:
void grow();
std::size_t m_growConst;
float m_growExp;
};

template<typename T, typename Allocator>
gvector<T, Allocator>::gvector( std::size_t growConst, float growExp,
Allocator const &alloc ) :
super( alloc ),
m_growConst( growConst ),
m_growExp( growExp )
{
assert(growExp >= 0.0);
}

template<typename T, typename Allocator>
inline
gvector<T, Allocator>::gvector::gvector( Allocator const &alloc ) :
super( alloc ),
m_growConst( 1 ),
m_growExp( 0.0 )
{
}

template<typename T, typename Allocator>
inline
gvector<T, Allocator>::gvector::gvector( size_type count, T const
&value, Allocator const &alloc ) :
super( count, value, alloc ),
m_growConst( 1 ),
m_growExp( 0.0 )
{
}

template<typename T, typename Allocator>
inline
gvector<T, Allocator>::gvector::gvector( size_type count ) :
super( count ),
m_growConst( 1 ),
m_growExp( 0.0 )
{
}

template<typename T, typename Allocator>
template<typename InputIt>
inline
gvector<T, Allocator>::gvector::gvector( InputIt first, InputIt last,
Allocator const &alloc ) :
super( first, last, alloc ),
m_growConst( 1 ),
m_growExp( 0.0 )
{
}

template<typename T, typename Allocator>
inline
gvector<T, Allocator>::gvector::gvector( super const &other ) :
super( other ),
m_growConst( 1 ),
m_growExp( 0.0 )
{
}

template<typename T, typename Allocator>
inline
gvector<T, Allocator>::gvector::gvector( super const &other, Allocator
const &alloc ) :
super( other, alloc ),
m_growConst( 1 ),
m_growExp( 0.0 )
{
}

template<typename T, typename Allocator>
inline
gvector<T, Allocator>::gvector::gvector( super const &&other ) :
super( std::move( other ) ),
m_growConst( 1 ),
m_growExp( 0.0 )
{
}

template<typename T, typename Allocator>
inline
gvector<T, Allocator>::gvector::gvector( std::initializer_list<T> init,
Allocator const &alloc ) :
super( init, alloc ),
m_growConst( 1 ),
m_growExp( 0.0 )

{
}

template<typename T, typename Allocator>
inline
typename gvector<T, Allocator>::iterator gvector<T, Allocator>::insert(
iterator pos, T const &value )
{
if( super::size() == super::capacity() )
grow();
return super::insert( pos, value );
}

template<typename T, typename Allocator>
inline
typename gvector<T, Allocator>::iterator gvector<T, Allocator>::insert(
const_iterator pos, T const &value )
{
if( super::size() == super::capacity() )
grow();
return super::insert( pos, value );
}

template<typename T, typename Allocator>
inline
typename gvector<T, Allocator>::iterator gvector<T, Allocator>::insert(
const_iterator pos, T const &&value )
{
if( super::size() == super::capacity() )
grow();
return super::insert( pos, value );
}

template<typename T, typename Allocator>
inline
typename gvector<T, Allocator>::iterator gvector<T, Allocator>::insert(
const_iterator pos, size_type count, T const &value )
{
if( super::size() == super::capacity() )
grow();
return super::insert( pos, count, value );
}

template<typename T, typename Allocator>
template<typename InputIt>
inline
typename gvector<T, Allocator>::iterator gvector<T, Allocator>::insert(
const_iterator pos, InputIt first, InputIt last )
{
if( super::size() == super::capacity() )
grow();
return super::insert( pos, first, last );
}

template<typename T, typename Allocator>
inline
typename gvector<T, Allocator>::iterator gvector<T, Allocator>::insert(
const_iterator pos, std::initializer_list<T> ilist )
{
if( super::size() == super::capacity() )
grow();
return super::insert( pos, ilist );
}

template<typename T, typename Allocator>
template<typename ... Args>
inline
typename gvector<T, Allocator>::iterator gvector<T, Allocator>::emplace(
const_iterator pos, Args &&...args )
{
if( super::size() == super::capacity() )
grow();
return super::emplace( pos, args ... );
}

template<typename T, typename Allocator>
inline
void gvector<T, Allocator>::push_back( T const &value )
{
if( super::size() == super::capacity() )
grow();
super::push_back( value );
}

template<typename T, typename Allocator>
inline
void gvector<T, Allocator>::push_back( T &&value )
{
if( super::size() == super::capacity() )
grow();
super::push_back( std::move( value ) );
}

template<typename T, typename Allocator>
template<typename ... Args>
inline
void gvector<T, Allocator>::emplace_back( Args &&...args )
{
if( super::size() == super::capacity() )
grow();
super::emplace_back( args ... );
}
template<typename T, typename Allocator>
void gvector<T, Allocator>::set_grow( std::size_t growConst, float growExp )
{
assert(growExp >= 0.0);
m_growConst = growConst;
m_growExp = growExp;
}

template<typename T, typename Allocator>
void gvector<T, Allocator>::grow()
{
using namespace std;
size_t size = super::size(),
capacity = super::capacity();
assert(size == capacity);
size_t growConst = size + m_growConst,
growExp = (size_t)(size * m_growExp);
growExp = growExp != size ? growExp : size + 1;
try
{
super::reserve( growConst >= growExp ? growConst : growExp );
}
catch( bad_alloc & )
{
if( growConst >= growExp )
super::reserve( size + 1 );
else
try
{
super::reserve( growConst );
}
catch( bad_alloc & )
{
super::reserve( size + 1 );
}
}
}

#if !defined(NDEBUG)
template
struct gvector<char, std::allocator<char>>;
#endif

[olcott]

On 9/12/2020 1:10 PM, Bonita Montero wrote:
>> I did not pay much attention because std::vector is already perfect.
>
> I derived a class gvector. It has a growth-factor of n and m. n is an
> integral growth-factor that the vector's capacity is lineary incremented
> every time it gets full. m is a float that the vector's capacity is mul-
> tiplied by if it gets full. Whichever size is chosen depends on which is
> greater.
> Usually n is chosen that it determines the allocation-steps which are
> backed by the memory-pool of the allocator. When the memory-allocator
> begin to allocate the memory directly from the kernel as the block-size
> gets large enough, the capacity is resized by an appropriately chosen m.
> One might think that multiplying the vector's capacity by a constant
> factor is a waste of memory, but keep in mind that the kernels don't
> really physically allocate pages demanded from the kernel until you
> really touch the memory; and memory that is only allocated to reserve
> for a certain capacity isn't touched until you add elements to the
> vector.
>
> So here's my gvector:
>

You may have been able to simply add a custom allocator to std::vector
to do the same thing.

Here is an absolutely fabulous two-dimensional std::vector written by a
member of this group:

https://groups.google.com/forum/#!original/comp.lang.c++/OnNneMNMIoU/OvGbbA8vCakJ

[Bonita Montero]

> You may have been able to simply add a custom allocator to std::vector
> to do the same thing.

How should that work ? There's no realloc-method of an allocator.
The vector simply allocates new memory and copies it to the new
allocated place.

[Melzzzzz]

Yep, one cannot copy verbatim without calling copy constructors,
and destruct afterwards ...


--
current job title: senior software engineer
skills: c++,c,rust,go,nim,haskell...

press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala

[olcott]

https://stackoverflow.com/questions/11896960/custom-allocator-in-stdvector

[Bonita Montero]

>>> You may have been able to simply add a custom allocator to
>>> std::vector to do the same thing.

>> How should that work ? There's no realloc-method of an allocator.
>> The vector simply allocates new memory and copies it to the new
>> allocated place.

> https://stackoverflow.com/questions/11896960/custom-allocator-in-stdvector

You're missing the point. As you can't grow a vector in-place with
a custom allocator you can stick with my solution, which is simpler.

[Bonita Montero]

And even more: an allocator can't manage the capacity of a vector.
So having a custom allocator here doesn't make sense !

[olcott]

I don't understand. The common memory growth factor of doubling the
allocation on every reallocation does manage the std::vector::capacity()
of the vector.

[Bonita Montero]

>> And even more: an allocator can't manage the capacity of a vector.
>> So having a custom allocator here doesn't make sense !

> I don't understand. The common memory growth factor of doubling the
> allocation on every reallocation does manage the std::vector::capacity()
> of the vector.

You suggested doing what I did in the allocator. This would mean
to allocate more memory than requested. But the vector wouldn't
notice this. It simply assumes that it got no more memory than
requested. So doing this growh like I did isn't possible through
a custom allocator.

[olcott]

I am only referring to the std::vector::push_back() automatic
reallocation memory growth factor.

[Bonita Montero]

> I am only referring to the std::vector::push_back() automatic
> reallocation memory growth factor.

No, you suggested to do what I did with a custom allocator:

| You may have been able to simply add a custom allocator to
| std::vector to do the same thing.

That's not possible.

[Juha Nieminen]

In comp.lang.c++ Anton Shepelev <anto...@gmail.com> wrote:
> There is a fundamental argument
> for the simplicity of a language.

I always hate it when people talk about the "simplicity" of C,
equating the length of its standard with the "simplicity" of
the language itself.

If the length of the language definition were everything that's
needed to know whether a programming language is "simple" to use
or not, then you could take any of the esoteric languages out there
that consist of something like 6 commands and which language
specification can be written in one page, and talk about the
"simplicity" of that language and how it makes it better than C++.

Length of the language specification does in no way correlate to
the simplicity of use or understanding the language. The esoteric
programming languages are a perfect proof of this.

C is a very complicated language compared to many others, both in
terms of fully understanding it, as well as using it.

For example, pointer syntax and arithmetic in C is really obscure.
It's so obscure, in fact, that not many even expect C (or C++),
who may have actively programmed in it for decades, still remember
by heart the syntax of, for example, "a pointer to a 2-dimensional
array where the second dimension is 100". Heck, some such programmers
might not even know such a thing is possible at all! Even though they may
have been programming in C (or C++) for decades. I kid you not.

Many experienced C programmers may be more familiar with pointers to
functions (because in C they are very often used), but even then you
can write really complex pointer declarations that hare extraordinarly
hard to decipher. Certainly not something you can decipher at a quick
glance.

C programmers also seem to be, for some reason, not very intimate with
the newer versions of the C standard, even though they add relatively
little to the language. For example, C99 introduced the 'inline'
keyword for function declarations. Even to this day, 20 years later,
you can still find newly-written C code where the programmer wrote,
in a header file, a 'static inline' function (instead of just 'inline'),
no doubt because of the old habit of thinking that if a function
definition in a header does not have the magic 'static' keyword then
it may cause linker errors, without understanding that 'inline' takes
care of that, and does it better than 'static'. (Yes, 'inline' functions
in C work in the same way as in C++, with regards to linking.)

(The problem with 'static inline' functions is that they will be
instantiated in every single compilation unit where they are used.
If the compiler ends up not actually inlining them, then their code
will be needlessly duplicated, increasing the binary size, and eg.
pointers to the function will point to different places. Declaring
the function as merely 'inline' is the better option because in this
case duplicates are discarded for the final executable.)

And, of course, don't let me get even started with how complicated
memory management is in C, for such a "simple" language. I have witnessed
first-hand how exasperating it can be to write complicated several levels
deep dynamic data structures in C. (I have eg. had to help a friend going
through a C programming class to implement exercises involving such data
structures. His final conclusion after the course was, essentially,
"C is not for me" and he moved to Javascript, Haxe and C#.)

C is *not* a simple language. Not in the sense of being simple to
understand and use. May be "simple" in the same sense as when that
word is used to describe a person.

[Jorgen Grahn]

On Sun, 2020-09-13, Juha Nieminen wrote:
> In comp.lang.c++ Anton Shepelev <anto...@gmail.com> wrote:
>> There is a fundamental argument
>> for the simplicity of a language.
>
> I always hate it when people talk about the "simplicity" of C,
> equating the length of its standard with the "simplicity" of
> the language itself.

(Cross-post to comp.lang.c dropped)

Me too. But I've decided it's harmless if a few people sit in
comp.lang.c and invent theories explaining why they don't use C++.

You cannot change their minds, and they are no major threat to C++
programmers.

[snip]

Good text, but I thought you were going to repeat your argument that
it's better to have the complexity in the language than in your own
code. That's a strong argument (but not, I think, enough to convince
someone who made his mind up thirty years ago).

/Jorgen

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

[Ian Collins]

On 13/09/2020 19:05, Juha Nieminen wrote:
>
> Many experienced C programmers may be more familiar with pointers to
> functions (because in C they are very often used), but even then you
> can write really complex pointer declarations that hare extraordinarly
> hard to decipher. Certainly not something you can decipher at a quick
> glance.

void (*signal(int sig, void (*disp)(int)))(int);

:)

Great post.
--
Ian.

[olcott]

On 9/13/2020 2:05 AM, Juha Nieminen wrote:
> In comp.lang.c++ Anton Shepelev <anto...@gmail.com> wrote:
>> There is a fundamental argument
>> for the simplicity of a language.
>
> I always hate it when people talk about the "simplicity" of C,
> equating the length of its standard with the "simplicity" of
> the language itself.
>
> If the length of the language definition were everything that's
> needed to know whether a programming language is "simple" to use
> or not, then you could take any of the esoteric languages out there
> that consist of something like 6 commands and which language
> specification can be written in one page, and talk about the
> "simplicity" of that language and how it makes it better than C++.
>
> Length of the language specification does in no way correlate to
> the simplicity of use or understanding the language. The esoteric
> programming languages are a perfect proof of this.
>
> C is a very complicated language compared to many others, both in
> terms of fully understanding it, as well as using it.
>

The essence of C is very simple.

> For example, pointer syntax and arithmetic in C is really obscure.
> It's so obscure, in fact, that not many even expect C (or C++),
> who may have actively programmed in it for decades, still remember
> by heart the syntax of, for example, "a pointer to a 2-dimensional
> array where the second dimension is 100". Heck, some such programmers
> might not even know such a thing is possible at all! Even though they may
> have been programming in C (or C++) for decades. I kid you not.
>

The essence of pointer syntax is very simple:
int N;
int *M;
&N // Address of N
*M // Data that M points to

> Many experienced C programmers may be more familiar with pointers to
> functions (because in C they are very often used), but even then you
> can write really complex pointer declarations that hare extraordinarly
> hard to decipher. Certainly not something you can decipher at a quick
> glance.
>

Function pointers can produce very efficient code when a selector index
is the subscript to any array of function pointers.

> C programmers also seem to be, for some reason, not very intimate with
> the newer versions of the C standard, even though they add relatively

If it ain't broke don't fix it.

> little to the language. For example, C99 introduced the 'inline'
> keyword for function declarations. Even to this day, 20 years later,
> you can still find newly-written C code where the programmer wrote,
> in a header file, a 'static inline' function (instead of just 'inline'),
> no doubt because of the old habit of thinking that if a function
> definition in a header does not have the magic 'static' keyword then
> it may cause linker errors, without understanding that 'inline' takes
> care of that, and does it better than 'static'. (Yes, 'inline' functions
> in C work in the same way as in C++, with regards to linking.)
>
> (The problem with 'static inline' functions is that they will be
> instantiated in every single compilation unit where they are used.
> If the compiler ends up not actually inlining them, then their code
> will be needlessly duplicated, increasing the binary size, and eg.
> pointers to the function will point to different places. Declaring
> the function as merely 'inline' is the better option because in this
> case duplicates are discarded for the final executable.)
>
> And, of course, don't let me get even started with how complicated
> memory management is in C, for such a "simple" language. I have witnessed
> first-hand how exasperating it can be to write complicated several levels
> deep dynamic data structures in C. (I have eg. had to help a friend going

That is when it is time to switch to C++ classes.

> through a C programming class to implement exercises involving such data
> structures. His final conclusion after the course was, essentially,
> "C is not for me" and he moved to Javascript, Haxe and C#.)
>
> C is *not* a simple language. Not in the sense of being simple to
> understand and use. May be "simple" in the same sense as when that
> word is used to describe a person.
>

When I created post this the idea that I presented was that when you
intentionally restrict yourself to the most useful subset, even C++ is
very simple.

[David Brown]

While I appreciate (and agree with) your general points about C, I don't
agree with your points about "static inline" functions.

In practice compilers will not generate a non-inlined version of a
"static inline" function unless there is overriding reason why it cannot
inline the function (recursion, taking and using its address, that kind
of thing). Thus the risk of duplication should normally be zero (and if
you have a compiler with a warning like gcc's -Winline, it is actually
zero). The advantage of making the function "static inline" is you know
the compiler will always use that definition, and will never end up
calling an external non-inlined version of the function - without the
"static", it is unspecified when this might happen.

In C, "static inline" and "inline" functions behave differently with
respect to non-const static local variables and in their reference to
file-scope static identifiers (these are allowed in a "static inline"
function, but not in an "inline" function - except in C++).

If you have a function that you almost always want to be inlined, but
very occasionally may need non-inlined, then "static inline" lets you do
so with the single definition (in a header) - a file-static non-inlined
version of the function will be generated if needed, from that
definition. If you have used "inline" alone, and need a non-inlined
version, you can't get that from the original inline definition - you
need to re-declare it in a non-inline version.

"Inline" does not work exactly the same in C99 and C++. There is also a
third commonly-used meaning of "inline" - the gcc extension in pre-C99
modes. The differences are subtle, but "static inline" functions are
identical in all cases. That may be good enough reason for a C
programmer to choose "static inline" rather than plain"inline".

<https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Inline.html>

In short, there are many good reasons for a C programmer to /choose/
"static inline", rather than just "inline". It's quite possible that in
many cases the choice is habit or copying someone else, rather than
actively choosing it. But please don't assume the use of "static
inline" is an indicator that the programmer does not understand C99.

> And, of course, don't let me get even started with how complicated
> memory management is in C, for such a "simple" language. I have witnessed
> first-hand how exasperating it can be to write complicated several levels
> deep dynamic data structures in C. (I have eg. had to help a friend going
> through a C programming class to implement exercises involving such data
> structures. His final conclusion after the course was, essentially,
> "C is not for me" and he moved to Javascript, Haxe and C#.)
>
> C is *not* a simple language. Not in the sense of being simple to
> understand and use. May be "simple" in the same sense as when that
> word is used to describe a person.
>

Agreed - "small" does not equate to "simple".

[Tim Rentsch]

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

[...]

> C programmers also seem to be, for some reason, not very intimate
> with the newer versions of the C standard, even though they add
> relatively little to the language.

An ironic statement, considering what comes next.

> For example, C99 introduced the
> 'inline' keyword for function declarations. Even to this day, 20
> years later, you can still find newly-written C code where the
> programmer wrote, in a header file, a 'static inline' function
> (instead of just 'inline'), no doubt because of the old habit of
> thinking that if a function definition in a header does not have the
> magic 'static' keyword then it may cause linker errors, without
> understanding that 'inline' takes care of that, and does it better
> than 'static'. (Yes, 'inline' functions in C work in the same way
> as in C++, with regards to linking.)
>
> (The problem with 'static inline' functions is that they will be
> instantiated in every single compilation unit where they are used.
> If the compiler ends up not actually inlining them, then their code
> will be needlessly duplicated, increasing the binary size, and eg.
> pointers to the function will point to different places. Declaring
> the function as merely 'inline' is the better option because in this
> case duplicates are discarded for the final executable.)

Despite what you may think, in C 'static inline' is usually a
better choice than just 'inline'. There are restrictions on
'inline' functions that do not apply to 'static inline'
functions, and, more importantly, simply changing 'static
inline' to 'inline' /can/ lead to linker errors - or worse,
since using such functions can be undefined behavior.

Also, despite what you may think, the rules in C for inline
functions (without 'static') are not the same as the rules in C++
for (without 'static') inline functions.

[Real Troll]

On 09/09/2020 18:08, olcott wrote:
>
>
> 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.
>
>

One thing c programmers are not prepared to accept is that "they are
Cobol programmers of 2030".  Linus was discussing this with another
Linux developer and they found that young people are not willing to
learn C when there are other languages such as C# . So old C programmers
have nothing to fear for the next 10 years as they are not likely to
face any competition from the young developers.  However, the technology
is changing so old programmers may not find it easy to adapt to the new
requirements.

[olcott]

Yet it seems unwise to create operating systems using C#, yet these same
systems could be easily transformed into C with classes, thus overcoming
the objecttions of Linus Torvald to C++.

[David Brown]

On 14/09/2020 07:24, olcott wrote:
> On 9/14/2020 12:20 AM, Real Troll wrote:
>> On 09/09/2020 18:08, olcott wrote:
>>>
>>>
>>> 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.
>>>
>>>
>>
>> One thing c programmers are not prepared to accept is that "they are
>> Cobol programmers of 2030".  Linus was discussing this with another
>> Linux developer and they found that young people are not willing to
>> learn C when there are other languages such as C# . So old C
>> programmers have nothing to fear for the next 10 years as they are not
>> likely to face any competition from the young developers.  However,
>> the technology is changing so old programmers may not find it easy to
>> adapt to the new requirements.
>

It makes little sense to write application code in C, in this century -
there needs to be extraordinary reason for doing so. But it is still a
good choice for a lot of low-level work, embedded work,
performance-critical work (in libraries), and some kind of portable
work. In particular, with C you can make code that is more "stand
alone" and independent of other libraries and ABI details that can cause
issues for other languages, including C++ (no matter how little of the
language you use).

> Yet it seems unwise to create operating systems using C#, yet these same
> systems could be easily transformed into C with classes, thus overcoming
> the objecttions of Linus Torvald to C++.
>
>

It would be crazy, IMHO, to use a managed language like C# for an OS.
An OS needs to be lower level than that. (Higher level languages can be
used for OS services.) C++ works fine for OS's, but the API - the
interface between the OS and the rest of the system - is best held in
pure C as the most portable interface language.

[Stuart Redmann]

+1

Wanted to say thanks, too.

Stuart

[Juha Nieminen]

In comp.lang.c++ David Brown <david...@hesbynett.no> wrote:
> In practice compilers will not generate a non-inlined version of a
> "static inline" function unless there is overriding reason why it cannot
> inline the function (recursion, taking and using its address, that kind
> of thing). Thus the risk of duplication should normally be zero (and if
> you have a compiler with a warning like gcc's -Winline, it is actually
> zero).

Not all compilers are gcc and clang. For example the sdcc compiler (which
is relatively widely used out there) will happily instantiate every
'static inline' function in every compilation unit where it's defined,
and its linker is not advanced enough to remove these instantiations even
if they are never called.

I know, because I had to fix this problem in a work-related project
(for a target that has 32 kilobytes of space for the executable binary).

Removing the 'static' made it work correctly.

> If you have a function that you almost always want to be inlined, but
> very occasionally may need non-inlined, then "static inline" lets you do
> so with the single definition (in a header) - a file-static non-inlined
> version of the function will be generated if needed, from that
> definition. If you have used "inline" alone, and need a non-inlined
> version, you can't get that from the original inline definition - you
> need to re-declare it in a non-inline version.

In which situation do you need a "non-line version" of the function?
If you need, for example, a pointer to the function, you can create one
just fine, and it will work just like in C++. If the compiler needs to
actually instantiate the inline function, it will do so, and it will be
a unique instantiation across the entire program (ie. there will be no
duplicates).

If I'm wrong with this, please correct me.

[Juha Nieminen]

Tim Rentsch <tr.1...@z991.linuxsc.com> wrote:
> Despite what you may think, in C 'static inline' is usually a
> better choice than just 'inline'.

If you use 'static inline' you may get unwanted duplications of the function
implementation. For example the sdcc compiler does this (even when the
function instantiation isn't actually called anywhere).

Sure, that might not matter much in a multi-gigabyte PC. It starts mattering
a lot more when you have eg. 32 kilobytes of space for your executable
binary.

> There are restrictions on
> 'inline' functions that do not apply to 'static inline'
> functions, and, more importantly, simply changing 'static
> inline' to 'inline' /can/ lead to linker errors - or worse,
> since using such functions can be undefined behavior.

Care to give some examples?

[Chris M. Thomasson]

probably should not use exceptions in C++ wrt creating an OS?

[Chris M. Thomasson]

Well, at least when creating the Kernel.

[Christian Hanné]

If someone new to C would learn C++ I'd recommend Visual C++
becuase it's a more visual language. It's rather like Logo.

[David Brown]

On 14/09/2020 09:40, Juha Nieminen wrote:
> In comp.lang.c++ David Brown <david...@hesbynett.no> wrote:
>> In practice compilers will not generate a non-inlined version of a
>> "static inline" function unless there is overriding reason why it cannot
>> inline the function (recursion, taking and using its address, that kind
>> of thing). Thus the risk of duplication should normally be zero (and if
>> you have a compiler with a warning like gcc's -Winline, it is actually
>> zero).
>
> Not all compilers are gcc and clang.

Indeed. But gcc is pretty common - and many other compilers (like
Intel's on pc's, and CodeWarrior for several Motorola/Freescale/NXP
microcontrollers) match gcc semantics and at least some extensions. For
many C programmers, whether you think it is a good thing or not,
"practical C" means "gcc C".

> For example the sdcc compiler (which
> is relatively widely used out there)

SDCC is not very widely used. It is an impressive project, and I'd be
less reluctant to use 8051 and similar cores if SDCC were the industry
standard there instead of Keil and IAR, but it is a limited project used
for a dying breed of devices.

> will happily instantiate every
> 'static inline' function in every compilation unit where it's defined,
> and its linker is not advanced enough to remove these instantiations even
> if they are never called.
>
> I know, because I had to fix this problem in a work-related project
> (for a target that has 32 kilobytes of space for the executable binary).
>
> Removing the 'static' made it work correctly.

SDCC puts a lot of effort into working /correctly/ - even if that does
not mean working /efficiently/. Don't get these mixed up. (Though of
course in embedded systems, performance or code size can be an absolute
requirement too.)

Writing code for these kind of microcontrollers invariably requires
writing "SDCC 8051 C" or "Keil 8051 C" or "IAR 6800 C". You don't
expect more than minimal portability and approximate C standards
conformity (SDCC tends to aim a bit more towards standards conformity
even at efficiency costs). You expect that different compilers generate
wildly different efficiencies for the same code, and that small changes
to code that have no semantic difference (and perhaps no object code
difference for optimised gcc code on an x86) can make a big difference
to the resulting code.


Getting good code from a compiler like SDCC is a niche skill - it's fun
in its way, but not relevant to a wider discussion of C.

>
>> If you have a function that you almost always want to be inlined, but
>> very occasionally may need non-inlined, then "static inline" lets you do
>> so with the single definition (in a header) - a file-static non-inlined
>> version of the function will be generated if needed, from that
>> definition. If you have used "inline" alone, and need a non-inlined
>> version, you can't get that from the original inline definition - you
>> need to re-declare it in a non-inline version.
>
> In which situation do you need a "non-line version" of the function?
> If you need, for example, a pointer to the function, you can create one
> just fine, and it will work just like in C++. If the compiler needs to
> actually instantiate the inline function, it will do so, and it will be
> a unique instantiation across the entire program (ie. there will be no
> duplicates).
>

Try this on godbolt.org:

inline int foo(int x) { return x * 2; }

typedef int (*fint)(int);
fint foobar(void) { return foo; }

You get this code:

foobar:
mov eax, OFFSET FLAT:foo
ret

The function "foo" is not created - so linking will fail. You need to
define it specifically, in one (and only one) C file, just like any
other externally linked function that is used somewhere in the code. If
the inline definition is visible, you can do that simply by writing:

"int foo(int x);"

This is different from C++ - in C++, a non-inlined version of the
function "foo" will be generated as needed, from a plain "inline" function.

Or in C you can avoid including the "inline" header definition and
define a completely different externally linked "foo". (This is not
allowed in C++.)

With "static inline", the non-inline version will always be generated as
needed, but be independent from any other non-inline copies generated in
other translation units. (This is true for C and C++.)

> If I'm wrong with this, please correct me.
>

The point you are missing, as far as I can see (and I too hope others
will correct me if I am wrong), is that C++ supports having an
externally linked function generated in multiple object files. This is
vital to templates, and is also used for inline functions, static data,
and the new weirdly-named "inline variables". So with C++, it's fine
for the compiler to generate an externally linked non-inlined "foo"
function here, included in many translation units, and it is up to the
linker to pick one and throw out the others. (The ODR requires that
they all be the same, because there is no way to specify which is kept.)

In C, this is not allowed - you cannot have the same externally linked
symbol defined in more than one object file in the program. So the C
behaviour is different here.


(In most cases, of course, these differences don't matter - usually when
you have an inline function, you are not planning on having a
non-inlined version anyway.)

[David Brown]

You forget you are replying to Tim. He expects you to do your own
homework and post the results. You can look forward to a reply in a
couple of months, when you have completely forgotten this thread, saying
"are you sure about that?".

[David Brown]

It is common to disable exceptions (and RTTI) in such low-level C++
code, but I don't see it as an absolute requirement. It depends on the
kind of OS you are writing.

[Real Troll]

On 14/09/2020 06:24, olcott wrote:
>
>
> Yet it seems unwise to create operating systems using C#,

That's what Microsoft is doing with Windows 10 OS.  they have started
with the "Store" and some aspects of Windows UI.  Rumours are abound
that some system files are also rewritten in C#. However, there are more
than billion lines of code to be written or re-written using c# so it
takes time!!.  Microsoft can't hire all the C# programmers to speed up
the process.

[Richard Harnden]

An IBM man-year .. 730 guys trying to get it done by lunch.

[olcott]

On 9/14/2020 2:58 AM, Christian Hanné wrote:
> If someone new to C would learn C++ I'd recommend Visual C++
> becuase it's a more visual language. It's rather like Logo.

Not not at all not in the least. It is a rats nest of complexity.

[David Brown]

On 14/09/2020 16:55, olcott wrote:
> On 9/14/2020 2:58 AM, Christian Hanné wrote:
>> If someone new to C would learn C++ I'd recommend Visual C++
>> becuase it's a more visual language. It's rather like Logo.
>
> Not not at all not in the least. It is a rats nest of complexity.
>

The poster was surely joking!

[Real Troll]

On 14/09/2020 14:17, Richard Harnden wrote:
>
> An IBM man-year .. 730 guys trying to get it done by lunch.

So it was all about too many cooks !!!!  Did they spoil the broth?

[olcott]

On 9/10/2020 7:08 AM, David Brown wrote:
> On 10/09/2020 11:59, Anton Shepelev wrote:
>> boltar to Pete Olcott:
>>
>>> Why do you put a copyright in your posts? Firstly they're
>>> not copyrightable as usenet is in the public domain [...]
>>
>> You are confusing content and medium. Any content is in
>> principle copyrightable regardless of the medium that
>> contains it.
>>
>
> In fact, whatever you write on Usenet (and most other places) is
> implicitly copyrighted by you, unless there is some prior claim or
> explicit transfer of copyrights. It is certainly not "public domain"
> unless you say so explicitly.
>
> (At least, that is my understanding - IANAL.)

>
> So the real question is, why bother putting a copyright message on the
> post when it is already covered automatically?

Because unlike most of the posts on Usenet I need to distinguish that my
posts related to the Halting Problem, Russell's Paradox, Gödel's 1931
Incompleteness Theorem and the Tarski Undefinability Theorem are mostly
brand new ideas originated by myself and not merely a rehash of what
others have said.

Although it is technically correct that a copyright arises whenever an
idea is put in fixed form most of the ideas presented on USENET are
mostly rehashes of the ideas of others. Because of this most people
would not generally carefully apply copyright law to USENET posts and
might consider some of my brand new ideas simply as rehashes of existing
ideas.

Here is the fundamental flaw in Gödel's 1931 Incompleteness Theorem:
A theory T is incomplete if and only if there is some sentence φ such
that (T ⊬ φ) and (T ⊬ ¬φ).

The definition of incompleteness decides that every formal system that
cannot prove or refute self-contradictory sentences is incomplete
entirely on the basis that the formal system cannot prove or refute
self-contradictory sentences.

> If someone feels that
> their messages are being abused - copied and used in different contexts,
> quoted by someone who does not follow the expected conventions, etc., -
> then perhaps it's easier to get legal help if the copyright is marked
> explicitly. But hopefully that is not something that is going to be a
> likely issue here!

[Chris M. Thomasson]

I want to see the Kernel written in C#. That would be a trip. Fwiw, here
is the full source code to the WinNT 4 kernel:

https://github.com/ZoloZiak/WinNT4

Not sure if garbage collection is a "good idea" here.

[Anton Shepelev]

Olcott to Anton Shepelev:

> > I thought classes had inheritance by definition; they
> > would not be classes otherwise. So you use classes with
> > methods but without inheritcance? -- interesting.
>
> http://wiki.c2.com/?InheritanceBreaksEncapsulation

Of course. Inheritance means dependencies going down and
branching through layers upon layers of the class hierarchy.
It is for this reason that McConnel argued against it in
"Code Complete", and I agree with him. But classes without
inheritance leave so very little of the whole object-
oriented paradigm that switching to a simpler, procedural
language seems only natural. Why stick to a huge object-
oriented language to use 1% of its capabilities? Classes
without inheritance are very easy to do in C, and so are
dynamic arrays and sensible, (Borland)Pascal strings.

> > > Without containment we have side-effects.
> >
> > I beg pardon for overlooking your mention of side
> > effects the first time. I don't understand what side
> > effects are inevitable in procedural programming that
> > classes help to avoid.
>
> If every function depends on the same global data pool
> changes to one function can break other functions.

I understand what side effects are, but I am not familiar
with the term "global data pool". If you mean global
variables, then one can use them in procedural and object-
oriented languages as easily as avoid them! C does not force
you to use or abuse global variables... On the other hand,
the fields of classes -- their hidden state -- are global
with respect to methods because they are not syntatically
passed in as parameters, and produce on class level exactly
the same problem as global variables do on module level in
procedural languages. The big difference, however, is that
procedural programming lets you avoid global varialbes
whereas classes make no sense without fields.

> [...]
> I did not pay much attention because std::vector is
> already perfect.

The subject of this thread being "Why should a "c"
programmer learn c++ ?", I expected you to pay equal
attention to solving your problems in both C and C++...

> > So do my C dynamic arrays, although the factor is
> > constant.
>
> With a constant growth size is prioritized over time.

I said constant factor, not constant increment. `factor'
implies multiplication, not addition.

> In other words I never ever use new, malloc() or calloc().
> I did try using std::list once yet the benchmarks proved
> that std::vector is much more efficient even for most
> linked list things.

A sensible approach once you have dynamic arrays. What do
you do in situtaions where you store pointers or indices
into a vector and have to compress it to release free space
in between used elements?

--
() ascii ribbon campaign -- against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]

[olcott]

On 9/14/2020 5:33 PM, Anton Shepelev wrote:
> Olcott to Anton Shepelev:
>
>>> I thought classes had inheritance by definition; they
>>> would not be classes otherwise. So you use classes with
>>> methods but without inheritcance? -- interesting.
>>
>> http://wiki.c2.com/?InheritanceBreaksEncapsulation
>
> Of course. Inheritance means dependencies going down and
> branching through layers upon layers of the class hierarchy.
> It is for this reason that McConnel argued against it in
> "Code Complete", and I agree with him. But classes without
> inheritance leave so very little of the whole object-
> oriented paradigm that switching to a simpler, procedural
> language seems only natural. Why stick to a huge object-
> oriented language to use 1% of its capabilities? Classes
> without inheritance are very easy to do in C, and so are
> dynamic arrays and sensible, (Borland)Pascal strings.
>

Classes with their own member functions not only dive the complexity of
system design by putting functionality and data in the same place it
used properly can utterly eliminate data dependencies and side effects.

>>>> Without containment we have side-effects.
>>>
>>> I beg pardon for overlooking your mention of side
>>> effects the first time. I don't understand what side
>>> effects are inevitable in procedural programming that
>>> classes help to avoid.
>>
>> If every function depends on the same global data pool
>> changes to one function can break other functions.
>
> I understand what side effects are, but I am not familiar
> with the term "global data pool". If you mean global
> variables, then one can use them in procedural and object-
> oriented languages as easily as avoid them! C does not force

A std::vector can hold many classes comprised of other classes and
stored in a local variable. We can create a dozen of these in main() and
have a very sophisticated and powerful system with no thought ever given
to dynamic memory allocation, or pointers. main() can pass combinations
of these sophisticated classes to its own functions as references.

> you to use or abuse global variables... On the other hand,
> the fields of classes -- their hidden state -- are global
> with respect to methods because they are not syntatically
> passed in as parameters, and produce on class level exactly
> the same problem as global variables do on module level in
> procedural languages. The big difference, however, is that
> procedural programming lets you avoid global varialbes
> whereas classes make no sense without fields.
>
>> [...]
>> I did not pay much attention because std::vector is
>> already perfect.
>
> The subject of this thread being "Why should a "c"
> programmer learn c++ ?", I expected you to pay equal
> attention to solving your problems in both C and C++...
>
>>> So do my C dynamic arrays, although the factor is
>>> constant.
>>
>> With a constant growth size is prioritized over time.
>
> I said constant factor, not constant increment. `factor'
> implies multiplication, not addition.
>

I found that increasing size by double is generally the best tradeoff
between space and time.

>> In other words I never ever use new, malloc() or calloc().
>> I did try using std::list once yet the benchmarks proved
>> that std::vector is much more efficient even for most
>> linked list things.
>
> A sensible approach once you have dynamic arrays. What do
> you do in situtaions where you store pointers or indices
> into a vector and have to compress it to release free space
> in between used elements?
>

I never use pointers and whenever I need indexes they are only used in
the member functions that needs them.

[Anton Shepelev]

Juha Nieminen to Anton Shepelev:

> > There is a fundamental argument for the simplicity of a
> > language.
>
> I always hate it when people talk about the "simplicity"
> of C, equating the length of its standard with the
> "simplicity" of the language itself.
>
> If the length of the language definition were everything
> that's needed to know whether a programming language is

> "simple" to use or not, ->

Of cousre, it is not. The length of the standard is related
to what I should call the mathematical simplicity of a
language, its simplicity in itself, with no regard to ease
of use by mortals. In that sense, RedCode, BainFuck, and
the Turing machine are all by magnitudes simpler than both C
and C++.

> -> then you could take any of the esoteric languages out

> there that consist of something like 6 commands and which
> language specification can be written in one page, and
> talk about the "simplicity" of that language and how it
> makes it better than C++.

Not at all, because neither of those languages is a near
subset of C++, which has all the complexity of C and tons
more to boot.

> Length of the language specification does in no way
> correlate to the simplicity of use or understanding the
> language. The esoteric programming languages are a perfect
> proof of this.

You are not quite correct. With the other conditions equal,
the larger language is harder and longer to learn, forces
the programmer to rember more stuff and to spend more time
thinking which thing to use when, because large languages
tend to offer not merely two, but often three, four, &c ways
defur the same feline.

The length of the standard, charaterising the outward size
of the language, *is* one measure of both its mathematical
and human complexities.

> C is a very complicated language compared to many others,
> both in terms of fully understanding it, as well as using
> it.

Yes. I should say it is certainly more complicated than
Modula and Pascal.

> For example, pointer syntax and arithmetic in C is really
> obscure. It's so obscure, in fact, that not many even
> expect C (or C++), who may have actively programmed in it
> for decades, still remember by heart the syntax of, for
> example, "a pointer to a 2-dimensional array where the
> second dimension is 100".

The declaration of an array has nothing do to with pointer
arithmetic, which *is* simple in C. I do not remeber having
to do it, but here is my attempt, which did not come quite
from the tips of my fingers:

int **p[100];

OK, the syntax of C declarations is counterintuituve until
one learns its logic, and even then it reamains at a
considerable angle with human intuition. But is not this
syntax the same in C++?

> Heck, some such programmers might not even know such a
> thing is possible at all! Even though they may have been
> programming in C (or C++) for decades. I kid you not.

Not to know that a language supports such a basic data
structure? I don't know... One way to avoid the problem is
to declare one thing at a time instead of putting all on one
line, as many like to do.

> Many experienced C programmers may be more familiar with
> pointers to functions (because in C they are very often
> used), but even then you can write really complex pointer
> declarations that hare extraordinarly hard to decipher.
> Certainly not something you can decipher at a quick
> glance.

It is bad enough that C allows such complex declarations,
but I consider it part of it mathematical simplicity. Yet I
never ever write anything like Ian Collins's example:

> void (*signal(int sig, void (*disp)(int)))(int);

I do it one step at a time to keep my brain inside my skull:

typedef void ( *f_disp )( int );
typedef void ( *f_signal)( int sig, f_disp disp );

And again, as far as I know, this declaration syntax is as
essential part of C++ as it is of C. Why mention it?

> C programmers also seem to be, for some reason, not very
> intimate with the newer versions of the C standard, even
> though they add relatively little to the language.

> [...]

I don't see how it bears on the subject, but I like lower
volatility of the C standard. It help the programmer stay
sane and focus on the real work instead of learning heaps of
new features every several years. I absolutely adore the
commitment of PDOS to C90.

> And, of course, don't let me get even started with how
> complicated memory management is in C, for such a "simple"
> language. I have witnessed first-hand how exasperating it
> can be to write complicated several levels deep dynamic
> data structures in C.

Yes the basic model is very simple, but it takes discipline
to use it correctly. Using indices into dynamic arrays
instead of ad-hoc pointers helps a lot.

> (I have eg. had to help a friend going through a C
> programming class to implement exercises involving such
> data structures. His final conclusion after the course
> was, essentially, "C is not for me" and he moved to
> Javascript, Haxe and C#.)

Memory management in C# is so much more complicated than it
is in C once you look into how it works instead of just
using it lamer-like, without a notion of what is going on
under the hood.

> C is *not* a simple language. Not in the sense of being
> simple to understand and use. May be "simple" in the same
> sense as when that word is used to describe a person.

I consider this adjective more true of people whose first
programming language is Python or Java. They import and use
high-level libraries and all the complicated language
features with nary a glimpse of the super compicated
machinery that makes it possible. They miss what programming
is all about.

[Ben Bacarisse]

Anton Shepelev <anto...@gmail.com> writes:

> Juha Nieminen to Anton Shepelev:

<cut>

>> For example, pointer syntax and arithmetic in C is really
>> obscure. It's so obscure, in fact, that not many even
>> expect C (or C++), who may have actively programmed in it
>> for decades, still remember by heart the syntax of, for
>> example, "a pointer to a 2-dimensional array where the
>> second dimension is 100".
>
> The declaration of an array has nothing do to with pointer
> arithmetic, which *is* simple in C. I do not remeber having
> to do it, but here is my attempt, which did not come quite
> from the tips of my fingers:
>
> int **p[100];

It's not really the point of the thread, but that's an array of pointers
to pointers to int. A pointer to an array must use parentheses,
(*p)[...], so that the "pointer to" is read before the "array of" bit:

int (*p)[][100];

> OK, the syntax of C declarations is counterintuituve until
> one learns its logic, and even then it reamains at a
> considerable angle with human intuition. But is not this
> syntax the same in C++?

Yes, but in most cases a C++ program would use a different type
altogether.

>> Heck, some such programmers might not even know such a
>> thing is possible at all! Even though they may have been
>> programming in C (or C++) for decades. I kid you not.
>
> Not to know that a language supports such a basic data
> structure?

I think the point is that few know you can have a "pointer to array"
type. Pointers to the start of an array (which will have the same base
type as the array) are ubiquitous in C but pointers to an array type are
much rarer.

<cut>

>> void (*signal(int sig, void (*disp)(int)))(int);
>
> I do it one step at a time to keep my brain inside my skull:
>
> typedef void ( *f_disp )( int );
> typedef void ( *f_signal)( int sig, f_disp disp );
>
> And again, as far as I know, this declaration syntax is as
> essential part of C++ as it is of C. Why mention it?

It's no longer "essential" as C++ has other syntax. For example:

auto signal(int sig, auto (*disp)(int) -> void) -> auto (*)(int) -> void;

<cut>
--
Ben.

[Juha Nieminen]

In comp.lang.c++ Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
> Anton Shepelev <anto...@gmail.com> writes:
>> Juha Nieminen to Anton Shepelev:

>>> For example, pointer syntax and arithmetic in C is really
>>> obscure. It's so obscure, in fact, that not many even
>>> expect C (or C++), who may have actively programmed in it
>>> for decades, still remember by heart the syntax of, for
>>> example, "a pointer to a 2-dimensional array where the
>>> second dimension is 100".
>>
>> The declaration of an array has nothing do to with pointer
>> arithmetic, which *is* simple in C. I do not remeber having
>> to do it, but here is my attempt, which did not come quite
>> from the tips of my fingers:
>>
>> int **p[100];
>
> It's not really the point of the thread, but that's an array of pointers
> to pointers to int. A pointer to an array must use parentheses,
> (*p)[...], so that the "pointer to" is read before the "array of" bit:
>
> int (*p)[][100];

Yeah, not really the point of the thread, but this beautifully demonstrates
my point.

The correct syntax for "pointer to a two-dimensional array of int, where
the second dimension is 100" is:

int (*p)[100];

Although, technically speaking, that's just "a pointer to an array of
int of size 100", but since a "pointer to value" doubles as a "pointer
to an array of values", that likewise doubles as a pointer to a
two-dimensional array.

While 'p' above is technically speaking "a pointer to an array of
size 100", the difference with a mere "int *p;" is what it dereferences
to, and how it behaves in terms of arithmetic. More precisely:

int *p1; // pointer to int (or int array)
int (*p2)[100]; // pointer to an int[100] (or array of such)

sizeof(*p1) == sizeof(int);
sizeof(*p2) == 100*sizeof(int);

++p1; // will increment p1 by sizeof(int)
++p2; // will increment p2 by 100*sizeof(int)

A two-dimensional array, like "int table[200][100];" is essentially just
"an array of 200 int[100] elements", which is why you can have a pointer
that points to int[100] and have it point to such an array.

It's perhaps understandable, but telling, that even many experienced
C (and C++) programmers don't know this, even after decades.

Incidentally in C++ you can have a reference to an actual 2-dimensional
array, where both dimensions are specified:

int (&r)[200][100];

The semantics of this would require another essay to explain.

[Keith Thompson]

So, technically speaking,

int (*p)[100];

is *not* the correct syntax for "pointer to a two-dimensional array of
int, where the second dimension is 100".

In fact the correct syntax for that is:

int (*p)[][100];

(Yes, I cheated and used cdecl.)

The distinction between arrays and pointers is muddy enough without
glossing over the very real differences.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[Paavo Helde]

15.09.2020 02:15 Anton Shepelev kirjutas:

> Not at all, because neither of those languages is a near
> subset of C++, which has all the complexity of C and tons
> more to boot.

These complexities do not add. When one programs in C++, one takes care
to actively *avoid* unnecessarily complex subsets of C (and most
probably also several subsets of C++, but that's beside the point).

Foe example, std::string is much more easier to use correctly than
strcat(). By using std::vector and std::array one can easily avoid all
syntax and behavior complexities of raw arrays. The list goes on.

[Bart]

That's not helpful. Your example is a 'pointer to 2D array' in the same
way that:

int* p;

doubles as 'pointer to array'.

Although this is extremely common C idiom, it is NOT a pointer to 2D
array. An actual 'pointer to 2D array' would actually double, due to the
same idiom, as 'pointer to 3D array':

int (*p)[][100];
int i,j,k;

p[i][j][k];

What a language where you can have a discussion as to whether an array
has 2 dimensions or 3! At any point where you end up with a T* type, you
can optionally turn that into a gratuituous array dimension, where the
value is set up for such an array or not.

> While 'p' above is technically speaking "a pointer to an array of
> size 100", the difference with a mere "int *p;" is what it dereferences
> to, and how it behaves in terms of arithmetic. More precisely:
>
> int *p1; // pointer to int (or int array)
> int (*p2)[100]; // pointer to an int[100] (or array of such)
>
> sizeof(*p1) == sizeof(int);
> sizeof(*p2) == 100*sizeof(int);
>
> ++p1; // will increment p1 by sizeof(int)
> ++p2; // will increment p2 by 100*sizeof(int)
>
> A two-dimensional array, like "int table[200][100];" is essentially just
> "an array of 200 int[100] elements", which is why you can have a pointer
> that points to int[100] and have it point to such an array.
>
> It's perhaps understandable, but telling, that even many experienced
> C (and C++) programmers don't know this, even after decades.
>
> Incidentally in C++ you can have a reference to an actual 2-dimensional
> array, where both dimensions are specified:
>
> int (&r)[200][100];
>
> The semantics of this would require another essay to explain.
>

(My language only has such references for parameters. There, assuming
the most likely meaning of that C++ type, the same thing would be
declared as:

[200,100]int &r

which means that the type is really 'ref[200,100]int r', but the
necessary & and deref operations are done transparently.)

[Ben Bacarisse]

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

> In comp.lang.c++ Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
>> Anton Shepelev <anto...@gmail.com> writes:
>>> Juha Nieminen to Anton Shepelev:
>>>> For example, pointer syntax and arithmetic in C is really
>>>> obscure. It's so obscure, in fact, that not many even
>>>> expect C (or C++), who may have actively programmed in it
>>>> for decades, still remember by heart the syntax of, for
>>>> example, "a pointer to a 2-dimensional array where the
>>>> second dimension is 100".
>>>
>>> The declaration of an array has nothing do to with pointer
>>> arithmetic, which *is* simple in C. I do not remeber having
>>> to do it, but here is my attempt, which did not come quite
>>> from the tips of my fingers:
>>>
>>> int **p[100];
>>
>> It's not really the point of the thread, but that's an array of pointers
>> to pointers to int. A pointer to an array must use parentheses,
>> (*p)[...], so that the "pointer to" is read before the "array of" bit:
>>
>> int (*p)[][100];
>
> Yeah, not really the point of the thread, but this beautifully demonstrates
> my point.
>
> The correct syntax for "pointer to a two-dimensional array of int, where
> the second dimension is 100" is:
>
> int (*p)[100];

No, that's not the type you asked for. It is usual to /access/ an array
of int using an int pointer, but a pointer to an array of int is another
thing altogether. Likewise, you can use the above to access the
elements of an array whose element type is int[100], but it is not a
pointer to 2D array.

> Although, technically speaking, that's just "a pointer to an array of
> int of size 100", but since a "pointer to value" doubles as a "pointer
> to an array of values", that likewise doubles as a pointer to a
> two-dimensional array.

Not at all. A pointer to int (int *) points to an int -- one single
int. That may be a lone int, and int as the start of an array or an int
in the middle of an array, but it is not a pointer to an array of int.

> While 'p' above is technically speaking "a pointer to an array of
> size 100", the difference with a mere "int *p;" is what it dereferences
> to, and how it behaves in terms of arithmetic. More precisely:
>
> int *p1; // pointer to int (or int array)
> int (*p2)[100]; // pointer to an int[100] (or array of such)
>
> sizeof(*p1) == sizeof(int);
> sizeof(*p2) == 100*sizeof(int);
>
> ++p1; // will increment p1 by sizeof(int)
> ++p2; // will increment p2 by 100*sizeof(int)
>
> A two-dimensional array, like "int table[200][100];" is essentially just
> "an array of 200 int[100] elements", which is why you can have a pointer
> that points to int[100] and have it point to such an array.
>
> It's perhaps understandable, but telling, that even many experienced
> C (and C++) programmers don't know this, even after decades.

I think you have just added to the general confusion. Don't call a
pointer to int a pointer to an array of int, call it a pointer /into/ an
array, if you must, or you can just stick with what it is: a pointer to
int.

Likewise, a pointer to an array of 100 ints is not a pointer to 2D array
if ints, it is a pointer /into/ (i.e. to one member of) such an array.

--
Ben.

[olcott]

You totally get it !!!

[olcott]

I don't see the difference.

[olcott]

On 9/15/2020 9:03 AM, Bonita Montero wrote:
>>> If you write any non-trivial piece of code, you need to learn it
>>> properly. Wrapping everything in classes and hoping nothing blows up
>>> is a recipe for disaster.
>
>> If you use std::vector for all your dynamic memory needs move
>> semantics is trivial. It it all automatically handled for you by
>> std::vector.
>
> Not automatically. You have to write "vecA = move( vecB );"
> instead of "vecA = vecB;". That's trivial, but you have to
> know how to use it.
>

I don't rememeber ever needing to do this, I simply used the default
assignment operator().

[olcott]

Whenever I need a two-dimensional array I simply use this one:
// comp.lang.c++ message from Gianni Mariani Nov 24, 2005 at 9:21 pm
// http://groups.google.com/group/comp.lang.c++/msg/a9092f0f6c9bf13a