How many instructions are there ?

[oldtobor]

OK, I may not know a lot of things and may have a lot of things wrong. But I am sure that PERL at least was definitely the route that languages should have taken.

For example to extract the next to the last field of an ascii file separated by "|" and sort them, it can be done with one line: C:\> perl -ane"split/\|/; $l=@_[@_-2];push@r,$l.\"\n\"if$l;END{print sort@r}" bands.txt

works on any unix too.

I find it amazing that back in the mid 1990s, just when Java started to become popular this direction of language design, and maybe greatly improving the concepts, compilers etc. did not take off. The syntax could be cleaner very BASIC like at least, there are so many improvements conceivable but the ideas are great:

split - it is implied that the line is split and the result is in an array called @_.

@_[@_-2] gets the next to the last field;

@_ is the total array;

at the end of the scan (like AWK) just print the sorted array.

 

[eieio]

In the case of C / C++, the precedence for binary math operations wrong. & shoud be the same as * (binary "and" same precedence as multiply), while | (inclusive or) and ^ (exclusive or) should have the same precedence as + or -. Instead these operators have lower precedence than the logical and compare operators, && || < > <= >= !=, which doesn't make sense and requires unecessary parenthesis. It would never make sense to perform a binary math operations on logical values which are just defined as zero and not zero.

You are incorrect here. The bitwise and/or/xor are higher precedence than the logical and/or. They are, however, lower precedence than relational operators, with good reason. They serve double purpose as non-short-circuit logical operators. For example, f() != 10 && g() == 8 will not execute g() if f() returns 10 , but f() != 10 & g() == 8 will execute g() regardless of the result of f(), with the same overall logical result.

 

[eieio]

Speaking of which, logical values should have been more strictly defined, with TRUE and FALSE being reserved symbol names.

This is a bad idea that violates the very essence of C. Making true/false values their own type with reserved symbols is a contrivance that C intentionally avoids. The "0 is false, everything else is true" is leveraged extensively by good C programmers.

Here are some examples to illustrate the the design choice:

/* status register bits */
enum {
    STATUS_READY=1,
    STATUS_PENDING=2,
    STATUS_ERROR=4,
}

...

/* check for errors */
if (readStatusReg() & STATUS_ERROR) {
   /* error handling */
}

...

/* see if the device is ready or pending */
if (readStatusReg() & (STATUS_READY | STATUS_PENDING)) {
   /* take appropriate action that applies to both states */
} else {
    /* perform some idle action */
}

...

int (*handler)(result_t *) = getHandler();

/* execute the hander if we have one, and pass the results off */
result_t result;
if (handler && handler(&result)) {
    /* we had a handler and it returned success, do something with the result */
}

You see, truth values other than 1 are useful. C is a very well designed language, with many very intentional features; most of them for efficiency of expression and execution.

- Old MacDonald

 

[MeJennifer]

C is a very well designed language, with many very intentional features; most of them for efficiency of expression and execution.

Let me say that I am a great fan of C, I use it very often, mainly due to its efficiency and small memory footprint! But I find it far from well designed, on the contrary I find it rather poorly designed.

And that dual usage of the term "static" is close to idiocy.

A well designed language is Pascal or Java and more recently Ruby.

 

[eieio]

And that dual usage of the term "static" is close to idiocy.

Which dual usage do you speak of?

 

[D H]

Static has many meanings in C and C++.

• A static file-scope variable acts like a global variable except that it is not visible to the linker. The opposite of static is no keyword.
• A static function similarly is not visible to the linker.
• A static function-scope variable has permanent storage and is initialized but once (this use of static is opposite of auto).
• A static member variable is a class variable.
• A static member function can only access static member variables.

 

[chroot]

dir/b/s *.pl|perl -ane"s/\n//;open _;print$_,@t,\"\n\n\"if@t=grep/if/,<_>"

Perl's such a piece of crap! Do you really expect any programmer in his right mind to be able to actually type that garbage, from memory, without making at least twelve mistakes??

And your "program" just relies on DOS to do its recursive listing, which isn't helpful at all! Jeff Reid was asking about writing an actual program to do this, not just to depend on the shell.

Not to mention that your stupid Perl program is horribly memory inefficient, attempting to store each entire file in memory as it is searched. What if your directory contains gigabyte files? You're screwed!

How about a simple Python program that actually does what Jeff Reid wants to? How about one that any programmer, of any language, can read and understand? How about one that anyone who knows Python could write in a couple of minutes? How about one that is time and memory efficient, without requiring any extraordinary effort on the part of the programmer?

Observe:

import os
from os.path import join
for root, dirs, files in os.walk('/my/path/here'):
	filename = join(root, name)
	for line in file(filename).readlines():
		if pattern in line:
			print "File", filename, "matched."

Perl's dead. Long, long dead.

- Warren

 

[eieio]

Static has many meanings in C and C++.

• A static file-scope variable acts like a global variable except that it is not visible to the linker. The opposite of static is no keyword.
• A static function similarly is not visible to the linker.
• A static function-scope variable has permanent storage and is initialized but once (this use of static is opposite of auto).
• A static member variable is a class variable.
• A static member function can only access static member variables.

No, those all mean the same thing; with the exception of the static member function (method), which is a very natural extension that keeps in line with C++'s object oriented features.

The keyword 'static' simply specifies that the compiler reserve space for the item in either the initialized or uninitialized data segment, and that the symbol for that item be restricted to the scope in which it is defined. There is no difference between a static file-scope variable and a static function-scope variable. They both reside within the same block in the executable image and behave exactly alike; while the symbol behaves exactly as it should, from within the scope it was defined.

Static member variables behave exactly the same way, too; there is just one of such variable in the class scope. This is seen in the way you need to define static member variables in similar manner to static file-scope variables.

Really, all static variables are the same thing: a reserved, pre-initialized (or zeroed) section of the program data segment, with a localized symbol.

Furthermore, I really don't see static methods as being all that unintuitive in meaning, if you already grasp what static is supposed to mean. What do you want, a separate keyword like 'notinterestedinimplicitinstanceaccess'? The keyword 'static' is already closely associated with idea.

- OMD

 

[eieio]

import os
from os.path import join
for root, dirs, files in os.walk('/my/path/here'):
	filename = join(root, name)
	for line in file(filename).readlines():
		if pattern in line:
			print "File", filename, "matched."

Perl's dead. Long, long dead.

- Warren

Good one.

Or if you want that last bit of efficiency:

import os
from os.path import join
for root, dirs, files in os.walk('/my/path/here'):
	filename = join(root, name)
	for line in file(filename):
		if pattern in line:
			print "File", filename, "matched."

Just iterate the file object (as of 2.3). That way you don't read in the whole file into a list first.

- OMD

 

[chroot]

For example to extract the next to the last field of an ascii file separated by "|" and sort them, it can be done with one line: C:\> perl -ane"split/\|/; $l=@_[@_-2];push@r,$l.\"\n\"if$l;END{print sort@r}" bands.txt

One line that would take any programmer 20 minutes to really understand thoroughly. One that probably took you an hour to write in the first place!

If you want to take a file like this:

a | b | c
d | e
f | g | h | i

And sort the second-to-last elements of each line, here's a Python program that anyone who's ever programmed can understand immediately:

import sys

bigList = []

for line in sys.stdin:
	try:
		secondToLast = line.split('|')[-2].strip()
		bigList.append(secondToLast)
	except:
		pass

bigList.sort()
print bigList

I wrote this in literally three minutes. It's more efficient than your Perl (since it doesn't read the entire file at once), anyone here can understand it in seconds, and it does something your code does not: it includes exception handling to deal with lines that don't actually have two elements in them.

- Warren

 

[chroot]

Just iterate the file object (as of 2.3). That way you don't read in the whole file into a list first.

That's what I was intending to do with readlines(). Good catch, it's not actually a generator!

- Warren

 

[D H]

Any language can be obfuscated.

o = lambda o:map(lambda a:filter(None,(map(lambda i:map(lambda x:a.__setitem__(x,0),range(2*i,o,i)),range(2,o)),a)[1])[1:],[range(o)])[0]
print p(20)

Regarding static:

The opposite of static at file scope is "extern", while the opposite of static at function scope is "auto". They are different concepts. This is not just my opinion; all of my C reference books have some caveat on the multiple meanings of "static".

I agree with McJennifer: C is a poorly architected language. Ada is the only well architected language that I know of, and it is more-or-less dead.

 

[chroot]

Any language can be obfuscated.

That's what's so hilarious about oldtobor. He complains adamantly about how languages like C are overly complex and hard to write and understand... and then shows us his thoroughly obfuscated Perl one-liner as an example of what he presumably feels is elegant and easy to understand.

I agree with McJennifer: C is a poorly architected language. Ada is the only well architected language that I know of, and it is more-or-less dead.

I've been meaning to learn Ada. I take it you don't think Python is well-architected?

- Warren

 

[oldtobor]

Python seems ok, it seems to go in the right direction, maybe if it got rid of the object oriented stuff. Pity that it executes slow, but all interpreted languages are slow. But after decades of research couldn't they have finally created lightning fast interpreters ?

Software doesn't evolve; it simply changes, it simply draws a different picture of the same thing, it is an aesthetical - cultural creation. It is not like hardware where you can measure its progress, where there is a well defined task that can be optimized and you get progress.

Software is a based on what people want to do, how they want it to look, so it is fickle, it follows styles. There has been very little progress in software, linux , a 30 year old OS is the great new thing, and you still have to use vi because they can't create an EDIT program like the one that runs on DOS, from the prompt.

Maybe when multicore chips start integrating in hardware - firmware more and more software, there will start to be some progress. Then again the proliferation of so many languages and systems is another example of

EXCESS CAPACITY

 

[chroot]

Python seems ok, it seems to go in the right direction, maybe if it got rid of the object oriented stuff. Pity that it executes slow, but all interpreted languages are slow. But after decades of research couldn't they have finally created lightning fast interpreters ?

It's not slow at all, oldtobor. It is, in fact, it's as fast as C or C++ for many purposes, and is generally faster than an equivalent program in C or C++, given equal amounts of time spent optimizing both.

Software doesn't evolve; it simply changes, it simply draws a different picture of the same thing, it is an aesthetical - cultural creation. It is not like hardware where you can measure its progress, where there is a well defined task that can be optimized and you get progress.

There are many ways you can track the progress of software's evolution -- like the speed or cost of development.

Software is a based on what people want to do, how they want it to look, so it is fickle, it follows styles. There has been very little progress in software, linux , a 30 year old OS is the great new thing, and you still have to use vi because they can't create an EDIT program like the one that runs on DOS, from the prompt.

You mean... like emacs?

Maybe when multicore chips start integrating in hardware - firmware more and more software, there will start to be some progress. Then again the proliferation of so many languages and systems is another example of

EXCESS CAPACITY

This was the paradigm of the mainframe, which ended some decades ago. It proved to be a poor way to look at things.

The truth is that all the intelligence should be in the compiler or interpreter, not in the hardware. Putting more complicated stuff in hardware is moving the wrong direction, for many reasons. (If you don't understand the reasons, ask.) The hardware should be simple, bulletproof, and run mind-bogglingly fast.

- Warren

 

[eieio]

Regarding static:

The opposite of static at file scope is "extern", while the opposite of static at function scope is "auto". They are different concepts. This is not just my opinion; all of my C reference books have some caveat on the multiple meanings of "static".

I agree with McJennifer: C is a poorly architected language. Ada is the only well architected language that I know of, and it is more-or-less dead.

You are incorrect on both counts.

The keyword 'extern' is not the opposite of static, though it may seem that way to new C programmers. It actually instructs the compiler that the specified symbol will be defined in another scope, usually another file. Declaring a variable 'extern' does not make it visible to other scopes/files, it makes it useable from other files. It basically says "hey, it's not going to come from this scope," and allows the compiler to use the symbol without having a definition in the current scope.

Global variables are useable from outside of their defining scope (file) by default; static makes the symbol for a global private to the scope.

Static and auto are also not opposites. Auto is, of course, redundant, since all variables at function scope are automatically created on the stack at runtime by default. Like I said before, static instructs the compiler to allot some space in the executable image for the data and keep the symbol private to the scope. This is the same thing static always means (excepting the static method, as mentioned before).

It's also a bit odd to consider static the opposite of both extern and auto at the same time. They have very different meanings, yet I've tried to demonstrate that static nearly always means the same thing.

I hardly care what your reference books say. Find a better one that will help you understand what C is doing. Then you may understand C's elegance. It sounds like your books are for beginners.

- OMD

 

[eieio]

and you still have to use vi because they can't create an EDIT program like the one that runs on DOS, from the prompt.

Hmm, I think you are confusing can't and don't want to. If you want to port EDIT to a UNIX, then go ahead. You'll probably have to learn C if you can get the original source.

If you bothered to look, you would notice a simple editor called PICO, which has many similarities to EDIT, and isn't as difficult for n00bs/fogies as vi can be at first.

- OMD

 

[D H]

Just a few extracts from ISO/IEC 9899:TC2

6.2.2 Linkages of identifiers
1 An identifier declared in different scopes or in the same scope more than once can be made to refer to the same object or function by a process calledlinkage. There are three kinds of linkage: external, internal, and none.

2 In the set of translation units and libraries that constitutes an entire program, each declaration of a particular identifier withexternal linkage denotes the same object or function. Within one translation unit, each declaration of an identifier withinternal linkagedenotes the same object or function. Each declaration of an identifier with no linkagedenotes a unique entity.

3 If the declaration of a file scope identifier for an object or a function contains the storage class specifier static, the identifier has internal linkage.
​

OK. Static has a special meaning when used for a file scope identifier. What more does the standard have to say about "static"?

6.7.1 Storage-class specifiers
Syntax
storage-class-specifier:
typedef
extern
static
auto
register
Constraints
At most, one storage-class specifier may be given in the declaration specifiers in a declaration.
​

Making specifiers as conceptually different as "typedef" and "static" of the same class ("storage class specifiers") speaks volumes of how well architected the C language is.

6.7.5 Declarators
Syntax
declarator: pointer_opt direct-declarator
direct-declarator:
identifier (declarator )
direct-declarator [ type-qualifier-listopt assignment-expression_opt ]
direct-declarator [ static type-qualifier-list_opt assignment-expression ]
direct-declarator [ type-qualifier-list static assignment-expression ] direct-declarator[ type-qualifier-list_opt *]
direct-declarator( parameter-type-list ) direct-declarator ( identifier-list_opt )
​

This is good. The architects of C can't even use storage-class-specifier in their own BNF. They have to make static a special case, twice.

6.7.5.2 Array declarators
Constraints
In addition to optional type qualifiers and the keywordstatic, the [ and ] may delimit an expression or *. I fthey delimit an expression (which specifies the size of an array), the expression shall have an integer type. If the expression is a constant expression, it shall have a value greater than zero. The element type shall not be an incomplete or function type. The optional type qualifiers and the keyword static shall appear only in a declaration of a function parameter with an array type, and then only in the outermost array type derivation.

Semantics
If, in the declaration ‘‘TD1’’, D1has one of the forms: D [ type-qualifier-list_opt assignment-expression_{opt[/sub ] ] D [ static type-qualifier-listopt assignment-expression ] D[ type-qualifier-list static assignment-expression ] D[ type-qualifier-listopt * ] and the type specified for ident in the declaration ‘‘T D’’ is ‘‘derived-declarator-type-list T’’, then the type specified for ident is ‘‘derived-declarator-type-list array of T’’.121) (See 6.7.5.3 for the meaning of the optional type qualifiers and the keyword static.)}
​

<sub>I could go on - the standard explicitly mentions static as a special case several more times.

All this means that C is indeed a well-architected language in which the term static has only one meaning.

Not.</sub>

 

[D H]

You are incorrect on both counts.

The keyword 'extern' is not the opposite of static, though it may seem that way to new C programmers.

You are wrong. One cannot declare something both static and extern. Declaring something extern makes it visible to the linker. Declaring something static makes it invisible to the linker. I don't know what you mean by the word opposite, but I think most people would assume visible and invisible are opposites.

Static and auto are also not opposites. Auto is, of course, redundant, since all variables at function scope are automatically created on the stack at runtime by default.

The two terms cannot be used in unison (there are no static auto variables) and one means the variable is allocated/initialized each time the function is called and the other means the variable is allocated/initialized once. Once again, I don't know what you mean by the word opposite. To me, static and auto are opposites.

 

[D H]

I take it you don't think Python is well-architected?

It appears to be well-architected. I just don't like it.

I don't like end-of-line meaning end-of-statement. One of the best things about forgetting how to do Fortran was forgetting how to make continuation statements.

I don't like the block structure via indentation. Visually impaired programmers (at least those I have worked with) detest indentation (and case-sensitivity, but that is a topic for another day). I learned long ago to use a pretty-printer to make sense of someone elses' indentation scheme. I learned long ago that forcing an indentation scheme is usually not a good idea.

I don't like late binding. I would much prefer the compiler to tell me about errors ASAP.

I don't like toy languages. Python, Pascal (oh yeah, and Basic) are toy languages. You can google "toy language" to see what I mean.

 

[chroot]

It appears to be well-architected. I just don't like it.

You might as well have left it at that, D H. The rest of your arguments are nonsense.

I don't like end-of-line meaning end-of-statement. One of the best things about forgetting how to do Fortran was forgetting how to make continuation statements.

You can use semicolons if you want to. You just don't have to.

I don't like the block structure via indentation. Visually impaired programmers (at least those I have worked with) detest indentation (and case-sensitivity, but that is a topic for another day). I learned long ago to use a pretty-printer to make sense of someone elses' indentation scheme. I learned long ago that forcing an indentation scheme is usually not a good idea.

Everyone who's new to Python follows the same road... most can't even fathom the idea of significant whitespace. The truth is, it removes many pains in the ass (such as figuring out which braces are nested within which braces), but adds a few pains in the ass of its own (such a moving between different editors configured to treat tabs differently). On the whole, it's really not a big enough reason to consider the language with distate. Try it for a couple of weeks, and I guarantee you'll no longer be concerned about it.

I don't like late binding. I would much prefer the compiler to tell me about errors ASAP.

This is a fair issue; but many other languages share it. Good runtime checking eliminates most of the potential problems, though. Late binding opens oh-so-many doorways to powerful, elegant code that it's entirely worth the "risk."

I don't like toy languages. Python, Pascal (oh yeah, and Basic) are toy languages. You can google "toy language" to see what I mean.

That's just asinine. Python is way more useful out of the box than many other supposedly non-toy languages like Perl and C++ and Java. To be honest with you, Java (the most popular language on the planet) is much more what I'd call a toy language than is Python. It sounds to me like you simply have little to no practical experience with the language. Am I correct?

- Warren

 

[D H]

I agree that Java is a "toy language", and for pretty much the same reasons that Kernighan called Pascal a "toy language".

I do not particularly like the way Python is organized. I am not alone in this regard. While proper indentation is nice, it is not something a compiler should use. Yech.

Scary, but true: Some flight software is now written in C++. Fortunately, many of the features of C++ that are touted as "attributes" of the language are forbidden in this use: operator overloading, multiple inheritance, templates, runtime binding: all verbotten. Some of these features are often touted as attributes of Python.

 

[chroot]

I do not particularly like the way Python is organized. I am not alone in this regard. While proper indentation is nice, it is not something a compiler should use. Yech.

Once again, this is just the first stop on the ol' railroad. I was there once, too, and it almost prevented me from even giving the language a serious look. Good thing I opened my mind to it, though, after all.

- Warren

 

[eieio]

You are wrong. One cannot declare something both static and extern. Declaring something extern makes it visible to the linker. Declaring something static makes it invisible to the linker. I don't know what you mean by the word opposite, but I think most people would assume visible and invisible are opposites.

I know you can't use both static and extern at the same time. That would be like saying "hey there is this variable defined in another file, with local linkage, so I can't use it."

Let's turn to an example:

/* A: *declare* to the compiler that there will be an int variable named foo, in some other file*/
extern int foo;

/* B: *define* a variable named bar, with internal linkage */
static int bar;

/* C: *define* a variable named xmas, with external linkage */
int xmas = 25;

int func(void) {
    /* D: *define* a variable named easter, with no linkage */
    static easter = 21;
}

I don't know if there is any way to get this through to you, but for some reason I'm trying anyway.

In case A, there is no actual space reserved for foo at all. In fact, if nothing in the current file makes use of foo, it doesn't even need to be defined in another file, as the linker won't even look for it; it's just a declaration. You can even define it later in the same file if you want. Extern is like a prototype, essentially (and is redundant when used with function prototypes).

In case B, the compiler actually reserves space in the data section (uninitialized data section or BSS/.bss in this case). A symbol is created with local linkage.

In case C, the compiler again reserves space in the data section (initialized data section or DATA/.data). A symbol is created with external linkage. This means that files outside of the of the file can declare this variable extern, and then make use of it.

In case D, the complier again reserves space in the data section (DATA/.data). This is techinically called a static storage duration, but the result is existentially the same as a static global. The difference here is that the symbol is only visible within the scope of the function, and thus has a linkage of none. It's even safe to pass pointers to static locals around, unlike with automatic locals.

Is it not clear how differently static and extern work? Do you notice that case B and D are more silmilar than not? Can you see that the only difference is the symbol scope, which is naturally in line with the scopes of the definitions.

I don't know why you can't accept that static variables within functions are essentially the same as those out side of them. Furthermore, I don't know why you insist there are several different meanings of static. On top of that, I don't see one place in the spec where static is given specifically different meanings. There are several places that expound on the operational meaning, but nothing that indicates in any way that static is "overloaded" in meaning. And I'm not sure what bearing the BNF syntax definition has on how the keyword works. It seems like a thin ploy to misuse the spec to back up a weak argument and lend credence to a personal opinion.

The two terms cannot be used in unison (there are no static auto variables) and one means the variable is allocated/initialized each time the function is called and the other means the variable is allocated/initialized once. Once again, I don't know what you mean by the word opposite. To me, static and auto are opposites.

Ok, so a static local is allocated and initialized once, huh? Pretty much exactly what a static global is, huh? The only difference is the scope, eh? Ok, that really seems like static has a bunch of meanings then, since it has the same result everywhere it is used.

- OMD

 

[rcgldr]

You are incorrect here. The bitwise and/or/xor are higher precedence than the logical and/or. They are, however, lower precedence than relational operators, with good reason. They serve double purpose as non-short-circuit logical operators. For example, f() != 10 && g() == 8 will not execute g() if f() returns 10 , but f() != 10 & g() == 8 will execute g() regardless of the result of f(), with the same overall logical result.

I disagree, I find this usage more common:

if( x & 3 == 0) /* looks like a check for (x modulo 4) == 0*/

& is a bit wise multiply: 0x0=0, 0x1=0, 1x0=0, 1x1=1, so in my opinion (and others), it should have the same precedence as multiply.

^ is a bitwise (finite field) add: 0+0=0, 0+1=1, 1+0=1, 1+1=0, and should have the same precedence as add (or subtract)

| should should also have the same precedence as add (or subtract)

Logical values {FALSE, TRUE}, should have been treated differently than numeric values. Typecasts should be required to treat logical values as numbers.

static

C defines static variables to be initialized to zero. If the target environment doesn't support a zero initialized segment, then static variables have to reside in a initialized data segment. This will increase program size. On a PC, not a big deal, but in embedded applications, space is important. For example:

static int abc; /* initialized to zero, may require program image space */
int xyz; /* uninitialized, normally won't use any program image space */

C provides no means to declare global values

Most linkers include this feature since they auto-generate global values (starting and ending addresses of program segements for example). This can also be done from assembly language (for Masm / ML, simply delcare an equate as public, it will show in the link map as type <absolute>). However, there's no way to do this in C.

Fortran continuation

Place a "*" in the 6th column from the left (column 6 if origin 1 editor, 5 if an origin 0 editor).
Note that C defines require \ at the end of a line for continuation.

pointers in Fortran

Although a bastardization of the language, arrary[0] was the equivalent of a pointer to array in some environments. Delare array[0], and assign array[0]=address to set the pointer, then arrray[index] would access the contents of [address+index-1]. To simplify usages, assign array[0]=address-1 (or - size of variable) so that array[index] == [address+index]

 

[oldtobor]

Hmm, I think you are confusing can't and don't want to. If you want to port EDIT to a UNIX, then go ahead. You'll probably have to learn C if you can get the original source.

If you bothered to look, you would notice a simple editor called PICO, which has many similarities to EDIT, and isn't as difficult for n00bs/fogies as vi can be at first.

- OMD

I have given up a long time ago expecting anything from linux - unix as far as editors. I learned vi. This however is a great example of the linux mindset, we can't do it or do it yourself. Now EDIT for DOS is an old simple program that has been running for years on PCs. How on Earth is it possible that they can't just create a command from any UNIX or LINUX prompt maybe called msedit that opens AN EXACT CLONE OF YOUR GOOD OLD DOS EDITOR ? Why is it so hard ?

Pico sucks (really old fashion, vi is better), and I don't want an editor that has to open in Xwindows, I just want an exact replica of EDIT for DOS!

It can't be done probably for technical reasons, explain so I can understand, maybe it has to do with the terminals, or with how information is going to the screen, I don't know.

It is the same if you try to find a simple keyboard - mouse recorder for linux - unix based GUIs, that is why you can't have something like VBA. Open source rarely progresses any software, open office sucks, and it will stay the same forever. Linux and open source has been a constant dissapointment, and yeah it is always the users fault according to the open source community.

 

[D H]

I disagree, I find this usage more common:

if( x & 3 == 0)

I hope this is a typo. As written, the then branch if the if statement is unreachable. A few parentheses will help. Since == has higher precedence that &, this is the same as
if( x & ( 3 == 0))
Since 3 == 0 is false, this is the same as
if( x & 0)
Since the bitwise and of 0 with anything is 0, this is the same as
if( 0)

If I found anyone writing code like this, I would take that person aside for a little talk.

in my opinion it ("&") should have the same precedence as multiply.

Take your complaints to the standards committee. Until then, live with the precedence rules as they exist.

My rules on precedence are simple (and since I am an old fart, my rules hold sway over a number of people):

1. parentheses
2. element operators (->, .)
3. unary operators
4. multiplicative operators
5. additive operators
6. comparison operators
7. logical operators (&&, ||)
8. assignment operators
9. when in doubt, use rule #1

I don't know and don't care whether && has precedence over || because writing a && b || c is not valid D_H C code.

C provides no means to declare global values

Of course it does: "extern".
Using extern int Foo; in a header file means that the variable "Foo" is defined elsewhere. Including that header file means you don't have to define the variable. You define it by omitting the extern. (Yech.)

Note that C defines require \ at the end of a line for continuation.

No, it does not. Yech.

 

[-Job-]

You know, this is really pointless. Why don't we all spend more time programming and less time arguing.

 

[eieio]

I disagree, I find this usage more common:

if( x & 3 == 0) /* looks like a check for (x modulo 4) == 0*/

& is a bit wise multiply: 0x0=0, 0x1=0, 1x0=0, 1x1=1, so in my opinion (and others), it should have the same precedence as multiply.

I do see the point you are trying to make. However, like I said before, the bitwise operators are also used for non-short-circuit logical operations, which mandates the precedence they have.

And although you may feel like you example is the common case, it really isn't. If you feel up to it, grab any version of any open source operating system or other large C project, and do a regular expression search for all expressions using & and then all expressions using both & and ==. You will find that the vast majority of the expressions will not fit your pattern usage. In fact, bit masking within a conditional is most common, followed by non-short-circuit logical operations.

^ is a bitwise (finite field) add: 0+0=0, 0+1=1, 1+0=1, 1+1=0, and should have the same precedence as add (or subtract)

| should should also have the same precedence as add (or subtract)

That is purely a matter of opinion, which is fine. Most people that do a lot of development in C/C++ perfer the current precedence. Patterns like "(x & 3) == 0" just aren't frequent enough to be worried about having to type some parens.

Logical values {FALSE, TRUE}, should have been treated differently than numeric values. Typecasts should be required to treat logical values as numbers.

That's pure nonsense. As I demonstrated in the bitmask test ("is the device ready or pending"), false == 0 is completely sufficient and even an advantage to concise expression. These kinds of tests happen all of the time--you can use a similar test to above to see this--and it would be quite cumbersome to cast every single bitmask compare. In fact, that's one of the things makes Java so cumbersome for any kind of hardware related development.

C defines static variables to be initialized to zero. If the target environment doesn't support a zero initialized segment, then static variables have to reside in a initialized data segment. This will increase program size. On a PC, not a big deal, but in embedded applications, space is important. For example:

static int abc; /* initialized to zero, may require program image space */
int xyz; /* uninitialized, normally won't use any program image space */

That's not precisely true. Uninitialized globals typically reside in the zero initialized data segment of the image, regardless of wheather they are static or not. Your variable xyz may or may not use image space, depending on if the environment supports uninitialized sections, just like abc.

The behavior can be modified to varying degrees in most compilers, but this is the default behavior for most contemporary compilers.

- OMD

 

[eieio]

I have given up a long time ago expecting anything from linux - unix as far as editors. I learned vi. This however is a great example of the linux mindset, we can't do it or do it yourself.

That's actually a very human mindset. No one wants to port an ill featured editor to Linux for you. There's no benefit for them, since there are perfectly fine editors available. Perhaps if you paid someone, they would port EDIT for you, but you really can't expect something for nothing. People contribute to open source software because they have some interest in what they are producing. No one is interested in EDIT but you, which is why I suggested that you do it.

Now EDIT for DOS is an old simple program that has been running for years on PCs. How on Earth is it possible that they can't just create a command from any UNIX or LINUX prompt maybe called msedit that opens AN EXACT CLONE OF YOUR GOOD OLD DOS EDITOR ? Why is it so hard ?

It has nothing to do with it being hard, it's actually very possible to do. But the point you seem to be unable to grasp it that no one cares to provide EDIT. I've noticed that you have a pattern of coming to the conclusion that people are unable to do something, when they simply don't want to.

Pico sucks (really old fashion, vi is better), and I don't want an editor that has to open in Xwindows, I just want an exact replica of EDIT for DOS!

Hey, it was just a suggestion. And by they way, EMACS can run in a terminal as well as in a window under X.

It can't be done probably for technical reasons, explain so I can understand, maybe it has to do with the terminals, or with how information is going to the screen, I don't know.

Again, it can be done, but no one wants to. You seem to want it a lot though, so maybe you should look into it. It might even be fun for you.

Open source rarely progresses any software, open office sucks, and it will stay the same forever. Linux and open source has been a constant dissapointment, and yeah it is always the users fault according to the open source community.

Well, in one sense you are right, open source is not the answer for everything. But it has produced some very useful projects, especially a large volume of libraries that can benefit everyone's development.

Opinions are fine, if you can keep then in check and not treat them like fact that everyone else should believe and follow. I don't particularly care for Open Office myself. I like MS Word, personally. But I'm not going to bash someone for liking Open Office or thinking that it's good. I will, however, call someone out for making biased assertions or stating incorrect facts to promote their opinions.

I think you would get more positive responses if you tried a more genial approach to things. If you said something like "man, I wish there was something more familiar to me, like EDIT, on Linux. That would be great." You might be surprised, someone might just decide to do it for you; maybe someone wanting to get familiar with the curses library, as an exercise. However, you can't just badmouth things and then expect people to be ready and willing to implement your ideas/requests.

- OMD