Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Obvious things C should do

digitalmars.com

Post reply on HN
Print view View original

301–310 of 310 posts

Re: Obvious things C should do

#301

Post by acuozzo »

The things I want most from a new C standard:

1. Fix the integer promotion rules. Obeying them as they are now makes code considerably less readable.

2. Choose one of the idiomatic approaches to type punning and make it standard. Having to use memcpy() over and over again is terrible.

3. Make casting a pointer-to-struct to a pointer to its first member supported. Stop leaving it to POSIX.

4. Make the exact-width integer types in stdint.h required. They were brazen enough to require support for long long in C99, so why not?

5. Make integer literals without type suffices be compile-time bignums.

Re: Obvious things C should do

#302

Post by marginalia_nu »

chii wrote: post #289
marginalia_nu wrote: post #210

Earlier quoted context omitted.

Even as a java programmer, I think this is a bad take. Java doesn't force separation of implementation and interface, and java interfaces also have a lot of weird stuff going on with them. Java also has too many tools for this. You both have class/interface, but also public/private. I honestly think C does it better than Java.

> java interfaces also have a lot of weird stuff going on with them. really? I know java pretty well, and there aint nothing weird there. C uses conventions to produce an "interface" (ala a header file with declarations). Java uses compilers to produce an interface, which i do really like. You can ship that interface without an implementation, and only at runtime load an implementation for example. > You both have cl…

> C uses conventions to produce an "interface" (ala a header file with declarations). Java uses compilers to produce an interface, which i do really like. You can ship that interface without an implementation, and only at runtime load an implementation for example.

You can do this in C as well, since it has separate code declarations and definitions. You conventionally put the declarations in the header and definitions in the source file. A C program can link against declarations alone, and the implementations can be loaded later using dynamic linking.

> And these are all othorgonal concerns. A private interface is for the internal organization of code, as opposed to a public one (for external consumption). That's why you might have a private interface.

But these are profoundly overlapping concerns. Interfaces also hide the internal organization of the code, and on top of this, you also have project jigzaw's modules (that absolutely nobody uses), but which also caters toward separating private implementations from public interfaces.

Re: Obvious things C should do

#304

Post by honestSysAdmin »

msm_ wrote: post #60
honestSysAdmin wrote: post #39

Earlier quoted context omitted.

Perhaps I could load the Javascript and also "login to X", but I'll instead forego reading this and pay attention to what others are writing about C.

It's also hosted here: https://www.digitalmars.com/articles/Cobvious.html

Thank you.

Re: Obvious things C should do

#305

Post by ninalanyon »

Obvious things C should do is not the same as things that C should obviously do. For instance you have to declare things in the right order in F# too and that seems to be mostly regarded as a modern language.

Re: Obvious things C should do

#306

Post by dfawcus »

WalterBright wrote: post #268
dfawcus wrote: post #223

Earlier quoted context omitted.

Metaware High-C version 1.2 (Nov 1985) had underscores in floating point and integer literals. Possibly it had that even earlier. Possibly also taken from Ada, as other text in that section of the manual reference Ada. See A.3 pg 169 (and 58+) of 235 in: https://bitsavers.org/pdf/metaware/High_C_Language_Reference...

I did not know that. Thanks for pointing it out.

mind, it is also possible that they took that from Algol 68, and 'adjusted it':

  $ a68g --strict -e '(INT a = 1 000; print((a,newline)) )'
        +1000
As Algol 68 allows spaces within numbers, as well as within identifiers.

Re: Obvious things C should do

#307

Post by fuzztester »

wruza wrote: post #282
fuzztester wrote: post #278

Earlier quoted context omitted.

Interesting. Yes, I remember the .tpu and .dcu filename extensions. IIRC, .tpu stood for turbo pascal unit, and .dcu may have meant delphi compiled unit, not sure of the latter. I don't remember the .int extension, but it would have been there, of course, if you say so. What was the use of the .int file?

It was literally the unit with implementation part just missing. Sort of a header that you can just read(?). Idk if it played a role in compilation, probably not. But some commercial libraries packaged them as well. Here, look at this random repo: https://github.com/keskival/turbo-pascal-experiments/tree/ma... -- few int files at the end of a list. This page mentions a few ints without any context: https://comp.lang.…

Got it, thanks.

Re: Obvious things C should do

#308

Post by norir »

me-vs-cat wrote: post #287
norir wrote: post #215

I consider forward references an anti-feature. I want any language I use to have the following property: if I append to the source file, I can't break previously correct code above the insertion point. Forward references both break this property _and_ requires multiple compiler passes. More generally though, it's time to stick a fork in c. To me the only sane ways to use c are as a compilation target or for quick and…

What do you mean by "break previously correct code"? Can you give an example of what you're thinking with original code and appended code, where concatenating the two (1) does not change the behavior of the original code when forward references are not allowed, and (2) changes the behavior of the original code when forward references are allowed?

in d:

  import std.stdio;
  alias string = immutable(char)[]
  void main() { bar(foo()); }
  void bar(string s) { writeln(s); }
  string foo() { return "foo"; }
now change the definition of foo:

  import std.stdio;
  alias string = immutable(char)[];
  void main() { bar(foo()); }
  void bar(string s) { writeln(s); }
  int foo() { return 1; }
This now fails to compile at line 3 even though the breaking change was made at line 5.

Re: Obvious things C should do

#309

Post by me-vs-cat »

norir wrote: post #308
me-vs-cat wrote: post #287

Earlier quoted context omitted.

What do you mean by "break previously correct code"? Can you give an example of what you're thinking with original code and appended code, where concatenating the two (1) does not change the behavior of the original code when forward references are not allowed, and (2) changes the behavior of the original code when forward references are allowed?

in d: import std.stdio; alias string = immutable(char)[] void main() { bar(foo()); } void bar(string s) { writeln(s); } string foo() { return "foo"; } now change the definition of foo: import std.stdio; alias string = immutable(char)[]; void main() { bar(foo()); } void bar(string s) { writeln(s); } int foo() { return 1; } This now fails to compile at line 3 even though the breaking change was made at line 5.

I am unable to fit that example in this prior description: "if I append to the source file, I can't break previously correct code above the insertion point". Can you help me by providing the "previously correct code" and the "appended code" which causes the break after being appended?

Re: Obvious things C should do

#310

Post by me-vs-cat »

norir wrote: post #308
me-vs-cat wrote: post #287

Earlier quoted context omitted.

What do you mean by "break previously correct code"? Can you give an example of what you're thinking with original code and appended code, where concatenating the two (1) does not change the behavior of the original code when forward references are not allowed, and (2) changes the behavior of the original code when forward references are allowed?

in d: import std.stdio; alias string = immutable(char)[] void main() { bar(foo()); } void bar(string s) { writeln(s); } string foo() { return "foo"; } now change the definition of foo: import std.stdio; alias string = immutable(char)[]; void main() { bar(foo()); } void bar(string s) { writeln(s); } int foo() { return 1; } This now fails to compile at line 3 even though the breaking change was made at line 5.

I am unable to fit that example in this prior description: "if I append to the source file, I can't break previously correct code above the insertion point".

Your foo() example above has code which has been changed, rather than "if I append to the source file". (I re-read my prior comment and realized this may not have been clear.)

That a change to code can introduce a bug is something we've all seen. But your prior description is not any kind of change, it was specifically an append. In the context of forward references, I am curious to see something that matched your prior description.

Post reply on HN