bug raport - about way of linking in c

[Ian Collins]

I wrote on this before many times in this messages tree

1. local linking i see as a fix to the present c - it will break no line

2. other improvements makes a distinct language I work on almost 10 years (maybe not such many but I forgot when it had begun) I used to call it C2 as a 'codename'

I Said here on about 4 improvements, some
other I am thinking on are also:

1) realloc keyword

int tab[1000];

realloc tab[2000];

- it will make a new dynamic memory paradigm
(or almost) other than both GC and no
malloc/free - like management - labels/handlers
ale never disjoined with ram content here

This doesn't make a great deal of sense..

2) larger structures are passed (in and out) by
hideen adress, return value is always on upper
scope so there are no waste on passing

struct float3 {float x,y,z};

(float3) cross(float3 x, float3 y) //by adr not value
{
return { x.y * y.z - x.z * y.y,
x.z * y.x - x.x * y.z,
x.x * y.y - x.y * y.x} //thru addr fill to ram on upper scope

//...
}

(important - this one is efficient
and handy one, fills holes in present c)

What you are describing there is pass by reference and return value
optimisation (RVO), both present in C++.

3) couple of other ideas

ex 'build in' types
float3 or float4 float8 int4 etc related to sse/avx types, accelerated by sse operations on such
types

This could probably be implemented in current C++. Maybe you are
working in the wrong language?

 

[Kaz Kylheku]

I wrote on this before many times in this messages tree

1. local linking i see as a fix to the present c - it will break no line

Well, not as far you're able to see.

Anyway, you should join the ISO C committee; you'd be in excellent company.

2. other improvements makes a distinct language I work on almost 10 years
(maybe not such many but I forgot when it had begun) I used to call it C2 as
a 'codename'

URL to code repository, or it didn't happen.

 

[fir]

W dniu czwartek, 4 października 2012 00:35:29 UTC+2 użytkownik Kaz Kylheku napisał:

Well, not as far you're able to see.



Anyway, you should join the ISO C committee; you'd be in excellent company.








URL to code repository, or it didn't happen.

Will make a compiler (codename 'fury'),
but makin such compiler is much easier than
workin out such improvements - I guarantee,

Compiler is a piece of cake compared to
thoutghts needed to find out such things

 

[Keith Thompson]

W dniu środa, 3 października 2012 23:07:47 UTC+2 użytkownik Keith Thompson napisał:

The main benefit here is trashing out header files which i
dislike.. (not to much will change but there should be a way to
contain type definitions in .obj files etc)

If you eliminate header files, you're making a radical change to the
C language, big enough that I wouldn't even call the new language
"C". It would break every non-trivial C program that's ever been
written. Even C++ didn't do that.

If you add your "modules" feature to the language without eliminating
header files, than you have two separate mechanisms with overlapping
functionality, which will make learning the language that much
more difficult.

You probably have some good ideas, but I don't think they can fit
into C. If you want to proceed with this, I suggest you invent
a new language. You can base it on C as much as you like, but I
advise against calling your new language "C". (The name "D" is
already taken; see <http://dlang.org/>. In fact, D may have some
of the features you like; for example, it uses `import std.stdio;`
rather than `#include <stdio.h>`.)

I also advise you to gain a very strong understanding of C as it's
currently defined if you want to base a new language on it.

[...]

void main()

And in your own language, you can use "void main()" as much as you like.
In C, it's wrong. (That's not *quite* accurate, but it's close enough.)

Please take the time to clean up the extra blank lines that
Google Groups inserts so the rest of us don't have to. You can
copy-and-paste your article from the web form into a text editor, fix
it up, then copy-and-paste it back into the web form. (Or consider
using an interface other than the horribly broken Google Groups.)

I blame Google for this, but there are things Google user can do
to alleviate the damage.

I wrote on this before many times in this messages tree

1. local linking i see as a fix to the present c - it will break no line

2. other improvements makes a distinct language I work on almost 10
years (maybe not such many but I forgot when it had begun) I used to
call it C2 as a 'codename'

Whatever you may have written many times before, I was responding
to one specific message, which proposed incompatible changes to C.

If you want to create a new language with such features, go ahead
(many others have done similar things). But comp.lang.c exists to
discuss C, not your new language.

I Said here on about 4 improvements, some
other I am thinking on are also:

[big snip]

None of which I was commenting on.

 

[Keith Thompson]

W dniu środa, 3 października 2012 23:07:47 UTC+2 użytkownik Keith Thompson napisał:

in my version : as I said

module main;
reaches stdio;

char* main(char* in)
//(or close couse sizes and maybe other info should be sent too)
{

}

That's nice, but it's not C. There's a comp.lang.misc newsgroup
that might be a more appropriate place to discuss your new language.
(I don't know how active it is these days.)

got deep understanding of the thing I call "Spirit Of C"

I don't doubt that you understand what *you call* the Spirit of C.
That doesn't mean you have a deep understanding of the C language
itself.

It's a minor point, but your insistence on writing "void main()", and
your lack of acknowledgement of my explanation of the reasons it's a bad
idea, does not imply a deep understanding of the currently defined C
language.

 

[Stephen Sprunk]

W dniu czwartek, 4 października 2012 00:35:29 UTC+2 użytkownik Kaz
Kylheku napisał:

Will make a compiler (codename 'fury'), but makin such compiler is
much easier than workin out such improvements - I guarantee,

Compiler is a piece of cake compared to thoutghts needed to find out
such things

If you think so, that is only because you've never actually written a
compiler, which makes me wonder what you've been _doing_ for the last
ten years, especially since you don't even realize that you've
reinvented namespaces--a concept that is a lot more than ten years old.

A compiler for C, which has been tweaked for ~40 years and now well
understood, is hard enough. A compiler for a language with the features
you propose (which is _not_ C, and is therefore off-topic here) will be
even harder.

S

 

[Stephen Sprunk]

Building-in a permanent prefix into a name is not the same as having
namespaces. Otherwise no-one would have bothered inventing them.

Having namespaces as a native language feature allows some syntactic
sugar, such as being able to leave the prefix off in some cases, but
that's about it.

If you look at how C++ namespaces are implemented in common ABIs,
they're just translated to prefixes by the name-mangling system--which
you can do just fine in C without needing a special language feature,
though in some cases a slight bit more typing is required.

There is a considerable advantage to having a full 'name' made up of
two or more parts. We all benefit from 'namespaces' as used in
hierarchical file systems, and from having forenames and surnames!

Yet there are still collisions even with multi-part names, so it's not a
perfect solution.

S

 

[Stephen Sprunk]

W dniu wtorek, 2 października 2012 15:05:17 UTC+2 użytkownik Stephen
Sprunk napisał:

The difference is huge -

If you have namespaces and modules you have two 'beings' (modules and
namespaces) In my proposal you have only modules - and you dont need
namespaces - its much simpler

You are still missing the point. Your modules _are_ namespaces. There
are not two "beings"; there is one thing with two names: "modules" (what
you call it) and "namespaces" (what everyone else calls it).

S

 

[Kaz Kylheku]

W dniu czwartek, 4 października 2012 00:35:29 UTC+2 użytkownik Kaz Kylheku napisał:

Will make a compiler (codename 'fury'),
but makin such compiler is much easier than
workin out such improvements - I guarantee,

Compiler is a piece of cake compared to
thoutghts needed to find out such things

URL to piece-of-cake compiler, or it didn't happen.

 

[fir]

W dniu czwartek, 4 października 2012 01:57:22 UTC+2 użytkownik Stephen Sprunk napisał:

You are still missing the point. Your modules _are_ namespaces. There
are not two "beings"; there is one thing with two names: "modules" (what
you call it) and "namespaces" (what everyone else calls it).

this above is wrong - by module I mean as
I said .obj file and its corresponding
source file (or files if you would tear
it up on many files - but If one would
like to divide module code on pieces I
would reccomend to divide it on binary
level)

If the concept I mean would be namespace
thet namespuce then would be divided its
containing constents on binary level into
distinct binary modules, namespace is not
about it - module is module (related to
binary level code divisions0, namespace
is namespace (manage names in a way) -
this what I was talking was about modules

 

[fir]

W dniu czwartek, 4 października 2012 00:23:05 UTC+2 użytkownik Ian Collins napisał:

What you are describing there is pass by reference and return value
optimisation (RVO), both present in C++.

nay, this is improvement to both c(&way)
and c++ tangled way (though I had some
hesitations to it and to some other
improvements I still also have in some extent0

It gives clean looking code

Smth1 x, Smth2 y = foo(smth3, smth4);

it is easier to write c programs with that,
also it is fully efficient compared to
this(&c, &way) but gives inout and output checking and it is nicer on both client
and function body side

(it looks nice and is important, though
I also like the old c and got deep 'respect'
to it, so when I compare it with old c syntax
I feel afraid to some extent, not sure if
such thing preserve the spirit of old c :-(
This are complex matter and I plan to work on it
yet

 

[Ian Collins]

W dniu czwartek, 4 października 2012 00:23:05 UTC+2 użytkownik Ian Collins napisał:

nay, this is improvement to both c(&way)
and c++ tangled way (though I had some
hesitations to it and to some other
improvements I still also have in some extent0

It gives clean looking code

Smth1 x, Smth2 y = foo(smth3, smth4);

it is easier to write c programs with that,
also it is fully efficient compared to
this(&c,&way) but gives inout and output checking and it is nicer on both client
and function body side

Clean possibly, but almost entirely unlike C.

In what way is your suggestion more efficient than C++ style pass by
reference?

 

[fir]

W dniu czwartek, 4 października 2012 09:41:53 UTC+2 użytkownik Ian Collins napisał:

Clean possibly, but almost entirely unlike C.

In what way is your suggestion more efficient than C++ style pass by
reference?

Possibly it can be faster in returning
values - c++ does very strange things
here, c++ 'optymizes it' (or maybe not
sometimes i dont know) but it is also conteptually big mess of uglinefs forme;

here it is clear and much efficient,
returned ram data is always on upper scope
and its referenced thru adres (hidden
pointer, word adress is close to reference
here but i prefer to use adress, not to
speak on other form o references maybe)

It is also better then present c way
(c way just do not permit to creatae
a handy version of such things as itoa(),
FloatToString(),

this_way(&outStruct, &inStruct);

is fully efficient but it is obscure

my way

out = this_way(in);

is better one IMO

 

[Ian Collins]

W dniu czwartek, 4 października 2012 09:41:53 UTC+2 użytkownik Ian Collins napisał:

Possibly it can be faster in returning
values - c++ does very strange things
here, c++ 'optymizes it' (or maybe not
sometimes i dont know) but it is also conteptually big mess of uglinefs for me;

C++ (and maybe C as well?) RVO will construct the return value for the
function in the variable the function return would be assigned to. So
you can write functions that return large objects without having to
worry about the copy overhead.

 

[fir]

W dniu czwartek, 4 października 2012 10:24:44 UTC+2 użytkownik Ian Collins napisał:

C++ (and maybe C as well?) RVO will construct the return value for the

function in the variable the function return would be assigned to. So

you can write functions that return large objects without having to

worry about the copy overhead.

maybe but afaik it is limited, here it
is clean and light, conteptualy easier,
solution how to do it - also code looks
nicer (no & * signs and other unnecessary
stuff - explicite pointers or even 'explicite
references' are not needed here when looking at it at conteptual level (oneneed reference to data not explicit pointer, i chose hidden reference as aproposal after some deliberations))

 

[Ian Collins]

W dniu czwartek, 4 października 2012 10:24:44 UTC+2 użytkownik Ian Collins napisał:

maybe but afaik it is limited, here it
is clean and light, conteptualy easier,
solution how to do it - also code looks
nicer (no& * signs and other unnecessary
stuff - explicite pointers or even 'explicite
references' are not needed here when looking at it at conteptual level (one need reference to data not explicit pointer, i chose hidden reference as a proposal after some deliberations))

Can't you do anything about all those unnecessary blank and long lines
in your replies? Fixing them is a pain in the arse.

In C++ one could write

SomeBigObect a;
SomeBigObect b;

SomeBiggerObect c = someFunction(a, b);

Which is what you originally wrote.

 

[fir]

W dniu czwartek, 4 października 2012 10:54:33 UTC+2 użytkownik Ian Collins napisał:

Can't you do anything about all those
unnecessary blank and long lines

in your replies? Fixing them is a pain in
the arse.

can break and delete it manually, it is
google groups, - If you know any other www
newsgate I could use maybe i would like
to use the other

got some newsreader but i do not like
it, prefer www newsgates but not found
other one

In C++ one could write

SomeBigObect a;
SomeBigObect b;

SomeBiggerObect c = someFunction(a, b);

Which is what you originally wrote.

The solution / proposal i gave is simpler,
cleaner,'optymizes always', compiler would
work much faster, it is also more in spirit
of transparent view what your compiled code
look like - optimization likers will like it
i think

Also here I would like to return more
values

Bigger b; //eight floats for example

Big c,d,e,f = Split(b); //each Big is two float

also some other improvements/ options related
to it, for example keyword value if someone
would like maybe to get it by value, olso
keywords auto/register/static to some other
ways of passing

Big c,d,e,f = Split(register b);

register means pass b adr thru register,

(not finished Yet and I will be working
on some claryfication)

 

[fir]

W dniu czwartek, 4 października 2012 00:35:29 UTC+2 użytkownik Kaz Kylheku napisał:

Well, not as far you're able to see.

Anyway, you should join the ISO C committee; you'd be in excellent company.

i would like to talk with them, probably,

my inventions i consider meaningful already
(if considered separatelly - it is thinked
just as separated set of c improvements)

but on the other side it is all not
finished (closed) yet, so I am just
working on it

 

[Jens Gustedt]

Am 03.10.2012 23:07, schrieb Keith Thompson:

And in your own language, you can use "void main()" as much as you like.
In C, it's wrong. (That's not *quite* accurate, but it's close enough.)

No it isn't. The standard has it even as example in two places. As
long as it is part of a definition and as long as you are not calling
main recursively, this is ok.

Generally this "void main()" business is not a good example for things
that people should primarily learn about C. There are much more
important things to come first.

Jens

 

[Kenny McCormack]

Am 03.10.2012 23:07, schrieb Keith Thompson:


No it isn't. The standard has it even as example in two places. As
long as it is part of a definition and as long as you are not calling
main recursively, this is ok.

Generally this "void main()" business is not a good example for things
that people should primarily learn about C. There are much more
important things to come first.

Gee. Ya think?

But, see, once you've learned not to cast the return value of malloc(), what
else is there to do (to show one's innate superiority) ? What else is there
to make an issue of?