Assuming x is an std::ostream object (you did not specify):
(1) and (2) are equivalent and both correct.
(3) is incorrect (and the compiler should tell you so I think), it is a pointer to the wrong location, simply a + 6 is correct for the first parameter.
(4) is correct, and is equivalent to a + 6 (as in the correction stated for (3) ).
In all cases the cast is entirely unnecessary. Since weird, unusual or over decorated syntax is never a good idea, I would simply stick with:
x.write( &a[6], 1 ) ;
or possibly
x.write( a + 6, 1 ) ;
but personally I wouldn't use the latter since it assumes an understanding of pointer arithmetic and its relationship to array indexing that a later code maintainer (or possibly even yourself) may not possess.
Of course in reality for a single character output I would use the far simpler ostream::put()function:
x.put( a[6] ) ;
which is far clearer surely?
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry for not mentioning the class: std::ofstream.
Might be why you considered the cast unneccesary; I hate it but it wont work otherwise,
probably because of the unsigned?
If the put() function exists there too, i'll check it out and use :)
It becomes obvious to me then than a[x] is a char, and i can get its address, whereas a is a pointer! Maybe i'd knew as much if i had read some reference about "strings" then...It is a bit complicated for me that the only 0-255 1-byte variable type is unsigned char! Not to mention how tiring it is to have to cast to print its numeric value.
Anyway...thank you very much for your answers!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>> Might be why you considered the cast unneccesary; I hate it but it wont work otherwise,
My mistake. A char may be implicitly cast to an unsigned char, but in C++ a char may not be implicitly cast to unsigned char. The fstream::put() function takes a char, so it will not need the cast. But why did you need to make it unsigned? If it is intended to be character data rather than small-unsigned-integer data, then plain char should normally be used.
>> Maybe i'd knew as much if i had read some reference about "strings"
>> It is a bit complicated for me that the only 0-255 1-byte variable type is unsigned char!
If you include <stdint.h> (An ISO C99 header), you can use uint8_t instead.
>> Not to mention how tiring it is to have to cast to print its numeric value.
First assumption should be that if you are casting, you are doing it wrong. Not always the case, but often. In this case the cast may have been necessary, but in a good OO design it is normally possible to wrap this in a class with an interface with appropriate types for your application so that the cast need only be done in one place and then hidden from the rest of the code. If you are littering your code with such casts, it might be time to consider your design.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
unsigned char a[100];
I want to write a[6] to file X. Which will suit me?
1. x.write((char)( &a[6] ),1);
2. x.write((char)( &(a[6]) ),1);
3. x.write((char)( &a+6 ),1);
4. x.write((char)( &a[0]+6 ),1);
Excuse me for the triviality but I couldn't find a satisfyingly clear solution out there...
How about neither!?
Assuming x is an std::ostream object (you did not specify):
(1) and (2) are equivalent and both correct.
(3) is incorrect (and the compiler should tell you so I think), it is a pointer to the wrong location, simply a + 6 is correct for the first parameter.
(4) is correct, and is equivalent to a + 6 (as in the correction stated for (3) ).
In all cases the cast is entirely unnecessary. Since weird, unusual or over decorated syntax is never a good idea, I would simply stick with:
x.write( &a[6], 1 ) ;
or possibly
x.write( a + 6, 1 ) ;
but personally I wouldn't use the latter since it assumes an understanding of pointer arithmetic and its relationship to array indexing that a later code maintainer (or possibly even yourself) may not possess.
Of course in reality for a single character output I would use the far simpler ostream::put()function:
x.put( a[6] ) ;
which is far clearer surely?
Clifford
Sorry for not mentioning the class: std::ofstream.
Might be why you considered the cast unneccesary; I hate it but it wont work otherwise,
probably because of the unsigned?
If the put() function exists there too, i'll check it out and use :)
It becomes obvious to me then than a[x] is a char, and i can get its address, whereas a is a pointer! Maybe i'd knew as much if i had read some reference about "strings" then...It is a bit complicated for me that the only 0-255 1-byte variable type is unsigned char! Not to mention how tiring it is to have to cast to print its numeric value.
Anyway...thank you very much for your answers!
>> Might be why you considered the cast unneccesary; I hate it but it wont work otherwise,
My mistake. A char may be implicitly cast to an unsigned char, but in C++ a char may not be implicitly cast to unsigned char. The fstream::put() function takes a char, so it will not need the cast. But why did you need to make it unsigned? If it is intended to be character data rather than small-unsigned-integer data, then plain char should normally be used.
>> Maybe i'd knew as much if i had read some reference about "strings"
Plenty of free resources:
http://www.cplusplus.com/doc/tutorial/
http://mindview.net/Books/TICPP/ThinkingInCPP2e.html
http://www.planetpdf.com/developer/article.asp?ContentID=6634 (PDF version of the above)
>> If the put() function exists there too, i'll check it out and use :)
Surely you did not consider using the class without reading the documentation!? http://www.cplusplus.com/reference/iostream/ofstream/
>> It is a bit complicated for me that the only 0-255 1-byte variable type is unsigned char!
If you include <stdint.h> (An ISO C99 header), you can use uint8_t instead.
>> Not to mention how tiring it is to have to cast to print its numeric value.
First assumption should be that if you are casting, you are doing it wrong. Not always the case, but often. In this case the cast may have been necessary, but in a good OO design it is normally possible to wrap this in a class with an interface with appropriate types for your application so that the cast need only be done in one place and then hidden from the rest of the code. If you are littering your code with such casts, it might be time to consider your design.
Clifford