@hth313

In other words: Only use C as a backend for a higher level language.

@Samurai_Crow

Just to be a contrarian, I suppose:

When creating a static-link library or a dynamic shared object (for a non-C++ client), I prefer to implement the logic in C++ - with re-usable portions maintained in a common-code repository - but I create stubs and headers for C, by which the library's (opaque) types and functions are exposed. That said, in such cases I restrict dependencies to an absolute minimum.

For C++ projects, I use a class factory pattern instead.

Last edited by Snorg on 04-Apr-2019 at 09:41 AM.

@hth313

Quote:

Proper constants is probably also a good idea.

I'm not sure what you mean by that. C has 'const', which is kind of a misnomer, since they are really read-only variables, and it has pre-processor defines, which to the compiler are just literals, so my guess is that you are referring to named constants that have name/type information in the symbol table, but then again... you might mean something completely different.

Quote:

However, there is no need to change the preprocessor, just because it can be abused we should not do it, instead we should provide better alternatives ways.

We can't change C; it's too late for that. But I don't think it would be a good idea to replicate the C pre-processor in a new language.

I refactor and port a lot of C code, and the biggest thing I run into are bad abstractions in/with header files -- people tend to not know what should go in there and what shouldn't. It's a lot of work to get that all untangled and sorted out without breaking anything. This is especially a problem when someone defines storage in a header file, which ends up getting redefined somewhere else, and the linker can't figure out which instance to use.

I would like to have a C-like language where all objects have internal linkage by default, and anything that requires external linkage is marked with a keyword such as 'public'. Such a language could still use header files, but they would be generated by the compiler.

Last edited by bison on 04-Apr-2019 at 05:11 PM.

_________________
"Unix is supposed to fix that." -- Jay Miner

@Samurai_Crow

Quote:

In other words: Only use C as a backend for a higher level language.

This is actually a really good idea. I experiment with language design, but I don't have the necessary knowledge or skills to design and implement the back-end of a compiler, so I write source-to-source compilers that output C, which I then compile with gcc or clang.

Last edited by bison on 04-Apr-2019 at 05:07 PM.

_________________
"Unix is supposed to fix that." -- Jay Miner

@cdimauro

Quote:

Processing n-times includes actually INCREASES the compile time.

I don't disagree with that, but it allows you to also split up your project, and only compile parts of it, as the .o files can be compiled only if .cpp or .h file is changed if the makefile is correctly setup.

Let's say you have 10 .cpp files, and you changed two .cpp files, you only compile two .cpp files not 10, this cuts down compile time a lot. (Just don't change structs/classes inside .h files as then you might need to recompile everything, that is what "make clean" is for.)

However, I agree that pascal / Delphi has many advantages, but it is just a different beast.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@bison

Quote:

so I write source-to-source compilers that output C, which I then compile with gcc or clang.

And thats saves you from learning 10 different machine code languages.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Quote:

And thats saves you from learning 10 different machine code languages.

That's 9 more than I know right now.

I used to know a bit of 68000 and MIPS, but those have kind of slipped away from me.

_________________
"Unix is supposed to fix that." -- Jay Miner

Quote:

bison wrote: Quote: Proper constants is probably also a good idea. I'm not sure what you mean by that. C has 'const', which is kind of a misnomer, since they are really read-only variables, and it has pre-processor defines, which to the compiler are just literals, so my guess is that you are referring to named constants that have name/type information in the symbol table, but then again... you might mean something completely different.

No, you nailed it.

With proper constants I mean variables that looks like real variables in the source, are recognized as such by the debugger, but do not take up any storage space unless one takes the address of it. C almost allows for this, but there are a couple of problems. The constant has to be placed in a header which gives multiple definitions to the linker, unless the compiler is instruction somehow to generate weak definitions. Even having this, people cannot trust that such mechanism always exist (the code is to be portable) and resort to #defines. I am not sure about how well debuggers of today deal with defines and are able to know about them and treat it nicely. The C preprocessor has always been a kludge in this regard as it textually alters the program without understanding a thing about what is going on.

@Trekiej Quote:

Trekiej wrote: Pseudo Code: The Language of the Ancients

Python: executable pseudo-code. The Language of Wisemen.


@hth313 Quote:

hth313 wrote: @bison @cdimauro I do not entirely agree... C is a low level language, much like a processor independent assembler and we all know about macro assemblers. They are not ideal, but it is a pragmatic way of getting a lot of strange and messy things done in a fairly standardized way. What should be done is to improve the language to avoid certain dangerous overuse, most well known is the small functions expansions inline. This should be done using an optimizer that inlines ordinary code, which gcc at least seems to allow for. Proper constants is probably also a good idea. However, there is no need to change the preprocessor, just because it can be abused we should not do it, instead we should provide better alternatives ways.

The problem is that the preprocessor was added to C to avoid implementing better, higher-level, constructs.

Some were introduced from time to time (consts & enums), some were introduced in C++ (namespaces to avoid using macros to add prefixes or suffixes to symbol names, in order to minimize identifiers clashes. Inline).

Some are still missing (no module concept).

@hth313 Quote:

hth313 wrote: Quote: bison wrote: I'm not sure what you mean by that. C has 'const', which is kind of a misnomer, since they are really read-only variables, and it has pre-processor defines, which to the compiler are just literals, so my guess is that you are referring to named constants that have name/type information in the symbol table, but then again... you might mean something completely different. No, you nailed it. With proper constants I mean variables that looks like real variables in the source, are recognized as such by the debugger, but do not take up any storage space unless one takes the address of it. C almost allows for this, but there are a couple of problems. The constant has to be placed in a header which gives multiple definitions to the linker, unless the compiler is instruction somehow to generate weak definitions. Even having this, people cannot trust that such mechanism always exist (the code is to be portable) and resort to #defines. I am not sure about how well debuggers of today deal with defines and are able to know about them and treat it nicely. The C preprocessor has always been a kludge in this regard as it textually alters the program without understanding a thing about what is going on.

Exactly.

@NutsAboutAmiga Quote:

NutsAboutAmiga wrote: @cdimauro Quote: Processing n-times includes actually INCREASES the compile time. I don't disagree with that, but it allows you to also split up your project, and only compile parts of it, as the .o files can be compiled only if .cpp or .h file is changed if the makefile is correctly setup. Let's say you have 10 .cpp files, and you changed two .cpp files, you only compile two .cpp files not 10, this cuts down compile time a lot. (Just don't change structs/classes inside .h files as then you might need to recompile everything, that is what "make clean" is for.)

This already happens with other languages as well.

However even compiling a single file which changed, they don't require to re-parse again all include files which are used inside it: they just import the symbol table from the compiled code.
Quote:

However, I agree that pascal / Delphi has many advantages, but it is just a different beast.

Exactly: a beautiful beast with some clean and nice solutions for the problems which we discussed.

@cdimauro

Quote:

Some were introduced from time to time (consts & enums),

I've never been very happy with either construct in C. I think the standardization committee pulled the trigger too soon -- they should have studied the problem longer instead of just adopting extensions that compiler writers at the time were adding to the language.

_________________
"Unix is supposed to fix that." -- Jay Miner

@Everyone

I vote for a cleaned-up, debugged,extended (Add the equivalent of Structs, Matrix operations, a few extra system constants [Pi, InToCm, that kind of thing] and multitaking (including setting Priorities), and of course, as used in GWBASIC, Shell(). And any others you can think of....)

And, of course, a much improved editor--to go with a much improved programer!

Oh, I may just be prejudiced, I've got about a gig 1/2 of legacy BASIC code floating around.....

@pgf_666

You forgot to mention which dialect of BASIC you want updated. I know how to implement BASIC as a pass-and-a-half transpiler using C as a backend. I was considering doing one based on AMOS Kittens.

@hth313

Quote:

With proper constants I mean variables that looks like real variables in the source, are recognized as such by the debugger, but do not take up any storage space unless one takes the address of it.

In what scenario would you take the address of a constant? There may be one, I just can't think of it.

Quote:

C almost allows for this, but there are a couple of problems. The constant has to be placed in a header which gives multiple definitions to the linker, unless the compiler is instruction somehow to generate weak definitions. Even having this, people cannot trust that such mechanism always exist (the code is to be portable) and resort to #defines.

This works with gcc; I haven't tried other compilers.

bison@home ~/source/const $ cat foo.c
const int Foo = 42;

bison@home ~/source/const $ cat foo.h
extern const int Foo;

bison@home ~/source/const $ cat const.c
#include <stdio.h>
#include "foo.h"

int main()
{
    printf("%d\n", Foo);
    return 0;
}

bison@home ~/source/const $ cat Makefile
CC = gcc
CFLAGS = -std=c89 -Wall -Wextra -pedantic

const: foo.o
$(CC) $(CFLAGS) -o const const.c foo.o

foo.o:
$(CC) $(CFLAGS) -c foo.c

bison@home ~/source/const $ gcc --version
gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0
[snip]

bison@home ~/source/const $ make
gcc -std=c89 -Wall -Wextra -pedantic -c foo.c
gcc -std=c89 -Wall -Wextra -pedantic -o const const.c foo.o

bison@home ~/source/const $ ./const
42

To be continued... (I want to press the "Submit" button before the whole thing blows up.)

---

So it seems that one can declare a const-qualified variable in a header without initializing it, so long as the definition is initialized elsewhere, which means that it will not be instantiated when the header is included in a source file. Either I didn't know this, or else I knew it and forgot.

Last edited by bison on 12-Apr-2019 at 07:49 PM.
Last edited by bison on 12-Apr-2019 at 07:26 PM.

_________________
"Unix is supposed to fix that." -- Jay Miner

@hth313

This post is a continuation of the previous post, which can no longer be edited due to bugs in the forum software. (I don't think it likes certain HTML escape sequences.)

Quote:

With proper constants I mean variables that looks like real variables in the source, are recognized as such by the debugger, but do not take up any storage space unless one takes the address of it. C almost allows for this, but there are a couple of problems.

The thing I don't like about C const variables is that they can't be used as case labels, since they (const variables) are not really "constant constants."

Last edited by bison on 12-Apr-2019 at 07:34 PM.

_________________
"Unix is supposed to fix that." -- Jay Miner

Duplicate post.

Last edited by bison on 12-Apr-2019 at 07:49 PM.

_________________
"Unix is supposed to fix that." -- Jay Miner

@bison

A constant is like a variable, so someone might want to pass it by pointer to a function or similar. It is nothing strange language-wise, though perhaps not so common thing to do.

Yes, you can put a constant in a header with extern and no initializer, but then all files except the one that defines it knows the value of the constant, so it cannot be treated as a value everywhere and needs to be loaded from memory, taking up memory space.

Good point about the case constants. Maybe it is fixable if "proper" constants were accepted in the language. Enum types can be an alternative in this case.

@hth313

Quote:

I am not sure about how well debuggers of today deal with defines and are able to know about them and treat it nicely.

I always assumed that it was not possible to print defined constants in a debugger, since by the time the compiler reads the source the defines have all been replaced, but as it turns out, gcc will insert debugging symbols for defines if the debug level is set to 3.

bison@home ~/source/print-defines-in-gdb $ cat test.c
#define FOO 42

int main()
{
  return 0;
}

bison@home ~/source/print-defines-in-gdb $ cat Makefile
CC = gcc
CFLAGS = -std=c89 -Wall -Wextra -pedantic -g3

test:
$(CC) $(CFLAGS) -o test test.c

bison@home ~/source/print-defines-in-gdb $ make
gcc -std=c89 -Wall -Wextra -pedantic -g3 -o test test.c

bison@home ~/source/print-defines-in-gdb $ gdb test
GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git

[snip]

Reading symbols from test...done.
(gdb) break 1
Breakpoint 1 at 0x5fe: file test.c, line 1.
(gdb) run
Starting program: /home/bison/source/print-defines-in-gdb/test

Breakpoint 1, main () at test.c:5
5 return 0;
(gdb) print FOO
$1 = 42
(gdb)

Last edited by bison on 16-Apr-2019 at 04:47 PM.
Last edited by bison on 16-Apr-2019 at 04:43 PM.

_________________
"Unix is supposed to fix that." -- Jay Miner

@thread
Does anyone here like Julia programming?

_________________
John 3:16

@Trekiej

Julia is my girlfriend, I programmed her. She already does what I want.

@Trekiej

Never tried it, but the fact that it's homoiconic (code == data) is interesting.

_________________
"Unix is supposed to fix that." -- Jay Miner