Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > bug raport - about way of linking in c

Reply
Thread Tools

bug raport - about way of linking in c

 
 
Kaz Kylheku
Guest
Posts: n/a
 
      10-02-2012
On 2012-10-02, Stephen Sprunk <(E-Mail Removed)> wrote:
> Aside from a minor difference in syntax, they're the exact same thing.
>
> Since you refuse to recognize that you've reinvented namespaces, though,
> you've done a poor job of it.


Refusing to recognize that prefixes on names are de-facto namespaces
is a sign of low intelligence (and therefore, needless to say, unsuitability
for working in language design).
 
Reply With Quote
 
 
 
 
BartC
Guest
Posts: n/a
 
      10-03-2012


"Kaz Kylheku" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On 2012-10-02, Stephen Sprunk <(E-Mail Removed)> wrote:
>> Aside from a minor difference in syntax, they're the exact same thing.
>>
>> Since you refuse to recognize that you've reinvented namespaces, though,
>> you've done a poor job of it.

>
> Refusing to recognize that prefixes on names are de-facto namespaces
> is a sign of low intelligence (and therefore, needless to say,
> unsuitability
> for working in language design).


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

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!

--
Bartc

 
Reply With Quote
 
 
 
 
Greg Martin
Guest
Posts: n/a
 
      10-03-2012
On 12-10-03 09:10 AM, BartC wrote:
>
>
> "Kaz Kylheku" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> On 2012-10-02, Stephen Sprunk <(E-Mail Removed)> wrote:
>>> Aside from a minor difference in syntax, they're the exact same thing.
>>>
>>> Since you refuse to recognize that you've reinvented namespaces, though,
>>> you've done a poor job of it.

>>
>> Refusing to recognize that prefixes on names are de-facto namespaces
>> is a sign of low intelligence (and therefore, needless to say,
>> unsuitability
>> for working in language design).

>
> Building-in a permanent prefix into a name is not the same as having
> namespaces. Otherwise no-one would have bothered inventing them.
>
> 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!
>


There is certainly a difference in programmer effort and ease of
consistency but on the other hand C is lexically scoped and a namespace
doesn't change that. It would just leave it to the compiler to
"decorate" the names, would it not?


 
Reply With Quote
 
Les Cargill
Guest
Posts: n/a
 
      10-03-2012
Greg Martin wrote:
> On 12-10-03 09:10 AM, BartC wrote:
>>
>>
>> "Kaz Kylheku" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>> On 2012-10-02, Stephen Sprunk <(E-Mail Removed)> wrote:
>>>> Aside from a minor difference in syntax, they're the exact same thing.
>>>>
>>>> Since you refuse to recognize that you've reinvented namespaces,
>>>> though,
>>>> you've done a poor job of it.
>>>
>>> Refusing to recognize that prefixes on names are de-facto namespaces
>>> is a sign of low intelligence (and therefore, needless to say,
>>> unsuitability
>>> for working in language design).

>>
>> Building-in a permanent prefix into a name is not the same as having
>> namespaces. Otherwise no-one would have bothered inventing them.
>>
>> 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!
>>

>
> There is certainly a difference in programmer effort and ease of
> consistency but on the other hand C is lexically scoped and a namespace
> doesn't change that. It would just leave it to the compiler to
> "decorate" the names, would it not?
>
>



The only difference is:

Suppose we have:

::ns1::a
::ns1::b
::ns2::c

a can refer to b without qualification. c cannot.

If you do "fake namespaces", you always have to qualify.

--
Les Cargill

 
Reply With Quote
 
fir
Guest
Posts: n/a
 
      10-03-2012
W dniu wtorek, 2 października 2012 15:05:17 UTC+2 użytkownik Stephen Sprunk napisał:
> On 29-Sep-12 01:46, fir wrote:
>
> >>

>
> >> You're reinventing namespaces, but poorly.

>
> >

>
> > This is no matter of namespace.

>
> > ...

>
> > (One should not cure this by adding namespaces, this is no c spirit

>
> > in such things, it would be bad)

>
>
>
> ... but reinventing namespaces is exactly what you've done.
>
>
>
> Here is your proposed syntax (from another post):
>
>
>
> > module mian;

>
> >

>
> > reaches module_a;

>
> > reaches module_b;

>
> > reaches module_c;

>
> >

>
> > void main() {

>
> >

>
> > module_a init(); (*)

>
> > module_b init();

>
> > module_c init();

>
> >

>
> > module_a run();

>
> > module_b run();

>
> > module_c run();

>
> >

>
> >

>
> > }

>
>
>
> Here is the same thing done with C++ namespaces:
>
>
>
> #include "module_a.h"
>
> #include "module_b.h"
>
> #include "module_c.h"
>
>
>
> void main() {
>
> module_a::init();
>
> module_b::init();
>
> module_c::init();
>
>
>
> module_a::run();
>
> module_b::run();
>
> module_c::run();
>
> }
>
>
>
> Aside from a minor difference in syntax, they're the exact same thing.
>
>
>
> Since you refuse to recognize that you've reinvented namespaces, though,
>
> you've done a poor job of it. In particular, the C++ solution (and the
>
> C prefix convention that does roughly the same thing, which I provided
>
> an example of in another reply) does not require any change to linkers
>
> or break billions of lines of existing code, whereas your proposal does.
>
>


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



 
Reply With Quote
 
Greg Martin
Guest
Posts: n/a
 
      10-03-2012
On 12-10-03 11:12 AM, fir wrote:
> W dniu wtorek, 2 października 2012 15:05:17 UTC+2 użytkownik Stephen Sprunk napisał:
>> On 29-Sep-12 01:46, fir wrote:
>>
>>>>

>>
>>>> You're reinventing namespaces, but poorly.

>>
>>>

>>
>>> This is no matter of namespace.

>>
>>> ...

>>
>>> (One should not cure this by adding namespaces, this is no c spirit

>>
>>> in such things, it would be bad)

>>
>>
>>
>> ... but reinventing namespaces is exactly what you've done.
>>
>>
>>
>> Here is your proposed syntax (from another post):
>>
>>
>>
>>> module mian;

>>
>>>

>>
>>> reaches module_a;

>>
>>> reaches module_b;

>>
>>> reaches module_c;

>>
>>>

>>
>>> void main() {

>>
>>>

>>
>>> module_a init(); (*)

>>
>>> module_b init();

>>
>>> module_c init();

>>
>>>

>>
>>> module_a run();

>>
>>> module_b run();

>>
>>> module_c run();

>>
>>>

>>
>>>

>>
>>> }

>>
>>
>>
>> Here is the same thing done with C++ namespaces:
>>
>>
>>
>> #include "module_a.h"
>>
>> #include "module_b.h"
>>
>> #include "module_c.h"
>>
>>
>>
>> void main() {
>>
>> module_a::init();
>>
>> module_b::init();
>>
>> module_c::init();
>>
>>
>>
>> module_a::run();
>>
>> module_b::run();
>>
>> module_c::run();
>>
>> }
>>
>>
>>
>> Aside from a minor difference in syntax, they're the exact same thing.
>>
>>
>>
>> Since you refuse to recognize that you've reinvented namespaces, though,
>>
>> you've done a poor job of it. In particular, the C++ solution (and the
>>
>> C prefix convention that does roughly the same thing, which I provided
>>
>> an example of in another reply) does not require any change to linkers
>>
>> or break billions of lines of existing code, whereas your proposal does.
>>
>>

>
> 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
>
>
>



So .. if I want to link to the other libraries I will have to know what
modules contain what names if I wish to gain any benefit from your
system? C's success has in large part been due to fact that it is
possible to gain considerable portability of code but if I have to know
the internals of object code I'm linking to that is lost. It's common to
link to objects written in other languages and not even know that is the
case.

Fortunately, it is outside of the purview of the language C to address
issues of code location in object files and this won't be a problem for
the language.

 
Reply With Quote
 
fir
Guest
Posts: n/a
 
      10-03-2012
>
>
> So .. if I want to link to the other libraries I will have to know what
> modules contain what names if I wish to gain any benefit from your
> system? C's success has in large part been due to fact that it is
> possible to gain considerable portability of code but if I have to know
> the internals of object code I'm linking to that is lost. It's common to
> link to objects written in other languages and not even know that is the
> case.
>
> Fortunately, it is outside of the purview of the language C to address
> issues of code location in object files and this won't be a problem for
> the language.


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)

I advanced this modular improve system with
some more ideas, but it is not finished yet
and may take even a few years yet (it originate
slowly)

The one more 'fature' i can tell about is
instantiating of modules, If a module is
reached it is like a joined space you have
a door to, its ram is away and you can reach
to it, say

module poland;

reach france;
reach spain;

// poland code here

but if you instantiate module its ram is
contained here, in module you use it


module main;
reaches logging;

uses pixelbuffer,
bit,
int,
float;

void main()
{
float f = 2.0;
bit b = 0;

pixelbuffer buf;



}

int is a module instantiatlized here

But not all questions Ive got resolved
in this place, Im working on it :/ its not so
easy



 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      10-03-2012
fir <(E-Mail Removed)> writes:
[...]
> 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.)

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
fir
Guest
Posts: n/a
 
      10-03-2012
W dniu środa, 3 października 2012 23:07:47 UTC+2 użytkownik Keith Thompson napisał:
> fir <(E-Mail Removed)> writes:
>
> [...]
>
> > 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.)
>
>


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 asa '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

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)

float3 v = cross({1,2,3},{4,5,6});

multple values can be returned

int x,y,z = f();

and such like

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







 
Reply With Quote
 
fir
Guest
Posts: n/a
 
      10-03-2012
W dniu środa, 3 października 2012 23:07:47 UTC+2 użytkownik Keith Thompson napisał:
> 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>`.)
>


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)
{

}

>
>
> 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.
>

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

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
*bug* *bug* *bug* David Raleigh Arnold Firefox 12 04-02-2007 03:13 AM
Generating raport Luke Ruby 1 09-14-2006 06:51 AM
Getting linking error: not found in vtable (Trying to understand whats wrong the way I did my classes?) g35rider@gmail.com C++ 1 08-17-2006 05:10 PM
way way way OT: MCNGP Announcement Neil MCSE 174 04-17-2006 05:55 PM
AMD Opteron: 1-way, 2-way, ... Up to 8-way. John John Windows 64bit 12 12-27-2005 08:17 AM



Advertisments