any other language can do these?

[mcheung63]

Hi
except c/c++, which language can do:

1) ELF output
2) support linker script
3) have a nice general library

thanks
from Peter ([email protected])

[JamesM]

The "linker script" requirement is difficult, as most languages don't use LD as their linker. However:

- ADA95/2000
- Java, when compiled with GCC/LD (yes, there is a front-end for it).
- PHP , although I don't think the compiled version supports linker scripts (comes packaged with a bytecode interpreter)

I don't quite understand what you're asking, actually. You want it to support custom linking, but also have a standard library? Why would you ever want both? If you're making an OS you want it to be custom-linked, but not have a library. Otherwise I don't see why you would need custom linker script support...

[Craze Frog]

Hi
except c/c++, which language can do:

1) ELF output
2) support linker script
3) have a nice general library

thanks
from Peter ([email protected])

Pascal, Assembly, FreeBasic, D, Haskell, Fortran, and maybe OCaml and Lisp.

Edit: C sucks. Example:

Code: Select all

int *pint = 1234;
int *litre;
*litre = 1234;

Now why the HELL does *pint = 1234; set the value of the POINTER while *liter = 1234; sets the value of the DEREFERENCED POINTER???

And WHICH IDIOT made a SYSTEM programming language WITHOUT putting the BIT SIZES of the standard types into the standard? A valid 32-bit C compiler for x86 can, while following the standard, have an 8-bit int and a 64-bit long long (as long as a short and char is no more than 8 bits either). Only conventions keeps the programs running, not the standard.

Code: Select all

int *ptr, notptr;

C's pointer "system" (where's the system?) is a total mess. The * belongs to the variable, not the type, so notptr will not become a pointer. However, even though the * belongs to the variable and not the type, it can also be specified when you specify only a type and no variable, like in a function prototype:

Code: Select all

void myfunc(int *);

In one declaration the * belongs to the variable, in the next it belongs to the type. What were they thinking? (Were they even thinking?)

[neon]

And WHICH IDIOT made a SYSTEM programming language WITHOUT putting the BIT SIZES of the standard types into the standard?

C and C++ were not specifically made to be system programming languages, but rather general programming languages.

In a way they do put standard sizes inside of stdint.h, which defines types such as uint8_t, uint16_t, etc., That is guaranteed to be a specific size. uint8_t is guaranteed to be 8 bits, uint16_t is guaranteed to be 16.

Code: Select all

int *pint = 1234;
int *litre;
*litre = 1234;

Now why the HELL does *pint = 1234; set the value of the POINTER while *liter = 1234; sets the value of the DEREFERENCED POINTER???

Because the first is initialization, the second is assignment. In the initialization, dereferencing a pointer that does not point to anything has no purpose, and is prone to failure. Hence, it initializes the pointer with a memory address.

n one declaration the * belongs to the variable, in the next it belongs to the type.

No no no no. The pointer operator (*) always belongs to the type, not the variable. In all of your code snippets, it has always been in the type.

Code: Select all

int *litre;
*litre = 1234;

I should note that the above uses two different operators. The first is the pointer (*), and the second is the dereference (*) operator.

[Craze Frog]

n one declaration the * belongs to the variable, in the next it belongs to the type.

No no no no. The pointer operator (*) always belongs to the type, not the variable. In all of your code snippets, it has always been in the type.

If belongs to the type, then why does it work like this: int * pointer, not_pointer;. The second variable won't become a pointer. It should be if the * belonged to the int, because all variables on the line becomes ints.

[neon]

Code: Select all

 int * pointer, *not_pointer;  << both pointers

I think I see your point here, though.

[Alboin]

Edit: C sucks.

Yet, it's one of the most popular programming languages in history. Just because it "sucks" doesn't mean it's bad. By your reasoning, English would suck, and so would Spanish, and every other natural language out there. Nothing is perfect. It just has to work.

As for the thread's content, I should say that your list should include something about the standard library of each language. For example, even though haskell could be (apparently) used with ld, and made into a binary, it would be literal hell to get it free standing.

[Craze Frog]

And if it's not enough that the *, which is the dereference operator, does not always perform a dereference, the address of operator is crazy as well. (Yes, I know it's not the dereference operator when used there, but there is absolutely no reason why it shouldn't be. Disallowing writing to address 0 is an arbitary restriction imposed by the operating system and C is supposed to be portable.) But back to the address of operator (or more the lack thereof): (Note, C++, but shouldn't matter)

Code: Select all

void add_one (int &x) {
  x += 1;
}

void (*inc)/(int &x) = add_one; /* a */
void (*inc)/(int &x) = &add_one; /* b */

Both a and b does the same thing. Let me ask: since when was the address of X the same as X?

Also note the += operator. I'll get to that...

Edit: C sucks.

Yet, it's one of the most popular programming languages in history.

C is evolutionally superior, not technically superior.

Just because it "sucks" doesn't mean it's bad. By your reasoning, English would suck, and so would Spanish, and every other natural language out there. Nothing is perfect. It just has to work.

That's correct. As a programming language, English sucks big time. It's not even possible to write a compiler nor interpreter for it, can you say miserable failure?
However, English isn't a programming language (surprise!). The requirements for a natural language are totally different than the requirements for a programming language. The fact that I can write "unsigned long letter;" in C doesn't have any advantages in programming. But the fact that I can say that "the pun is mightier than the sword" is a huge quality of English.

Back to the +=. In C you don't use = for comparison, right? You just use it for assignment, right? Not really. In the following operators = is used for assignment:
=
+=
-=
*=
/=
%=
>>=
<<=
&=
|=
^=

In the following operators = is used for comparison:
<=
>=
!=

If == means equal and < means less than, less than or equal would be <==. If += means add and assign, <= should mean compare to less and assign.

[Alboin]

Please leave your rants to your blog.

If you wanted, you could have even started a new thread. It wouldn't be anything new to have a thread based on a rant.

[neon]

If == means equal and < means less than, less than or equal would be <==. If += means add and assign, <= should mean compare to less and assign.

Here you are mixing comparison operators with assignment operators.

(Yes, I know it's not the dereference operator when used there, but there
is absolutely no reason why it shouldn't be. Disallowing writing to address 0 is an arbitary restriction imposed by the operating system and C is supposed to be portable.)

C nor C++ initializes variables to 0. In other words, it will write to whatever garbage location is inside of the variable, which is very bad. It has nothing to do with address 0:

Code: Select all

char* p = 0x2a;

// if this written data to a memory location, it will write to a random byte
// in memory. "p" containers garbage data. Because this is prone to 
// failure, it is simply not allowed.

Both a and b does the same thing. Let me ask: since when was the address of X the same as X?

I actually don't know when, but in C++, the name of the object (variable or function) can be indirectly used to refer to its address. Hence, both of these are the same:

Code: Select all

char a=0;
char *p = a;
char* c = &a;

When used in a function parameter list, it is the refrence operator (&), not the address-of (&) operator. It indirectly referes to the parameters' address. The above makes it possible to write this:

Code: Select all

void foo (char&);

char a=0;
foo (a);     // cleaner syntax--we don't need to use &a here

[JamesM]

Woo! troll time. Let's go through these points one by one.

And WHICH IDIOT made a SYSTEM programming language WITHOUT putting the BIT SIZES of the standard types into the standard? A valid 32-bit C compiler for x86 can, while following the standard, have an 8-bit int and a 64-bit long long (as long as a short and char is no more than 8 bits either). Only conventions keeps the programs running, not the standard.

How is a language supposed to be portable and stand the test of time if the size of it's standard types are explicitly set in stone? Do you think when C was written the average size of an integer was 32-bits? (answer: noooooo).

Code: Select all

int *ptr, notptr;

C's pointer "system" (where's the system?) is a total mess. The * belongs to the variable, not the type, so notptr will not become a pointer. However, even though the * belongs to the variable and not the type, it can also be specified when you specify only a type and no variable, like in a function prototype:

Code: Select all

void myfunc(int *);

In one declaration the * belongs to the variable, in the next it belongs to the type. What were they thinking? (Were they even thinking?)

The '*' qualifier (it's a qualifier in this case and not an operator) states that the variable following it will be defined as a pointer. That is:

Code: Select all

int *ptr, notptr;

ptr is a pointer to a variable of type integer.. Notptr is a variable of type integer. The '*' qualifier 'belongs' to the variable.

Now to your second example:

Code: Select all

void myfunc(int *);

This is lax coding on your part, but allowed by the C99 standard. Inside the parameter list, you define one argument: "an integer". Again, the '*' operator kicks in afterwards: "the following argument will be a pointer to the type already specified". Then what? well, you just didn't name your argument. There is one there, but you just omitted to name it. This is allowed by the C99 standard, but it doesn't change the way in which the semantic rules of the language operate.

And if it's not enough that the *, which is the dereference operator, does not always perform a dereference, the address of operator is crazy as well. (Yes, I know it's not the dereference operator when used there, but there is absolutely no reason why it shouldn't be. Disallowing writing to address 0 is an arbitary restriction imposed by the operating system and C is supposed to be portable.) But back to the address of operator (or more the lack thereof): (Note, C++, but shouldn't matter) Code:

Code: Select all

void add_one (int &x) { 
  x += 1; 
} 

void (*inc)/(int &x) = add_one; /* a */ 
void (*inc)/(int &x) = &add_one; /* b */ 

Both a and b does the same thing. Let me ask: since when was the address of X the same as X?

Woo, Woo! Let the truth train continue!

First off I'm not sure what you were smoking when writing this example - where the hell did the forward slash '/' come from between "void (*inc)" and "(int &x)"? That's not valid and it doesn't compile. Anyways, ignoring that...

As stated, '&' as a qualifier (note the use of that word again) denotes that "the variable following will be defined as a reference". A reference is essentially a pointer without the dereference syntax. It's a less powerful pointer, essentially.

'&' as an operator, is, as you said the 'address of' operator. Now, take a look at your code. Not having to take the address of a function to obtain a function pointer is a known issue and is deprecated. Some (C++) compilers will emit a warning, some an error (note C++ compilers are usually stricter than C. This holds for G++/GCC). The fact that you *can* do it doesn't mean you *should*. The reason for it's behaviour is - what should this code return?

Code: Select all

<don't worry about the type> x = add_one;

What is the value and type? there is none. You can't pass around functions as variables in C (without using function pointers), and there is no logical 'value' a function should take. So most compilers just default back to returning a function pointer, as if you'd used the '&' operator.

The fact that I can write "unsigned long letter;" in C doesn't have any advantages in programming.

Why the hell not?

Back to the +=. In C you don't use = for comparison, right? You just use it for assignment, right? Not really. In the following operators = is used for assignment: <blah blah long rant>

You are confusing yourself. '=' is the assignment operator. All of the other two-character combinations you mentioned are operators in their own right, not variations on the assignment operator.. I hope that cleared it up

Disallowing writing to address 0 is an arbitary restriction imposed by the operating system and C is supposed to be portable.)

Dude, where are you getting your facts from?

Code: Select all

unsigned int *myptr = (unsigned int *)0x0;
*myptr = 66; // This will ususally cause a GPF and kill your process.

Where exactly can't you write to address zero? C++ compilers (as they're stricter) will usually stop you dereferencing a pointer which hasn't been initialised, as it contains junk and will make your program nondeterministic (which, unless you're writing a random number generator, is not what you want.)

Truth train pulling into the station - all change please!

JamesM

[Craze Frog]

All of the other two-character combinations you mentioned are operators in their own right, not variations on the assignment operator

Take a look at the ISO C++ standard section 5.17 page 89.

[JamesM]

* looks at specified chapter.

Yes, and your point is? Because *=, ^= etc are classified as "assignment operators" does not mean they are in some way related to "comparison operators". They merely share a common symbol, '=' (please note: alphanumeric symbol, NOT syntactic symbol). I still don't understand fully where you're coming from with your point.

If you're trying to use the C++ standard to suggest that '+=' is not an operator (and one single lexical token) then I reckon you're out of luck...

EDIT:

operators::= "!" | "%" | "^" | "&" | "*" | "-" | "+" | "=" | "|" | "~" | "<" | ">" | "/" | "->" | "++" | ".*" | "->*" | "<<" | ">>" | "<=" | ">=" | "==" | "!=" | "||" | "*=" | "/=" | "%=" | "+=" | "-=" | "<<=" | ">>=" | "&=" | "|=" | "::".

[Craze Frog]

I don't think you understood my posts at all. I know how it works. I know that the = in += and <= are different. However, I'm saying that it's insane to have the = mean two different things WHEN at the same time == is used for comparison instead of = "because it would illogical if the = was used for two different things". Almost everything in C/C++ is inconsistent, that's what I'm saying.

[JamesM]

I don't understand how it's inconsistent - In English we say "Let a equal b" as assignment, but we also say "If a is equal to b" as comparison.

Please provide a counterexample.