Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #119933 > unrolled thread

Something about my ideal C/C++

Back to article view | Back to comp.lang.c++

Contents

  Something about my ideal C/C++ wij <wyniijj5@gmail.com> - 2024-08-29 09:08 +0800
    Re: Something about my ideal C/C++ Mad Hamish <newsunspammelaws@iinet.unspamme.net.au> - 2024-08-30 13:34 +1000

#119933 — Something about my ideal C/C++

Last time talked with David, we had a differnet view of assembly (might be just
differnet wording).
Then I think now, C/C++ is essentially not very different from assembly, for
example, if we use bits-specified types:

 int16_t a=2;
 int8_t b=a;
 uint32_t c=a;

Such coding is not really different form assembly. But if we use int/char/long:

 int a=2;
 char b=a;
 long c=a;

Looked better for portibility by naming the 'registers' differently and let
the language to dicede. (Assembly can also achieve some level of portibility, 
just not as widely as C). Others should be mostly function calling convention.
What else?

I am not saying assembly is better than high level language, but that assembly
is not that scary, esp. if tools are as rich (one of my commercial DOS app. is
still continuously runging today for more than 25 years every minute (a server,
even thunder strikes is no problem).

If I look at the 'high level' language now, I feel the real thing is the removal
of 'comment' and thus (much) lesser routine codes. I can only explain this from
physiological view that human working memory (short term memory) is very 
limited. IOW, features of high level languages may just be human factors:
Too many 'irrelevant' codes (depending on the purpose of the viewer) on screen 
will cause problems for human. That is what I now thought, probably not really 
some other reasons.
To verify this view, suppose we have a large (or high resolution) screen, or
something like HTML hyper-link that allow us to see the detail at will...
at least, lots of the view of what source code might change, and thus the 
language.

By using high level (shorter) languages, the first thing is the model. What is
the model of C/C++?. No language I know is precise about the model.
The 2nd thing, the language is inevidently explained in TM language, i.e. the
key part (or 'mnemonic') of the language (still) has to be interpreted in TM
language (if you really think it is something else. There will be problems, and
new language/keywords may add new problems).
The 3rd. problem is that complexity does not go away. It does not disapper
because you call it 'exception' (the bad for 'exception' is that it disable you to use 'exception' in
thinking) or whatever, the real exception (or whatever)
will go way or thus handled. What can appear in assembly will (mostly) also
appear in high level language.

I like to use higher level language, just to express some possible properties
about the 'ideal high level language' (from assembly) I can hope for.

[toc] | [next] | [standalone]

#119959

On Thu, 29 Aug 2024 09:08:43 +0800, wij <wyniijj5@gmail.com> wrote:

>Last time talked with David, we had a differnet view of assembly (might be just
>differnet wording).
>Then I think now, C/C++ is essentially not very different from assembly, for
>example, if we use bits-specified types:

Have fun building an enterprise level web-app in assembly
>
> int16_t a=2;
> int8_t b=a;
> uint32_t c=a;
>
>Such coding is not really different form assembly. But if we use int/char/long:
>
> int a=2;
> char b=a;
> long c=a;
>

Variable definition is a very small part of a language, and most
languages have large standard libraries which provide a lot of
functionality

>To verify this view, suppose we have a large (or high resolution) screen, or
>something like HTML hyper-link that allow us to see the detail at will...
>at least, lots of the view of what source code might change, and thus the 
>language.

That's part of why you split things into functions
you see 
list.sort()
and you can go to the sort function to see how it's sorted if it's
relevant (say you're investigating something not being sorted
correctly or the sort being slow)
>
>By using high level (shorter) languages, the first thing is the model. What is
>the model of C/C++?. No language I know is precise about the model.

C++ supports multiple models

>The 3rd. problem is that complexity does not go away. It does not disapper
>because you call it 'exception' (the bad for 'exception' is that it disable you to use 'exception' in
>thinking) or whatever, the real exception (or whatever)
>will go way or thus handled. What can appear in assembly will (mostly) also
>appear in high level language.

The complexity can be managed more easily and a lot of things are
handled automatically by the compiler or run time
>
>I like to use higher level language, just to express some possible properties
>about the 'ideal high level language' (from assembly) I can hope for.
>

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web