How many instructions are there ?

[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/,<_>"

:rofl: 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?? :rofl:

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

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

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

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

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

 

[chroot]

EDIT on Linux would be what, fewer than 1k lines of curses? It'd be almost trivial.

But EDIT doesn't have syntax highlighting, automatic tabbing, multiple-file searching, or any of the other features that people really want in a text editor; this is why no one has ever bothered to port it to Unix/curses. If all you want is to be able to move the cursor around with the arrow keys, then use pico and get on with your life. Pico is almost exactly the same as EDIT.

- Warren

 

[oldtobor]

Why is it so hard to create an exact clone of EDIT from a unix - linux prompt ? I am sure that there must be some technical reason, maybe the terminals or the way the information goes to the screen, but an EDIT program should be relatively simple for an open source programmer to write, since they are writing operating system software, but I am sure there is a real technical reason. Please explain, because the EDIT program is very simple and convenient.

But what really intrigues me is that there must be some real, technical, fundamental limit of the unix architecture that prevents the creation of a simple program like DOS EDIT from the prompt. It is only 70k under windows (dos) and is a very simple straightforward program. I find it really mysterious that after more than 10 years no one in the unix or linux OSS community of programmers could create an exact replica.

I am absolutely convinced that it cannot be done. It is a simple program that would be handy to many people. There must be some real architectural reason. If you say the entire UNIX and LINUX community in 20 years, millions of people all decide no, it is forbidden to have EDIT, I truly cannot believe that. People are pragmatic, want to get things done fast, have problems to solve, EDIT would be just another quick simple tool you can use.

The funny thing is that the unix philosophy is all about small simple programs that can get a simple job done fast, like grep or awk etc. So it is perfectly within the spirit of unix or linux. Now there are more powerful choices, but in many cases, small scripts, you just don't need the power. After all grep for example finds patterns quickly and easily. There are more powerful database programs, obviously, but for something quick and simple grep is ok.

If on the other hand you are right, no one wants it, it will never be done, then that is a good example of what you can expect from the open source community in the future. They will make thousands of arcane programs and languages, but simple things that any person could appreciate and use like EDIT for DOS, or ACCESS or similar simply will never be done.

It is as if thousands of programmers have exactly the same mind set, the exact same opinions and tastes in everything. Like a religion or as if they were brainwashed against anything even remotely similar to anything PC or windows. Then why are they trying so hard to make the windows emulator WINE ?

 

[chroot]

You're an idiot, oldtobor. Why do you keep repeating things? Are you here for discussion, or just to rant about incoherent nonsense? You think there's something fundamental about Unix operating system that precludes the development of a goddamn trivial text editor? There are many editors for Unix that are so similar to EDIT that there's no reason to write another one! Look at pico. LOOK AT PICO. LOOK AT PICO.

What exactly about pico do you not like?!?

- Warren

 

[rcgldr]

if( x & ( 3 == 0))

As written, the then branch if the if statement is unreachable.

That was my point, it wouldn't work unless C treated the precedence of & the same as *, which it doesn't. My point about the precedence is that &, ^, and | are math operators, and should have been given the same precedence as the other math operators, but that's not the way the C language was defined.

C provides no means to declare global values

Of course it does: "extern". Using "extern int Foo;" ...

Note, I posted global "values", not global "variables". For example, how would you decleare "abc" in this case "#define abc 0x12345"? This is easily done in assembler as prevously posted (public abc ... abc EQU 012345h). One example usage is to implement the equivalent of "sizeof(relocatable function)".

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

No, it does not.

Yes it does, note I'm referring to "defines", for example, large macros, \ is required to extend a #define across multiple lines.

C defines static variables to be initialized to zero. ... occupies space

That's not precisely true.

Microsoft reference:

When modifying a variable, the static keyword specifies that the variable has static duration (it is allocated when the program begins and deallocated when the program ends) and initializes it to 0 unless another value is specified.

Uninitialized globals typically reside in the zero initialized data segment of the image.

Most wintel environments don't include a zero initialized segment, thus statics end up in the .data segment, and non-initialized variables in the .bss segment.

For the ARM (a risc processor environment, it's not an issue as all zero initialized variables are placed at the end of the .data segment, and the linker defines global values for "end of normal initialized .data / start of zero initialized .data" and "end of zero initialized data" for the start up routine to zero out. It also generates global values to allow code and data relocation for embedded environments.

vi

My main complaint about vi derivatives is that they have to be toggled in and out of text insert / command mode. I prefer using some key sequence to generate commands. I find generic editors like codewright much easier to use (I use it in CUA mode).

getting back on topic

As previously posted, C is a mid-level language, between assembler and true high-end languages. It doesn't include exponentiation, and requires a call. Conversion of mathematical algorithms to C is a pain compared to Fortan, or MatLab. Cobol still has it's place in dealing with database (field oriented) environments on mainframes. Oracle and other SQL languages are also good for database environments. Not all software problems were solved in the 1980's on a PC. Some problems were solved long before that, and some problems were solved more recently.

 

[eieio]

Most wintel environments don't include a zero initialized segment, thus statics end up in the .data segment, and non-initialized variables in the .bss segment.

This is also incorrect. The .bss section IS the uninitialized data section. This section has the IMAGE_SCN_CNT_UNINITIALIZED_DATA bit set in the Characteristics field of the section header. I've implemented PE-COFF executable loaders and object file linkers on several platforms. Here's the official spec, if you're interested: http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx
Check out around page 18.

In any case, both globals that are explicitly initialized to zero and uninitialized globals end up there, not in the .data section, unless you specifically override it (__attribute__ ((__section__ (".data"))), in GCC for instance). Furthermore, the zeroing of the section is usually performed as the executable is mapped into the process, and is either part of the loader or an effect of creating a private mapping of the zero page, or similar VM operation.

I haven't done much work with ARM, but the platform doesn't really matter per se, as it is the executable format that provides such features. Most operating systems that run on ARM use ELF, which follows the same general scheme as the PE-COFF description above.

I'm curious about your microsoft reference; you didn't cite it, but it looks like a rather generic functional description of what happens, not actually what happens. Maybe if you provide a citation, I can show you why it's not as definitive as you believe. :uhh:

- OMD

 

[DaveC426913]

None of it will be maintained forever, it will all be discarded and replaced by new, more capable code.

That's the second(*) biggest mistake in the history of the business.

The whole Y2K thing happened because no rational programmer thought their code could possibly live for 2 or 3 decades.

And yet banks are still running their COBOL applications from the 80s.



(*second only to Bill Gates' gaff of legend)

 

[NoTime]

That's the second(*) biggest mistake in the history of the business.

The whole Y2K thing happened because no rational programmer thought their code could possibly live for 2 or 3 decades.

And yet banks are still running their COBOL applications from the 80s.

(*second only to Bill Gates' gaff of legend)

:rofl: To both.
Did you know there was a year 10 issue?
Initially they started with 1 digit year :uhh:

There was a good reason for doing so though.
The first machine I wrote code for had 20k of memory.
That was huge.
It came out of the box with 4k of real core memory.
Little ferrite donuts strung in a wire matrix.

You spent a lot of time trying to scare up a free bit or two somewhere.
Allocating an entire 16 bits for '19' was simply out of the question.

When BG came out with the 640k comment, the multitasking mainframes had just become available with 1 meg memory just a few years prior.
'Only Six computers will ever be sold in the commercial market'
Howard Aiken (The designer of the first IBM computer)


PS: vi is a horrible editor.
It was, however, a lot better than card punch.
Considering modern editors, I find it hard to believe it's still around for use.

 

[rcgldr]

Most wintel environments don't include a zero initialized segment, thus statics end up in the .data segment, and non-initialized variables in the .bss segment.

This is also incorrect. The .bss section is the uninitialized data section.

I specifically mentioned a zero initialized section, not an unitialized section. However, it appears that the Wintel environment does zero all of the .bss segment. I also discovered that unitialized global variables ended up in the .data segment. In debug builds, the stack is initialized to 0xcccccccc, so local unitialized variables will be set to "c...c", in release builds I assume that no initialization is done.

In any case, both globals that are explicitly initialized to zero and uninitialized globals end up there, not in the .data section

I just tested this with Visual Studio 2005. A static variable ends up in the .bss section if there's no initializer, or it ends up in the .data segment if there is an initializer. As mentioned, I was suprised to find that an uninitialized global variable ended up in the .data segement and set to zero.

The platform doesn't really matter per se, as it is the executable format that provides such features.

Well the linker has to generate global values for a startup program to know what sections need to be zeroed out, or the executable format will need to include all of the .data / .bss sections, including the zeroed out section. I read the document you linked to and in section 5.1, it states that zero only sections images don't have to be included in the object file, which implies the startup routine clears these sections.

As mentioned, the Wintel environment appears to zero out all of .bss section. In the Arm environment, only a portion of the .bss segment is zeroed out, with the remainder remaining truly unitialized, which I assume is to reduce the execution time. Global values are generated by the linker, that indicate the location and size of the zero initialized logical segment which is the first part of the .bss segment.

I'm curious about your microsoft reference

It's from Visual Studio 2005, click on help, search for static, then click on C/C++ link and you get this: http://jeffareid.net/misc/static.jpg .

When BG came out with the 640k comment, the multitasking mainframes had just become available with 1 meg memory just a few years prior.

Back in 1986, when Atari came out with the 68000 based ST1024 system with 1 meg of memory for under $1000, I and other programmer / engineers asked how long it would be before people started commenting, you only have 1 meg of memory in your computer. Eventually the Atari series reached 4MB of ram before it sold off it's computer division to a European company, the only place where sales were still reasonable. The point here is that a lot of engineers realized that home computer memory sizes were going to continue to grow.

Regarding memory sizes on mainframes, high end IBM 360's and 370's had 1MB or more of memory during the 1960's and 1970's. By 1985, a Cray 2 super computer had 512MB of memory.

 

[oldtobor]

You're an idiot, oldtobor. Why do you keep repeating things? Are you here for discussion, or just to rant about incoherent nonsense? You think there's something fundamental about Unix operating system that precludes the development of a goddamn trivial text editor? There are many editors for Unix that are so similar to EDIT that there's no reason to write another one! Look at pico. LOOK AT PICO. LOOK AT PICO.

What exactly about pico do you not like?!?

- Warren

I downloaded and tried a PICO for DOS version. It is not too bad, better than vi, at least simpler. The question ws about an exact replica of DOS, but I think I found out why. During the late 80s, early 90s there were many full screen DOS programs around, but the unix environment was very separated from the PC users (unix being very high end professional). You could more easily find unix utilities (like awk already in 1989 by polytron) ported to DOS than vice versa. It was like someone asking to port DOS basic to IBM MVS, it didn't make sense. Then came windows gui and then linux. With linux the possibility of porting any DOS to unix became virtually zero because DOS was no longer even on the radar and because of hostility for anything DOS by OSS programmers.

I just wonder how it might have evolved if all those full screen DOS programs were ported as exact replicas to unix, unix - prompt. Like turbo pascal, or quick basic, etc.

 

[NoTime]

Regarding memory sizes on mainframes, high end IBM 360's and 370's had 1MB or more of memory during the 1960's and 1970's. By 1985, a Cray 2 super computer had 512MB of memory.

The IBM 360 was constrained to a max of 64k memory.
In the company I worked for, we had 5 370's, the biggest was 512k until 78 when they upgraded to a meg.
I think they did it to support TCAM the predecessor to VTAM.
The IBM 370 was constrained to 268 meg until around 84 when they came out with XA.
That was a PITA due to all the software that had used the upper 4 bits of the address to pass flags.