Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Writing single bits to a file

Reply
Thread Tools

Writing single bits to a file

 
 
cr88192
Guest
Posts: n/a
 
      10-28-2007

"CBFalconer" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> cr88192 wrote:
>>

> ... snip ...
>>
>> I will disagree with the casting the result of malloc.
>>
>> main reason:
>> it is necessary if one wants their code to compile in both C and
>> C++ compilers, since C++ usually raises a big fuss about uncast
>> conversions to/from 'void *'...

>
> If you write code and try to routinely compile it with both C and
> C++ compilers you deserve whatever happens to you. The languages
> are _different_. The multiple compilers is not normally useful
> anyhow, since you can always compile C in such a manner as to be
> linkable to C++, but not the reverse.
>


at the time, it was an issue of whether or not I wanted C++ style name
mangling in the object files (after all, this mangling gives at least some
useful type info). eventually I decided that I did not (the proposition
posed more problems than it was worth).

as for C and C++ being different:
they are similar enough here that there is not much real problem in making
code that will work on both, as most of the differences at this level are
minor and fairly trivial to deal with.

eventually, I normalized on using good old plain and unmangled names (and,
more so, internally normalizing on not having underscore prefixes, though on
windows, this is still the convention within the object and exe files...).

and so on...


> --
> Chuck F (cbfalconer at maineline dot net)
> Available for consulting/temporary embedded and systems.
> <http://cbfalconer.home.att.net>
>
>
>
> --
> Posted via a free Usenet account from http://www.teranews.com
>



 
Reply With Quote
 
 
 
 
Willem
Guest
Posts: n/a
 
      10-28-2007
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...

And telling the compiler that it can do certain optimizations.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
 
Reply With Quote
 
 
 
 
cr88192
Guest
Posts: n/a
 
      10-28-2007

"Willem" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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...
>
> And telling the compiler that it can do certain optimizations.
>


potentially, I guess, if the compiler does not figure this out on its own...

I guess it provides a means for constant folding:
const int foo=3;
....

if(foo) //well now, here we know it is 3...
{ ... }

but, I don't really see why one can't do similar by use of a dirty/clean
flag here (where a variable is dirty if not provable clean). this approach
worked in the past when I was writing interpreters (I guess const serves to
indicate that it is always clean...).


actually, in my compiler, some keywords are parsed but ignored.
at present this is the case with const.


>
> SaSW, Willem
> --
> Disclaimer: I am in no way responsible for any of the statements
> made in the above text. For all I know I might be
> drugged or something..
> No I'm not paranoid. You all think I'm paranoid, don't you !
> #EOT


 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      10-28-2007
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.

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.
 
Reply With Quote
 
Charlie Gordon
Guest
Posts: n/a
 
      10-28-2007
"Martin Wells" <(E-Mail Removed)> a écrit dans le message de news:
(E-Mail Removed) m...
> Chqrlie:
>
>> Given your choice of field names, you shouldn't be too proud of your
>> coding
>> conventions, stylistic or otherwise.

>
>
> By "field names", do you mean the names I choose for functions and
> variables? What in particular is wrong with them? Please take one of
> them as an example and point out the (perceived) flaws to me.


No, I meant struct member names.

>> We do disagree on what you consider
>> 'stupid' as well. IMHO, if the need arises to cast a qualified pointer
>> to a
>> different type in an expression, needlessly unqualifying it at the same
>> time
>> *is* stupid.

>
> That's not what I mean. I meant the likes of:
>
> int i;
> double x;
>
> ...
>
> i = (int const)x;
>
> Writint "int const" instead of "int" has no merit.


I agree completely.

> (Let's assume that the cast was present to suppress a compiler warning).


Stupid compiler is this case.

> But even if we take a pointer type, we could have:
>
> int i;
>
> char *p = (char*)&i;
> char *p = (char const *)&i; /* This is stupid */


I agree as well.

>> const qualifying the parameters of a 3 line function is completely
>> useless.
>> Just like casting strcpy to (void) and casting the result of malloc().

>
> I disagree. The merit is that you'll get a compiler error if you try
> to alter something, which, you didn't intend to alter in the first
> place.
>
> The be-all and end-all of it though is that I do be consistent with
> const -- i.e. if I'm don't plan on changing it, then make it const.


Consistency has its merits. But do you also write:

int main(int const argc, char * const * const argv) { ... }

--
Chqrlie.


 
Reply With Quote
 
cr88192
Guest
Posts: n/a
 
      10-28-2007

"James Kuyper" <(E-Mail Removed)> wrote in message
news:vQ_Ui.3729$R%4.932@trnddc05...
> 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...).


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


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.


or such...



 
Reply With Quote
 
Charlie Gordon
Guest
Posts: n/a
 
      10-28-2007
"cr88192" <(E-Mail Removed)> a écrit dans le message de news:
134ba$47249c9e$ca8010a3$(E-Mail Removed)...
>
> "James Kuyper" <(E-Mail Removed)> wrote in message
> news:vQ_Ui.3729$R%4.932@trnddc05...
>> 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.

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

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

> or such...


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

--
Chqrlie.


 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      10-28-2007
"Charlie Gordon" <(E-Mail Removed)> writes:
> "Martin Wells" <(E-Mail Removed)> a écrit dans le message de news:
> (E-Mail Removed) m...

<snip>
>> The be-all and end-all of it though is that I do be consistent with
>> const -- i.e. if I'm don't plan on changing it, then make it const.

>
> Consistency has its merits. But do you also write:
>
> int main(int const argc, char * const * const argv) { ... }


<nit-pick size="micro">
A case could be made that such a definition is not legal. The
standard allows 'int main(int argc, char *argv[])' "or equivalent"
with a footnote that suggests the equivalence is to be exact
(e.g. type synonyms and 'char **' are OK but that is about it).

Since one can not even pass a 'char **' argument to a function that
expects a 'char *const *const' parameter it would be hard to argue
that your example is "equivalent".
</nit-pick>

--
Ben.
 
Reply With Quote
 
Martin Wells
Guest
Posts: n/a
 
      10-28-2007
Chqrlie:

> Consistency has its merits. But do you also write:
>
> int main(int const argc, char * const * const argv) { ... }



Yes, I'd make them const if I didn't plan on changing it.

Martin

 
Reply With Quote
 
Charlie Gordon
Guest
Posts: n/a
 
      10-28-2007
"Ben Bacarisse" <(E-Mail Removed)> a écrit dans le message de news:
(E-Mail Removed)...
> "Charlie Gordon" <(E-Mail Removed)> writes:
>> "Martin Wells" <(E-Mail Removed)> a écrit dans le message de news:
>> (E-Mail Removed) m...

> <snip>
>>> The be-all and end-all of it though is that I do be consistent with
>>> const -- i.e. if I'm don't plan on changing it, then make it const.

>>
>> Consistency has its merits. But do you also write:
>>
>> int main(int const argc, char * const * const argv) { ... }

>
> <nit-pick size="micro">
> A case could be made that such a definition is not legal. The
> standard allows 'int main(int argc, char *argv[])' "or equivalent"
> with a footnote that suggests the equivalence is to be exact
> (e.g. type synonyms and 'char **' are OK but that is about it).
>
> Since one can not even pass a 'char **' argument to a function that
> expects a 'char *const *const' parameter it would be hard to argue
> that your example is "equivalent".
> </nit-pick>


The prototype I wrote as a joke for main is compatible with the classic int
main(int argc, char *argv[]); in the sense that passing an int and a char *
array would be OK, but it is incompatible in terms of signatures.
Too bad, there is no way to hint that main does not modify the array (not
the strings it points to).

What about int main(int const argc, char ** const argv) { ... } ? This one
is compatible with the standard.
Is this how you define main ?

I can think of an even more verbose yet compatible one:

signed int main(register signed int const argc, register char ** const
restrict argv) { ... }

Great! it does not even fit on one line.

--
Chqrlie.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Writing single bits to a file riva Java 2 10-27-2007 08:11 PM
shifting bits, shift 32 bits on 32 bit int GGG C++ 10 07-06-2006 06:09 AM
8 bits/ch vs 16 bits/ch in PS Terry Digital Photography 5 01-21-2004 06:59 PM
8-Bits vs 12 or 16 bits/pixel; When does more than 8 bits count ? Al Dykes Digital Photography 3 12-29-2003 07:08 PM
win XP 32 bits on a 64 bits processor.. Abbyss Computer Support 3 11-13-2003 12:39 AM



Advertisments