How would you design C's replacement?

[Keith Thompson]

A lot of machines don't really have a NOP instruction. The assembler is
free to pick whichever instruction it likes, that does nothing.

Ok, but I'd say that's a narrow special case that doesn't affect
the fundamental nature of the language. On SPARC, for example,
the recommended NOP instruction is "sethi 0, %g0".

In effect, for a CPU with no specific NOP instruction, "NOP" is
effectively macro.

If assemblers for a given CPU commonly generate *different*
do-nothing instructions for a NOP in the assembly language input,
then yes, that's a counterexample to my assumption. But it's a minor
one, and not something of the magnitude that Rui Maciel has asserted.

 

[88888 Dihedral]

Rui Macielæ–¼ 2012å¹´5月1日星期二UTC+8上åˆ4時29分50秒寫é“：

I believe it can be argued that the C programming language is already a
"fake assembly language" as it is.


Rui Maciel

Rui Macielæ–¼ 2012å¹´5月1日星期二UTC+8上åˆ4時29分50秒寫é“：

I believe it can be argued that the C programming language is already a
"fake assembly language" as it is.


Rui Maciel

OK, lets be serious about embedding assembly languages into C to become
some part of the C language standard.

I don't expect C++ to take over this part of C.

But mixing assembly parts and C programs together in system programming were around for more than 20 years in GCC, MSVC, TURBO C, and BCC.

 

[Ian Collins]

Le 02/05/12 16:35, James Kuyper a écrit :
On 05/02/2012 08:40 AM, Jens Gustedt wrote:
Am 05/02/2012 08:02 AM, schrieb Ian Collins:

It can where the type can be deduced, the standard uses an example:

auto x1 = { 1, 2 }; // decltype(x1) is std::initializer_list<int>

You mean the C++ states this, I suppose. Could you translate that into
something for C? int[2]?

std::initializer_list<> is a relatively new standard library template.
It's too new for me to be very familiar with it; I stopped paying close
attention to the C++ standard around the time they started preparing the
2003 standard. Key sections mentioning initializer lists seem to be
8.5.4,13.3.3.1.5, and 18.9. I've no idea whether the concept could or
should be adapted to C; I think that C might need to take a simpler
approach to the cases where C++ relies upon initializer lists.

And what would the users gain from such a construct?

A trivial example might be something like:

auto in = fopen("x", "r" );
auto out = fopen("y", "w+" );

char buf[64];

// what does fread return?
//
auto toWrite = fread( buf, sizeof(buf), 1, in );

if( toWrite )
{
auto written = fwrite( buf, sizeof(buf), 1, out );

if( written != toWrite ) { /* report error */ }
}

In C++ with the template stuff it is maybe necessary, but in C???

I agree the feature is much more important to C++ than to C, but handy
none the lass.

Handy perhaps, but detrimental to readability and troubleshooting.
Now I have to infer the type of each 'auto' variable by remembering
the return type of each function, as well as any conversions that may
happen under the hood.

Why? Isn't the point not having to know?

Without knowing exactly what 'fread' returns,
it's not clear whether the return type is a int, size_t, or even bool,
and from the context of the next 'if' statement, 'toWrite' could
easily be interpreted as the name of a boolean variable when it's
actually a 'size_t'.

But does it matter if the logic is clear? Let the programmer focus on
the logic and leave the types and conversions to the compiler.

I would not label this a "gain" for C. Your example is but a taste of
how bad 'auto' would be if used liberally.

I agree it could be seen as auto abuse, but I given implicit int is no
more, in the above example "auto" could be removed altogether...

 

[Ian Collins]

I do it all the time, when writing C code (which admittedly isn't that
often).

The two main compilers I use don't give a warning, not with the default
options anyway.

Don't your unit tests fail?

 

[gwowen]

Excuse me but how should that work?

auto foo = 45;

What should that be?

It's an int. We know this because the (C++) standard says how
literals acquire implicit types, because its important (mainly) for
function overloading.

"An integer literal is a sequence of digits that has no period or
exponent part. An integer literal may have a prefix that specifies its
base and a suffix that specifies its type. The type of an integer
literal depends on its form, value, and suffix. If it is decimal and
has no suffix, it has the first of these types in which its value can
be represented: int, long int;"

45U is an unsigned int.

char, short, int, long long, unsigned char, unsigned short, unsigned int
or unsigned long long?

ALL those types qualify actually. Even float and double qualify also.

But the C++ standard says which one counts. The C standard doesn't
because there's no where that it matters. If you want a floating
point literal, use a decimal point.

auto f = 45.; // That's a double

And this:

auto x = 'a';

"A character literal is one or more characters enclosed in single
quotes, as in ’x’, optionally preceded by the letter L, as in L’x’.A
character literal that does not begin with L is an ordinary character
literal, also referred to as a narrow-character literal. An ordinary
character literal that contains a single c-char has type char..."

Is that a char? an int?

It's a char. Again C++ has these rules, and they're pretty much ass
you'd expect (if it looks like a char, its a char...)

In C++ with the template stuff it is maybe necessary, but in C???

I agree. With the present simple type system, . But some of the
suggestions made here for C improvement (namespaces, function
overloading) will complicate the type system to the extent that there
may be some gain. It really is easier to type:

auto it = container->first_element();

rather than

struct bobs_namespace::vector_of_float::iterator it = container-

first_element();

and its makes it easier to change the type of container without
invalidating vast swathes of other code.

 

[Guest]

C's ubiquity comes in various forms, not only as run anywhere but also
find a programmer anywhere.

Most of the embedded projects I have been involved with recently use gcc
and a decent subset of those used gcc and a Linux kernel. One of my
first questions I asked on joining those projects was "why don't you use
C++?" and the answer invariably boils down to "we use what we are
familiar with".

So if it's hard to find experienced developers for the most popular C
derived language, I'd hate to be the one promoting a new one!

where did they say they'd had a problem finding C++ programmers? Sometimes it's just very conservative management.

 

[Guest]

On Monday, April 30, 2012 9:01:17 AM UTC+1, Malcolm McLean wrote:

We also need a bigger standard library. Things like hash tables, regular expressions, directory functions, port access for internet programming, SQL, and the ability to open a graphics window shouldn't have to rely on 3rd party libraries.

even C++ doesn't do SQL and graphics! Whose graphics would you standardize on? Im not sure I want an RDMS on my toaster.

 

[Ian Collins]

where did they say they'd had a problem finding C++ programmers? Sometimes it's just very conservative management.

On at least two of those projects, I was the management!

 

[Guest]

בת×ריך ×™×•× ×©× ×™, 30 ב×פריל 2012 17:09:07 UTC+1, מ×ת James Kuyper:

"use our graphics library or the dog gets it"

It doesn't really matter what you call a 3d point. Even a novice programmer, provided he was sane, could come up with a perfectly good typedef or convention, which could be used worldwide with no harm.
In this case, it is a problem of designated authority.

an openGl vertex has 4 coordinates

 

[Rui Maciel]

I disagree. In my opinion (and I'm not 100% certain that this
is standard terminology), the distinction between an assembly
language and a non-assembly language is fairly unambiguous.
As I said upthread, an assembly language program specifies CPU
instructions; a program in a non-assembly language, including C,
specifies run-time behavior.

I don't believe you are wrong; quite the opposite, in fact. The only issue
I have is that if we consider that assembly code with macros is also
assembly code, as is assembly code which calls routines stored in a library,
then we accept that at least a certain amount of abstraction, one which
takes us away from specifying instructions and leads us to specify run-time
behaviour, is also compatible with the concept of an assembly language.
This is the grey territory I was referring to.


Rui Maciel

 

[Guest]

news:[email protected]...

All the high-level assembler kind of languages I've used or created, were
generally far lower level than C (although most were some time ago too).


Probably not. But C is actually rather higher level than it's given credit
for. That also means it's not as great at doing low-level stuff as people
think. I only recently tried to use C as a target language for intermediate
code (no control structures, and the simplest possible expressions), yet
there were still a few problems in doing exactly what I wanted it to do.

(In the end I opted for generating assembly code directly; I know I can get
it to do anything, and I don't have a C compiler messing with my
intermediate code doing who knows what to it.)

yes, I was writing an interpreter in C and had a deep need for a jump table.
had to make do with a goto and a switch

 

[Guest]

[quote re-arraged slightly]

i have 2 definition of assembly language...
"assembly is a language write in ascii chars in .txt
code file, that allow to control
each instruction cpu execute in the translated .exe file"
ok.

"one assembly language is a language each program one can invent
with it...
it is possible to make a partition on the .txt assembly source code
in the way
each .txt piece of text of partition generate one cpu instruction
and vice versa each .exe instruction came from one .txt piece of text
of the partition"

I've no idea what any of that means

i want nothing, i already have all one programmer can wish: one
x86cpu 32 bit and one assembly language for that cpu...
nothing in this is "fake": it is each on or off

tough if you don't program on a x86. as you say, this isn't "fake assembly language"

for the C language the only flaw i see it is in its type definitions...
i claim fixed size types as in
u8 == unsigned 8 bit
u16 == unsigned 16 bit

<etc>

I've never found much use for 'em. I like a Byte or Octet type because it clarifies the usage.

are good because less UB in arithmetic with these types
and all composed type of these types would be
accessible/portable to other languages other programs etc

wasn't there a guy a while back who was into Portable Assembly Language? PASM?

for to have one portable assembly first one
has to have one portable cpu [or virtual cpu]

at which point the assembler ceases to be portable. I don't agree the terms"portable assembler" or "fake assembler" are meaningful but people still use them. In other words you want to reduce the useful of C by embedding theassembler for a single architecture.

the above speech is ok not only for C but
for all other languages too

you do ralise there are more ARM processors shipped than x86s?

 

[Guest]

That's being a little elitist.

it doesn't take long. I suffered the pain when I moved from Pascal to C. I even went though a phase of typeing == for assignment!

Why shouldn't anyone be able to use the language,

because that will never be true for any programming langage

for example those who have to program other languages too?

Fortran? Lisp? Perl/Python?

And the fix is easy: use different symbols for assignment and equality.

I know its easy but of the top of my head I can think of several possibilities. I wondered which one was being proposed.

Pascal := =
FORTRAN = EQ
scheme set! = eq eqv equal

and of course C's descendents have (mostly) followed C

By
using the natural "=" symbol for equality, you won't then fall into the trap
of using it by mistake instead of the very 1970s-looking "==".

Or use two symbols for assignment; one that returns the value of the left
side ("="), and one which returns void (eg. ":="). This could be added to C
today. It won't eliminate the problem, but can reduce it.

I'm not sure how that helps

 

[jacob navia]

Le 02/05/12 20:44, BGB a écrit :

AFAIK, absent anything else, the default type here is 'int'.

Then you can NEVER initialize types short or char with a constant.
Unless you make a cast:

auto foo = (short)45;

What is worst than the more concise

short foo =45;

 

[88888 Dihedral]

(e-mail address removed)æ–¼ 2012å¹´5月3日星期四UTC+8下åˆ6時09分19秒寫é“：

it doesn't take long. I suffered the pain when I moved from Pascal to C. I even went though a phase of typeing == for assignment!


because that will never be true for any programming langage


Fortran? Lisp? Perl/Python?


I know its easy but of the top of my head I can think of several possibilities. I wondered which one was being proposed.

Pascal := =
FORTRAN = EQ
scheme set! = eq eqv equal

and of course C's descendents have (mostly) followed C
b
I'm not sure how that helps

int a,b, c;

......

if ( (a+b)>c)
{ ....} //the famous trick to force c learner's to think in registers here!

// well buggy C trick!

I proposed long time ago for the missing bit.

 

[Jens Gustedt]

Am 05/03/2012 12:14 PM, schrieb jacob navia:

Then you can NEVER initialize types short or char with a constant.
Unless you make a cast:

auto foo = (short)45;

What is worst than the more concise

short foo =45;

Sure, if you initialize from a known constant the C++ auto feature
doesn't make much sense, anyhow.

It only does where the type is somehow hidden to the eye. In C++ I
guess the most interesting case are templates. In C this would be if
you have a type generic macro à la _Generic on the right hand side.

E.g

auto x = sin(y);

where you want x to inherit the type of y, even if occasionally
somebody is changing the type of y from double to float for example

Jens

 

[BartC]

it doesn't take long. I suffered the pain when I moved from Pascal to C. I
even went though a phase of typeing == for assignment!

It takes about an hour of exposure to C to start using "=" and ";"
everywhere else. The semicolons are harmless, but "=" for assignment in one
of my other languages is not an error, but will cause a crash. It takes
longer however to learn never to use "=" for equality.

I know its easy but of the top of my head I can think of several
possibilities. I wondered which one was being proposed.

I mean different from the ones C uses now. That would be very unlikely
because a new language specifically to replace C, would not use radically
different syntax. But given the freedom to do anything, you might choose "="
for equality, and anything else for assignment; even "=" where the
assignment cannot also be an expression.

Pascal := =

Also for Ada and Algol languages. That is also what I generally use. I'd
imagine that in pseudo-code, which doesn't have hard-and-fast rules, you
might also prefer to use := for assignment, to make it completely clear what
you mean. And "=" for equality; use of "==" looks more like an identity
test.

FORTRAN = EQ

Actually it was .EQ., but I think "=" has also been used for equality,
because context determines if this is an assignment or not.

scheme set! = eq eqv equal

With more elaborate types, there might be subtly different versions of
'equality', and you may need to use different symbols. But "=" wouldhave the
most basic, obvious meaning.

I'm not sure how that helps

That idea was if := is used most of the time, then the appearance of "=" in
a condition would look more incongruous. But it might be better if = and :=
were interchangeable. Even better would be to let "=" return void, with only
":=" allowed in a condition, but that breaks compatibility.

 

[James Kuyper]

Don't your unit tests fail?

The earlier you can catch an error, the better; compile time is better
than test time.

 

[Ben Bacarisse]

I know its easy but of the top of my head I can think of several
possibilities. I wondered which one was being proposed.

Pascal := =
FORTRAN = EQ

It's .EQ. not just EQ. But, in fact, Fortran has moved on, just as C
has, and now the pair are = and == (though .eq. is still permitted of
course).

scheme set! = eq eqv equal

A few other languages have a similar requirement for more than one kind
of equality and most seem to they have gone for == and ===.

and of course C's descendents have (mostly) followed C

So has Fortran. Once you've taken = for assignment, == looks like the
natural choice for equality.

 

[BartC]

(e-mail address removed) writes:

It's .EQ. not just EQ. But, in fact, Fortran has moved on, just as C
has, and now the pair are = and == (though .eq. is still permitted of
course).

Fortran seems to have moved on a lot more than C has. Modern C syntax
doesn't look much different to 30 years ago. The glimpse I had of modern
Fortran was unrecognisable.