Tuesday, April 10, 2018

Digest for comp.lang.c++@googlegroups.com - 22 updates in 5 topics

asetofsymbols@gmail.com: Apr 10 03:30PM -0700

I not agree... Some function has to be big: as some printf like function, or the big num division function etc with some help function for reduce their complexity
 
It seems there are 2 mode of writing function the first is write all follow only what I believe code does the 2th mode is debug for see that what one imagine happen in reality...
Some time ago I see some code I wrote in past, in modality not debug, only imagination not commented too, compile but no try run; It was hard, the only beginning was write comments and rewrite some part
"Öö Tiib" <ootiib@hot.ee>: Apr 10 09:49AM -0700

On Tuesday, 10 April 2018 16:04:20 UTC+3, Scott Lurndal wrote:
> >standards forbid to declare more than one thing per declaration.
 
> What's a "real C++ code base"? We've several million lines of
> actively developed C++ code that uses raw arrays and raw pointers.
 
I mean't that raw pointers are basically memory addresses that have
pile of unsafe operations only few of what make any sense in context
of particular memory address. C++ can abstract most of that away
without losing any efficiency. So good C++ code should do it and
that leaves rare cases for raw pointers in code base.
 
The raw array is decaying into that raw pointer in majority of
contexts so result is above described unsafe memory address plus
lost (often vital for optimizations and safety) information.
The std::array is safer, better and more efficient for most usages.
So good C++ code should prefer std::array and that leaves rare
cases for raw array in C++ code base.
bartc <bc@freeuk.com>: Apr 10 06:09PM +0100

On 10/04/2018 16:05, David Brown wrote:
 
>> The only quibble might be whether you stick the variable before or after
>> the type, and with what extra syntax.
 
> You might also want keywords to say that this is a variable declaration
 
Yes: 'extra syntax'.
 
> Well, /you/ wouldn't do it! Clearly some other people are quite happy
> with that. In C, the declaration syntax is designed to match the way
> the variable is used, rather than to emphasis its type.
 
Which of course is completely wrong.
 
When you add "*" to "int x" to make it "int * x", you are inserting a
pointer level into the type.
 
When you add "*" to "x" to make it "*x", you are dereferencing x and
therefore /removing/ a pointer level from the resulting type.
 
> No, you would not - at least, you would not laugh if you understood
> about language design - as distinct from having designed a couple of
> simple languages
 
Based on ideas from well-regarded languages such as Algol-68, Pascal and
Ada. Fortunately I hadn't come across C at that point.
 
> and thinking that they are the only good ways to make a
> language.
 
The type syntax created in C and inherited by C++ is /not/ a good way of
doing it as evidenced by the numerous ways you can be tripped up (eg.
see this thread), all the guidelines that tell you the ways to avoid the
pitfalls or how to write complex types, and the number of utilities that
exist to explain what a particular type specification even means.
 
You don't need to be a language design expert to see that.
 
--
bartc
scott@slp53.sl.home (Scott Lurndal): Apr 10 05:21PM

>> language.
 
>The type syntax created in C and inherited by C++ is /not/ a good way of
>doing it as evidenced by the numerous ways you can be tripped up
 
The type syntax created in C and inherited by C++ _is_ a good way
of doing it as evidenced by the billions of lines of C and C++ code
in existence.
 
The fact that you refuse to understand the rules, doesn't invalidate them.
bartc <bc@freeuk.com>: Apr 10 07:47PM +0100

On 10/04/2018 18:21, Scott Lurndal wrote:
 
> The type syntax created in C and inherited by C++ _is_ a good way
> of doing it as evidenced by the billions of lines of C and C++ code
> in existence.
 
I can't see the connection.
 
Maybe there were no viable alternatives for systems programming that
were just at the right level.
 
Maybe Unix started to take over the world and /that/ was written in C
and it came with a C compiler and most of the dealings with it had to
involve C or C interfaces.
 
Maybe there are billions of lines, instead of only hundreds of millions,
/because/ of the type system.
 
> The fact that you refuse to understand the rules, doesn't invalidate them.
 
I understand the rules. I just think the syntax is atrocious and many
seem to agree. Even Kernighan & Ritchie acknowledge that in K&R2 where
they say that C has been castigated for the syntax of its declarations,
before going on to present a program to convert C declarations into English.
 
My preferred syntax doesn't need turning into English because you can
read, write and understand it almost as though it /was/ English. You are
saying it is better if it's not so straightforward?
 
 
(This is the type spec that means 'pointer to a void function with no
parameters' in one of my languages:
 
ref proc # or:
pointer to proc # if you want it more verbose
 
This is the same thing in C:
 
void(*)(void)
 
Enough said...)
 
--
bartc
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 10 09:57PM +0200

On 10.04.2018 20:47, bartc wrote:
 
> This is the same thing in C:
 
>    void(*)(void)
 
> Enough said...)
 
 
In C++ you can write
 
function<void()>
 
... where `function` is `std::function`, a class from the `<functional>`
header.
 
For data the standard library does not offer similar practical type
builders (both names and functionality suck), but you can trivially define
 
template< class Type >
using ptr = Type*;
 
... and then write e.g.
 
const ptr<const char> s = "Oh!";
 
Cheers & hth.,
 
- Alf
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Apr 10 01:57PM -0700

On 4/10/2018 5:43 AM, Rick C. Hodgin wrote:
> > established software development practices.
 
> You don't have to use it, Leigh.  My feeling won't be hurt.  CAlive
> should not impact or affect you in the slightest.
 
I am wondering how old Leigh will have to be before he can even think
about trying it out? Just a little example compiler damn it! You can say
it is in a highly limited experimental state, for God's sake. What is
the hello world!
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Apr 10 02:04PM -0700

On 4/10/2018 6:53 AM, Rick C. Hodgin wrote:
> has to use any of these new features I am adding. They exist as one
> more tool in the toolbox, able to be used for those who see value in
> that tool.
 
Afaict, CDead for now.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 10 02:31PM -0700

On Tuesday, April 10, 2018 at 4:58:00 PM UTC-4, Chris M. Thomasson wrote:
> about trying it out? Just a little example compiler damn it! You can say
> it is in a highly limited experimental state, for God's sake. What is
> the hello world!
 
You have demonstrated repeatedly that you do not want to know
the truth. You want only to know the things you already know,
and proceed on the path you're already on. It's the saddest thing
to see in a person.
 
I cannot help you, Chris.
 
--
Rick C. Hodgin
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Apr 10 02:39PM -0700

On 4/10/2018 2:31 PM, Rick C. Hodgin wrote:
> and proceed on the path you're already on. It's the saddest thing
> to see in a person.
 
> I cannot help you, Chris.
 
What is the current state of your code? Can it compile a hello world
program or not?
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Apr 10 02:39PM -0700

On 4/9/2018 5:51 PM, Rick C. Hodgin wrote:
>>> of my goals.
 
>> It can help get it out there.
 
> I don't have a goal to "get it out there."
 
Why do you continually mention it here?
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 10 02:48PM -0700

On Tuesday, April 10, 2018 at 5:39:58 PM UTC-4, Chris M. Thomasson wrote:
 
> >> It can help get it out there.
 
> > I don't have a goal to "get it out there."
 
> Why do you continually mention it here?
 
I have wanted the ideas I have to be incorporated into C and C++.
 
I spent a lengthy campaign in 2014 and 2015 attempting to get some
of these ideas added to the C Standard, specifically the addition of
the class and exception handling. Had that happened, I probably
would never have pursued CAlive. But I met nothing but resistence
from everybody, much as I am doing here with you, and it was clear
I was getting nowhere with anybody else, so I decided to move in
2015.
 
I have a host of projects I am working on. I do not work solely on
any one project. All of my work is publicly available for download
and use by any person for any reason. The license I have is a Public
Domain license with one caveat:
 
Self-accountability to God that you will keep the source code
open as you received it.
 
I do not enforce that request, but you are left to yourself and your
relationship with God to honor it or not. There will be no court
cases over those who use it contrary to that desire, but everything
related to compliance or non-compliance will be solely between you
and God.
 
http://www.libsf.org:8990/projects/LIB/repos/libsf/browse
 
--
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 10 03:01PM -0700

On Tuesday, April 10, 2018 at 5:39:11 PM UTC-4, Chris M. Thomasson wrote:
> What is the current state of your code? Can it compile a hello world
> program or not?
 
Why do you care? All you do is mock me and berate my works. CDead
and all that. You are solely in "teardown Rick" mode.
 
CAlive is a driver that operates the base tool called Rapid Development
Compiler (RDC). RDC is a framework which enables a range of abilities,
and the CAlive driver is essentially a database describing how to guide
and direct RDC through a compilation process.
 
It is not something that can be built in pieces and used in stages.
It's like trying to build a bridge across some large gap. You can't
get it 80% completed and drive trucks over it that are rated for 80%
of the bridge's maximum weight. You can't use it until it's 100%
completed.
 
There is a tremendous amount of code and design that's gone in to RDC
and CAlive. They do not yet produce anything that's usable. There
are many algorithms which can lex and tokenize source code, along with
aggregating related things (like 1.234 being recognized as a single
number rather than [1][decimal_point][234]), and so on.
 
I have algorithms which parse #pragmas, load #include files, expand
macros, and setup N-passes for compilation. I have databases created
which map operators and operator precedence, call the correct handlers,
handle sequencing and orders of operation. I have some of the CAlive
standard library written, and other parts designed.
 
I have stated publicly on comp.lang.c that it will be toward the end
of 2019 before it's ready to be released, and that timeframe is a goal,
not a surety. And it may be pushed back further now as I'm currently
developing my Logician tool to design a CPU in that incorporates and
proves my idea of Love Threading. It's based on my Oppie-3 core design,
which is basically a simplified protected-mode only 32-bit 80386:
 
http://www.libsf.org:8990/projects/LIB/repos/libsf/browse/arxoda/oppie/oppie-3.png
 
That project will likely take me through this time next year, so CAlive
will probably take a backseat during most or all of that development,
meaning it will proceed slowly.
 
Once I get that CPU completed, I will proceed with my Arxoda design,
which is basically a simplified and enhanced 40-bit 80386:
 
http://www.libsf.org:8990/projects/LIB/repos/libsf/browse/arxoda/core/wex_register_mapping.png
http://www.libsf.org:8990/projects/LIB/repos/libsf/browse/arxoda/core/descriptor.png
http://www.libsf.org:8990/projects/LIB/repos/libsf/browse/arxoda/core/paging_cr0_cr4.png
 
It is all a very comprehensive goal, Chris. I don't have small goals.
I have huge goals and a grand vision. I continue to pray and seek
those who will come and help this endeavor, which is a purposeful
endeavor given over to the Lord, to return to Him the talents and
skills He first gave us, and to give the people of this world the
full fruit of our offerings at all points, source code and all, to
all levels of hardware, operating systems, drivers, compilers, and
all apps.
 
I'm trying to create an entire ecosystem here, Chris, one which is
directly honoring the Lord Jesus Christ, and will continue to do so
forever.
 
And all the while you do not seek to even understand what I'm doing,
but only proceed along the lines of your own thinking, asking me for
a hello.ca program.
 
You are so very wrong about limited me, Chris. How wrong are you
even more so about God?
 
--
Rick C. Hodgin
Ben Bacarisse <ben.usenet@bsb.me.uk>: Apr 10 11:22PM +0100


> On 10/04/18 16:29, Ben Bacarisse wrote:
<snip>
 
> I don't think it is a matter of not learning - I know fine how things
> work when you have multiple declarations in one line. But mixing
> concepts together too tightly is never a good idea for clarity.
 
I don't know what that means. I like to mix things together when they
are linked. So I'd happily write
 
short buffer[100], *bp = buffer;
 
precisely because it seems to me clearer to link them. I don't know if
this is "mixing concepts" or if it's doing it "too tightly".
 
<snip>
>> revolves around the name being declared, I can't stand seeing
 
>> char* x;
 
> To me, that is putting the emphasis on x being a pointer-to-char.
 
And I dislike it because it draws the emphasis /away/ from x bring a
pointer-to-char. Pointers are declared with a * in the declarator and I
see a plain, naked x. Now I /can/ parse char* x; but I have to spot the
* placed as far away as possible from the declarator.
 
What do you with a pointer to an array? Do you write
 
int(* x)[10];
 
<snip>
>> return x +1;
 
>> to me.
 
> Those two would really annoy me too.
 
Why? They annoy me because the spacing is "fighting" the syntax. Are
you saying that that carries less weight for you in declarations?
 
<snip>
--
Ben.
Daniel <danielaparker@gmail.com>: Apr 10 09:56AM -0700

On Tuesday, April 10, 2018 at 9:22:06 AM UTC-4, Rick C. Hodgin wrote:
 
> I explain these things to you ... but you reject it.
 
Other people have explained things to you, and you reject it, so it's a wash.
 
Daniel
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Apr 10 01:47PM -0700

On 4/10/2018 6:48 AM, Rick C. Hodgin wrote:
> On Tuesday, April 10, 2018 at 9:30:50 AM UTC-4, Mr Flibble wrote:
>> Evolution mate. Speed of light in a vacuum mate.
 
> Ever see "A Fish Called Wanda?"
 
Yes Mr Thomason. They are missing an s.
 
[...]
legalize+jeeves@mail.xmission.com (Richard): Apr 10 07:55PM

[Please do not mail me a copy of your followup]
 
Jorgen Grahn <grahn+nntp@snipabacken.se> spake the secret code
 
>Surely there's /some/ place where this is discussed openly? Although
>if the forum is C-oriented, I imagine mentioning C++ can be difficult.
 
Wherever it is, it is http based and not nntp based :-P
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Apr 10 01:37PM -0700

On 4/10/2018 8:22 AM, Jorgen Grahn wrote:
 
>> https://groups.google.com/forum/#!forum/lock-free
 
>> Argh!
 
> Surely there's /some/ place where this is discussed openly?
 
comp.programming.threads used to be the place a decade or so ago. Humm.
Perhaps we can try to revive it. ;^)
 
 
> Although
> if the forum is C-oriented, I imagine mentioning C++ can be difficult.
 
Well, then we go into C11. Pelles C compiler can handle that. Ahh, I
should implement my Proxy collector in C11.
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Apr 10 01:37PM -0700

On 4/10/2018 12:55 PM, Richard wrote:
 
>> Surely there's /some/ place where this is discussed openly? Although
>> if the forum is C-oriented, I imagine mentioning C++ can be difficult.
 
> Wherever it is, it is http based and not nntp based :-P
 
Argh! ;^)
Melzzzzz <Melzzzzz@zzzzz.com>: Apr 10 04:57PM

> What is the C++ reasoning for having both & and * types? Why not just
> have * types?
Because of C legacy/>
 
 
--
press any key to continue or any other to quit...
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 10 06:22PM +0100

On 10/04/2018 15:26, Rick C. Hodgin wrote:
> What is the C++ reasoning for having both & and * types?  Why not just
> have * types?
 
So you can refer to an object without using pointer semantics.
 
/Flibble
 
--
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates
a world that is so full of injustice and pain. That's what I would say."
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 10 07:45PM +0200

On 10.04.2018 19:22, Mr Flibble wrote:
>> What is the C++ reasoning for having both & and * types?  Why not just
>> have * types?
 
> So you can refer to an object without using pointer semantics.
 
That's right.
 
Bjarne added references to support user-defined operators. Without
references they would be really ugly and not like built-in operators.
 
I think that tidbit came from his "evolution" book, which I don't have,
sorry. Googling will probably find references. Maybe.
 
 
Cheers!,
 
- Alf
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)