On a sunny day (Fri, 15 May 2009 22:53:56 +0100) it happened Nobody wrote in :
./test2 memory needed=384 MB
This because it is (64M * 4) + (64M * 2). From in C: fprintf(stderr, "memory needed=%d MB\\n", ( (BIG_SIZE * sizeof(int32_t) ) + (BIG_SIZE * sizeof(int16_t) ) ) / 1000000 );
Plus you need some for the OS and loaded modules, but not much in Linux.
ound 'DYNAMIC' in ''$DYNAMIC'
Ah yes, I think I use -lang qb, something like that. Call me old skool. :-p
Without the dynamic allocation, the rest of the errors figure...
Say, what's the "3D" in this showing up for? Did you copy&paste wrong, or did my message get encoded stupid, or did yours?
I use it fairly regularly. Despite being DOS, an exorbitantly inefficient environment, it still runs on XP, and does things that (in lieu of a similarly powerful scripting language) are satisfactory for my purposes. I could do C, but I don't know it nearly as well as I know QuickBasic.
Tim
On a sunny day (Fri, 15 May 2009 21:24:06 -0700 (PDT)) it happened Tim Williams wrote in :
Yes, copy and paste, but I left it as it had not enough stack space anyways,,,
BASIC is so simple to use, but I have so much C code and apps written now that complicated things like networking would take me a hard time in BASIC. But this one is nice to have around for doing some quick calculations I think. There are so many of those high level languages with powerful networking around these days,,, C is for me some universal thing that does it all without me having to learn yet an other language.
I get really weird time printouts with that. Using FreeBasic 0.18.
time ./test One pass in 19.935 seconds. ./test 0.26s user 0.18s system 95% cpu 0.453 total
1E9*E!/(10*64E6)) 32-integer sums.
duration more reasonable.
functions.
Re: My program is prettier.
I don't think so. For one thing your program is shouting.
That would be (I guess is) weird.
1E9*E!/(10*64E6)) 32-integer sums.
duration more reasonable.
functions.
Real programmers don't use lower case.
John
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
ER
RND()!
, 1E9*E!/(10*64E6))
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
nto 64-million 32-integer sums.
ake the measurement duration more reasonable.
he system("date") functions.
ort ) *
und_data,
=A0 =A0 =A0// 10 x
IZE; ++index )
bound_data[index];
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
Nah. Real Programmers don't use anything with 'case' at all. (Which I guess includes binary, octal and decimal, as well as any entry method, especially panel switches.)
Tim
1E9*E!/(10*64E6)) 32-integer sums.
measurement duration more reasonable.
system("date") functions.
The impressive thing about C and C++, as languages and as a culture, is that as programmers become more experienced and "skilled", the readability of their code drops and the bug rate remains high.
John
On a sunny day (Sat, 16 May 2009 10:49:28 -0700) it happened John Larkin wrote in :
Well, you should state : "I think that", as it is clearly an opinion not supported by any real data.
The bug rate is normally very low, for C programs (dunno about C+++, I do not consider that a language, so you could well be right about that), there a 2 very basic sort of errors in C programs. One is the program flow itself: does it actually do what you want it to do, that is probably the same for all languages and is the essence of programming, the other is out of range pointers and that includes not checking return values like somebody did here in his C example, but that is bad practice.
That you cannot read C does not make it less readable by a C programmer. I cannot read Japanese, so I cannot give an opinion on Japanese writings, you cannot read C, so how can you give an opinion on C writings?
PS, some remark about *your* C programmer, not to piss him / her off, but something I consider very important, he /she uses 'short' and 'int' and 'unsiged short' etc... One should always specify the size of the variables, as those may be different on different machines:
This is from libc.info, the reference for C programming with gcc: Integers ========
The C language defines several integer data types: integer, short integer, long integer, and character, all in both signed and unsigned varieties. The GNU C compiler extends the language to contain long long integers as well.
The C integer types were intended to allow code to be portable among machines with different inherent data sizes (word sizes), so each type may have different ranges on different machines. The problem with this is that a program often needs to be written for a particular range of integers, and sometimes must be written for a particular size of storage, regardless of what machine the program runs on.
To address this problem, the GNU C library contains C type definitions you can use to declare integers that meet your exact needs. Because the GNU C library header files are customized to a specific machine, your program source code doesn't have to be.
These `typedef's are in `stdint.h'.
If you require that an integer be represented in exactly N bits, use one of the following types, with the obvious mapping to bit size and signedness:
If your C compiler and target machine do not allow integers of a certain size, the corresponding above type does not exist.
If you don't need a specific storage size, but want the smallest data structure with _at least_ N bits, use one of these:
If you don't need a specific storage size, but want the data structure that allows the fastest access while having at least N bits (and among data structures with the same access speed, the smallest one), use one of these:
If you want an integer with the widest range possible on the platform on which it is being used, use one of the following. If you use these, you should write code that takes into account the variable size and range of the integer.
The GNU C library also provides macros that tell you the maximum and minimum possible values for each integer data type. The macro names follow these examples: `INT32_MAX', `UINT8_MAX', `INT_FAST32_MIN', `INT_LEAST64_MIN', `UINTMAX_MAX', `INTMAX_MAX', `INTMAX_MIN'. Note that there are no macros for unsigned integer minima. These are always zero.
There are similar macros for use with C's built in integer types which should come with your C compiler. These are described in *Note Data Type Measurements::.
Don't forget you can use the C `sizeof' function with any of these data types to get the number of bytes of storage each uses.
File: libc.info, Node: Integer Division, Next: Floating Point Numbers, Prev: Integers, Up: Arithmetic
on
If you have a specific number of bits in mind, use the types.
OTOH, if you need compatibility with library functions, use the appropriate types (which are usually platform-specific). E.g. printf("%d") needs int not int32_t, malloc() wants size_t, etc.
This is more of an issue for pointers. The compiler will cast numeric values as needed, but it won't convert pointer targets, so don't pass a pointer to an int32_t to a function which expects an int* (casting the pointer won't help; you need to convert the data).
You also need to remember C's implicit casting rules, which can produce some fairly awkward interactions if you mix platform-specific types (int, long, ...) with fixed-width types from .
In my experience bugs have more to do with being sloppy (typos), misunderstanding multi-threading and bad design (or no design at all).
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn\'t fit, use a bigger hammer!"
--------------------------------------------------------------
' EPORT : OPEN TCP/IP PORT AS # 8
EPORT:
TCP CLOSE # 8 ' NUKE ANY OPEN ETHERNET COMM CLOSE # 1 ' OR SERIAL PORT
CPORT% = 0
LOCATE 18, 1
PRINT " Default IP address = "; IP1$ PRINT PRINT " Enter IP address, D for Default : ";
LINE INPUT IP$ IF UCASE$(IP$) = "D" THEN IP$ = IP1$
IF IP$ = "" THEN GOTO TOP
ERRCLEAR
TCP OPEN PORT 2000 AT IP$ AS # 8 TIMEOUT 50 CPORT% = 8
IF ERR THEN
LOCATE 22, 10: PRINT "TCP OPEN ERROR" SLEEP 2000 CPORT% = 0
END IF
TCP RECV #8, 2000, B$ ' FLUSH THE TCP BUFFER!
GOTO TOP
and then later, you can...
' CHECK FOR INCOMING TRAFFIC FROM T344...
TANK:
RPLY$ = ""
IF CPORT% = 8 THEN TCP RECV #8, 1, RPLY$ ' GET ONE (!) ETHERNET BYTE ELSE N& = COMM (#1, RXQUE) ' SERIAL: CHECK BUFFER CONTENTS IF N& THEN COMM RECV #1, 1, RPLY$ ' GET ONE BYTE FROM BUFFER END IF
This is insanely easy.
PB can also, easily, do UDP, SMPT, all that stuff. And all the tools are inherent to the language, not external libraries. Which means everything is clearly documented, both in manuals and in the built-in Help thing. All it does is work.
John
Do C programmers ever read code? They seem to seldom read their own, except when forced to look for a bug.
I have seen scads of "professionally" written C that was an uncommented, buggy mess, with code commented out all over the place without explanation. It's a bummer to spend time trying to understand a hunk of code only to discover a little /* thing somewhere above.
John
Bugs have mostly to do with typing fast, not reading and checking, and running the code to find some of the bugs. Languages like C encourage dense, risky, tricky code. Languages like Ada do everything they can to discourage it. Most programmers hate languages like Ada and Basic because they slow them down and make them think.
C also allows all sorts of memory-management and variable type/range errors that no modern language should allow to happen. Malloc, memcpy, wild pointers, things like that. It's barbaric.
Extreme Programming makes the case that two programmers writing a piece of code on one shared screen is more efficient, on average, than one programmer. That's pitiful.
You can't argue that C (and its culture) generally results in good or secure executables, because it so obviously doesn't.
John
On a sunny day (Sat, 16 May 2009 13:41:07 -0700) it happened John Larkin wrote in :
That is very nice, never knew a BASIC could do that.
On a sunny day (Sat, 16 May 2009 13:46:58 -0700) it happened John Larkin wrote in :
/* LOL, no that did not happen to me, yes I am the one who writes comments that way.
*/#define ONE 1 int small = 2; int i; for(i = 0; i < small; i += ONE) { /* I guess it is like using an editor with coloring, if freaked me out, I like black on white, cannot read green on a white background (I always use white background in the editor because the light level is then more constant), such things as 'if' 'for(' and other keywords read, at least to me, and that includes '/*' and '*/', as normal words in a text. Imagine a novel with all nouns in a different color, Oh, should not have mentioned it, somebody is gonna read this and try. As to comments, if you use sane variable names, and no 'a' 'b' 'c' only, then the code is very much self explaining.
*/ fprintf(stderr, "Hello.\\n"); }On a sunny day (Sat, 16 May 2009 13:59:30 -0700) it happened John Larkin wrote in :
Obviously does, as Linux is written in C (the kernel, the drivers, and many if not most applications).
C++ OTOH is not something I consider a language, and you may be right about that.
But C is like having the soldering iron on the hardware so to speak. You can do anything right, and anything wrong. While other languages (except for asm) have some more distance, Like you on the bench with the remote control.
For real design C is a must :-) For user work BASIC will do.
;-)
To be a bit more serious, the old BASIC had those gotos and line numbers, you got stuck with no space between line numbers, and needed a renumber routine. I found asm much more easy than that BASIC because the assembler allowed me nice long labels. BASIC has come a long way since then.
That depends on what they need to think about. Usually it is a workaround for a crappy language. Look at the amount of extensions Borland put into Delphi. Its almost like C.
Most of this stuff is deprecated. IIRC most modern compilers have an option that will start to complain when insecure functions are being used. The C++ STL library contains a huge amount of memory management, string handling, linked list, etc functions that make it totally unnecessary to deal with memory yourself.
That is like saying more people are killed by people driving a Corvette than a Ford.
You can argue this either way. Languages like C# and Java catch all kinds of errors. This means the programmers have to worry even less about cleaning up. On the other side C/C++ don't allow to let a pointer slip away. The program will crash. Anyway, good programmers that have an eye for security, resillience / recovery, timing / deterministic behaviour and multi-threading are very scarce.
I still believe that a good piece of software starts with a good design. No matter what language is being used.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn\'t fit, use a bigger hammer!"
--------------------------------------------------------------
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.