Re: Writing single bits to a file


"Charlie Gordon" <news@xxxxxxxxxxx> wrote in message news:4724b4ac$0$3831$426a74cc@xxxxxxxxxxxxxxx
"cr88192" <cr88192@xxxxxxxxxxx> a écrit dans le message de news: 134ba$47249c9e$ca8010a3$29217@xxxxxxxxxxxxx

"James Kuyper" <jameskuyper@xxxxxxxxxxx> wrote in message news:vQ_Ui.3729$R%4.932@xxxxxxxxxxx
cr88192 wrote:
...
'const' is a keyword I don't really know if I have ever really used...

reason: it doesn't really do anything, beyond telling the compiler to complain to me about stuff I should sanely know already anyways...

The 'const' keyword provides the same kind of benefit that prototypes do: you declare something about how an identifier is intended to be used, enabling the compiler to warn you if it detects the fact that you accidentally use it in a manner different from the what the declaration says. Then you get to decide whether it's the declaration or the usage that is incorrect. This is one of the many things that the compiler can check far quicker and more reliably than I can.


prototypes provide a lot more:
they actually make the type handling work right...

(well, that and as a side benefiet, I use them to help reinfoce modularity...).

James said "the same kind", not "the same amount".
I do enable a ton of warnings, and use extra tools such as valgrind, sparse, and custom made ones.
I haven't looked at your compiler yet, I'm willing to bet the code would benefit from such a treatment.


potentially...
actually, I am ending up endlessly debugging and fixing things, but not so much syntactic, primarily semantic issues.

a recent example was rigging up some 'bypass' code to allow me to more effieciently move floats and doubles between the FPU and SSE (happens, say, whenever one uses sin or cos), because, as it was before, this operation would end up flushing the register allocator (bad...). now, it is just storing into memory (the bottom of the compiler's notion of the stack) on one end, and loading from the other (still not sure why x86 lacks opcodes like 'fld32 xmm3', or 'fstp64 xmm0', these would be useful...).


another recent example was noting that my expression parsing, didn't exactly closely match the C operator precedence rules (noted in part, because me typing '*(vec3 *)(&v0)', failed to parse right...).

to a large degree, my parser was just sort of reused from my last scripting language and beaten into shape, but I had failed to notice that I had not gone and more correctly fixed up the precedence heirarchy (unary and postfix operators were the same precedence, bitwise operators were the same as normal arithmetic operators, ...).


so, now, everything is much more closely in tune with the C stadard, for better or for worse (I don't entirely like C's precedence rules, but then again, this is partly why my last script lang did them differently, but in any case conformance forces me to live with them...).

well, at least in the upper-end of my parser (tokenizer mostly), I have gone and added more operator and brace types (12 new brace types, based on character combos that should not occure in valid well-formed C, and 22 new operator tokens). more are possible if one is willing to go into the land of horrible-looking tokens ('#<. stuff .>' is allready pretty bad...).

if I used them, it would be mostly for compiler and language extensions (the operators specifically to be overloaded...).

most of the operators take forms like '+.' or '.+', and I will define that they have precedence similar to those of the operators they resemble (unless defined for something, it will be an error to try to use them though...).

I also added '~' as an infix operator, which I am considering will operate like an exponent operator ('a~3', since 'a^b' generally means xor, and 'a**b' is ambiguous). it could also serve as an alternative for 'dot product', which is currently handled with '^', which, sadly, has a very low precedence (this however, becomes ambiguous for quaternions, which are both numeric and vector, and thus can have both exponents and dot product...).

could potentially also add `, as an operator, since it is not otherwise used as a quote ('2`3', 'u`v', ...). likewise for @ and $ (though gcc allows the latter in names, I may not, but as of yet I am undecided...).
hmm...

but, whatever, all this is non-standard anyways...

(my great cost: before writing a C compiler, I implemented script languages, I guess I still sort of think in this way...).


True, if I were a perfect programmer, I would never need that warning. I don't know any perfect programmers. I'm certainly not one, and I'll happily do what's needed to enable this kind of warning.

and I am also a person who writes some amount of stuff in assembler as well, where assembler provides no such niceties...

I ride motorbikes, yet I fasten my seat belt in a car. Why take risks all the time?


point is, bugs usually pop up, and with practice, one develops a tendency to specifically avoid certain kinds of problems (the more painful the problem, the more highly the user learns to avoid it). as a result, for people using assembler, they learn to be careful, since even trivial errors will not be caught by assembler, and will proceed to become potentially hard to track down bugs (one develops a kind of 'blank stare' code checking ability).

making something easier, just makes it less painful to make errors, and thus errors become more frequent.

I suspect this is also very likely the case with programmers who primarily use statically typed languages that go over and use dynamically typed ones. since they have not really felt the pain of the compiler missing their type errors, they are a lot more likely to miss them, which is why, I think, paradoxically, many good old C and C++ programmers experience pain with many script languages, yet newbs seem a lot more adept at learning them, and old timers assert that these kind of errors don't really occur...

(many such people also assert that one gets used to lisp style syntax, but I never really stopped thinking that it looked ugly, nor did I ever really like having to use emacs to avoid the pain this kind of syntax causes when edited in notepad...).

meanwhile, in general, I like power and capability, at the possibly necessary cost of comfort (and stability...).


however, it is my belief that what const offers, for the most part, is something people will have already long-since internalized. unlike some other errors, these are likely to have a much lower chance of random-chance incedence, which most often consist of IME missing/mistyped variables, major type errors (often caused by another error), and missing/mixing function arguments...

assigning a read-only variable is a little less likely, on the grounds that this action is far more likely to be deliberate.

const correctness, although it requires discipline, pays off.
You are probably a bit young and still remember everything you type, when you start experiencing memory lapses (from 25 up) you will find all these little tricks pretty handy.


well, I don't remeber everything I type (there is just too much...).
as for age, I am getting there, sadly...
not 25 yet, but sadly, it is no longer that far away.
I am getting old it seems...


or such...

What do you mean by that? or it your signature? or such ...


habit I guess...


--
Chqrlie.


.

Relevant Pages

  • Re: Writing single bits to a file
    ... The 'const' keyword provides the same kind of benefit that prototypes ... enabling the compiler to warn you if it detects the fact that you ... I had not gone and more correctly fixed up the precedence heirarchy (unary ... I like to implement scripting languages for breakfast ...
    (comp.lang.c)
  • Re: Writing single bits to a file
    ... The 'const' keyword provides the same kind of benefit that prototypes do: you declare something about how an identifier is intended to be used, enabling the compiler to warn you if it detects the fact that you accidentally use it in a manner different from the what the declaration says. ... Just a moment ago, I was reviewing Jacobs StringCollection module: he does not use const either, and as I added constness for function arguments that should not be modified, I discovered a few allocation bugs where string were not duplicated as they should have been. ... exactly closely match the C operator precedence rules ', failed to parse right...). ... well, at least in the upper-end of my parser, I have gone and added more operator and brace types. ...
    (comp.lang.c)
  • Re: f() + g() * h()
    ... Operator precedence and explicit parentheses impose only a partial ... ordering on the evaluation of an expression. ... code can be made faster if the compiler rewrites it as ... A sufficiently smart compiler might even calculate sqrt ...
    (comp.lang.c)
  • Re: Function call evaluation order
    ... How do you propose to explain in terms of precedence and associativity the ... Your expectations have been tuned to match what your compiler does! ... Undefined behavior is behavior that is not defined by the C++ standard. ...
    (microsoft.public.vc.language)
  • Re: What micros do you actually hate to work with?
    ... with less than tiny asm ... hassle to work with 32 bit longs in assembler for an 8 bit uP, ... Microchip's C compiler tools and their assembly under MPLAB. ... is that other programmers for C are easier to find. ...
    (comp.arch.embedded)