Re: Writing single bits to a file

"cr88192" <cr88192@xxxxxxxxxxxxxxxxxx> a écrit dans le message de news:
8b8cb$472537c7$ca8010a3$22288@xxxxxxxxxxxxx
"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.

const does help finding semantic issues. 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. Believe me, const is very helpful.

<>

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, ...).

You should try some of the freely available validation suites. Well
actually there aren't that many: gcc has a lot of stuff, and same for the
glibc.

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...).

You need to find a way to put these under the programmer's control, with
custom definable precedence and associativity, while keeping the parser
efficient: a non trivial thing.

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...).

..+ has quirks: double x = 1.+y;

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...).

You seem very focussed on floating point stuff. I think ~ as an infix
operator should be a bitwise nand with the same priority as &: a ~ b would
be the same as a & ~b. This is quite consistent with the other bitwise
operators and with its unary function. dealing with bit flags would be
neater this way:

if (value) flags |= FLAG; else flags ~= FLAG;

infix ~ could have other semantics for non integer operands: it is quite
appropriate for string concatenation, but you specific memory mangement for
that, and almost unavoidably garbage collection.

for exponentiation, I would suggest you do use ** as in Fortran. It is not
ambiguous because a ** b has no meaning for b scalar or struct type. You
would need to bend the grammar a bit, but at least the precedence would be
much better suited than that of ^

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

I you do add string concatenation (after all you have GC if I recall
correctly), you should consider implementing the $ substitution inside
strings, à la Perl or PHP. To preserve compatibility with C, these should
be a different type of strings, either delimited with `` or prefixed with a
letter or a % or whatever.

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

Yes, some like it more than others ;-)

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

I can relate to that: I like to implement scripting languages for breakfast
now and then.

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).

Good C programmers learn to be careful, and humble too.

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

Actually they do occur: approximate programming with scripting languages is
pretty common. In javascript, type mismatches are hard to catch because
because + for instance is both numeric addition and string concatenation
with implicit conversion!

(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...).

simplicity is a greater goal.

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

I thought you were younger, and still under parental control.
Where are you studying theology? How long to go?

or such...

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


habit I guess...

Good night.

--
Chqrlie.


.

Relevant Pages

  • Re: const
    ... > const modifiers, ... willing to remove the const'ness with a cast, ... I don't know how good a cross-file compiler could be - it would have to be ... it's a guarantee by the programmer. ...
    (comp.programming)
  • Re: Index a #define string
    ... In this case, i wouldn't use an array myself but a const char * const, but ... should one make it of static storage? ... If they were on the stack, where do you think their values ... You mean that the compiler optimises it out. ...
    (comp.lang.cpp)
  • 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: How to define a const and initialize it?
    ... > do the same work as const int MYCONST will do.... ... But the thing is that macro substitution takes ... C++ compiler isn't even aware of its existence. ... This Item might better be called "prefer the compiler to the preprocessor," because #define is often ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Most Economical VB Development Compiler
    ... You can only define a conditional compiler constant to have one value. ... Attempting to do so produces a "Compile Error: ...
    (microsoft.public.vb.winapi)