comp.lang.c - 25 new messages in 11 topics - digest
comp.lang.c
http://groups.google.com/group/comp.lang.c?hl=en
Today's topics:
* operator overloading == - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/e872bdd42d831744?hl=en
* fixing compile warnings - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/41e53e9bb82de6ec?hl=en
* usage of size_t - 4 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/19e0ad96d01b9898?hl=en
* Stylistic questions on UNIX C coding. - 5 messages, 5 authors
http://groups.google.com/group/comp.lang.c/t/51d2b24a60d73f18?hl=en
* help: gcc compilation difference - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/c99c680c6b425b26?hl=en
* Reverse and Alphabetize in under 2kb - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/11babfbf4fe82c07?hl=en
* GET THE SIZE of struct in the PREPROCESSOR - 4 messages, 4 authors
http://groups.google.com/group/comp.lang.c/t/5868afedbbea3260?hl=en
* Mommy, Where Do Standards Come From? - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/2ee9317b397797a0?hl=en
* problem 1.13 The C programming language - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/e3b5a2688181479c?hl=en
* Best way/library to draw individual pixels on screen? (for fractals) - 1
messages, 1 author
http://groups.google.com/group/comp.lang.c/t/bf4e0288d8537985?hl=en
* C from Fortran Calls - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/ec59d7fd61d468f8?hl=en
==============================================================================
TOPIC: operator overloading ==
http://groups.google.com/group/comp.lang.c/t/e872bdd42d831744?hl=en
==============================================================================
== 1 of 2 ==
Date: Thurs, Mar 4 2010 8:16 am
From: A
Hi,
I am writing a "vector" class. I know about the STL but I prefer to
use this as I use this to create a "matrix" class later. I read that
using the inbuilt STL to create a matrix is not the best way to do it.
At the moment, the class "vec" looks like this.
template <class T>
class vec {
private:
int length;
T *v;
public:
vec();
explicit vec(int n);
vec(const T &a, int n);
vec(const T *a, int n);
vec(const vec &cpy);
vec & operator=(const vec &equate);
vec & operator=(const T &a);
inline T & operator[](const int i);
inline const T & operator[](const int i) const;
inline int size() const;
~vec();
};
Now, I want to overload the operator == in this way. It should accept
a value (type T) say "val", and check through all the entries of this
vector say "v1" and return another vector of type bool, which has
"false" where v1 != val and "true" where v1 == val. I managed to write
it this way...
member function:
vec<bool> operator==(const T &a) const;
the code definition is:
template <class T>
vec<bool> operator==(const T &a) const {
vec<bool> tmp(false,length);
for(int i=0; i<length; i++) {
if(v[i] == a) {
tmp[i] = true;
}
}
return tmp;
}
This works great, but I would like to return the reference instead of
the whole vector and would like to know how to do it. I am unable to
make use of the "this" pointer as I am returning a "local vector". I
would appreciate any help with this. thank you!
== 2 of 2 ==
Date: Thurs, Mar 4 2010 8:30 am
From: Keith Thompson
A <aragorn168b@gmail.com> writes:
> I am writing a "vector" class. I know about the STL but I prefer to
> use this as I use this to create a "matrix" class later. I read that
> using the inbuilt STL to create a matrix is not the best way to do it.
[...]
This is comp.lang.c. You want comp.lang.c++.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
==============================================================================
TOPIC: fixing compile warnings
http://groups.google.com/group/comp.lang.c/t/41e53e9bb82de6ec?hl=en
==============================================================================
== 1 of 2 ==
Date: Thurs, Mar 4 2010 8:14 am
From: Keith Thompson
Nick <3-nospam@temporary-address.org.uk> writes:
> Ian Collins <ian-news@hotmail.com> writes:
>> deadpickle wrote:
>>
>> {please don't top-post]
>>
>>> Thanks for the reply.
>>> Now I get a segfault. Is there a way to print the line causing the
>>> segfault (aka traceback in fortran)?
>>
>> No, you should run your programme under a debugger and look at the
>> stack trace when it faults.
>
> Although if you are still struggling to get to grips with the compiler
> and want to put off learning the debugger for a bit (and sooner or later
> you'll have to use it), you can find use the old stand-by of putting
> temporary printing statements in key places in the code and finding out
> how far it gets before it dies.
If you do that, you need to make sure that each message actually
appears before the program crashes. Given:
printf("One\n");
/* do something innocuous */
printf("Two\n");
/* do something that segfaults */
printf("Three\n");
it's entirely possible that the line "One" will never appear, because
it was buffered rather than printed directly to your output device,
and the segfault zapped the buffer before it could be flushed.
You can either print your messages to stderr, or call fflush(stdout)
after each output operation, or call
setvbuf(stdout, NULL, _IONBF, 0);
to turn off buffering for stdout.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
== 2 of 2 ==
Date: Thurs, Mar 4 2010 11:13 am
From: Nick <3-nospam@temporary-address.org.uk>
Keith Thompson <kst-u@mib.org> writes:
> Nick <3-nospam@temporary-address.org.uk> writes:
>> Ian Collins <ian-news@hotmail.com> writes:
>>> deadpickle wrote:
>>>
>>> {please don't top-post]
>>>
>>>> Thanks for the reply.
>>>> Now I get a segfault. Is there a way to print the line causing the
>>>> segfault (aka traceback in fortran)?
>>>
>>> No, you should run your programme under a debugger and look at the
>>> stack trace when it faults.
>>
>> Although if you are still struggling to get to grips with the compiler
>> and want to put off learning the debugger for a bit (and sooner or later
>> you'll have to use it), you can find use the old stand-by of putting
>> temporary printing statements in key places in the code and finding out
>> how far it gets before it dies.
>
> If you do that, you need to make sure that each message actually
> appears before the program crashes. Given:
>
> printf("One\n");
> /* do something innocuous */
> printf("Two\n");
> /* do something that segfaults */
> printf("Three\n");
>
> it's entirely possible that the line "One" will never appear, because
> it was buffered rather than printed directly to your output device,
> and the segfault zapped the buffer before it could be flushed.
>
> You can either print your messages to stderr, or call fflush(stdout)
> after each output operation, or call
> setvbuf(stdout, NULL, _IONBF, 0);
> to turn off buffering for stdout.
Good point, thanks.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk
==============================================================================
TOPIC: usage of size_t
http://groups.google.com/group/comp.lang.c/t/19e0ad96d01b9898?hl=en
==============================================================================
== 1 of 4 ==
Date: Thurs, Mar 4 2010 8:17 am
From: Tim Rentsch
Ian Collins <ian-news@hotmail.com> writes:
> Tim Rentsch wrote:
>>
>> Certainly that seems to be the expectation, but I don't
>> think it's required or necessarily guaranteed. I'm
>> pretty sure a conforming implementation could have
>> SIZE_MAX == 65535 but still allow
>>
>> char too_big[ 100000 ];
>>
>> for example. And that's only one way of getting a buffer of
>> more than SIZE_MAX bytes.
>
> No, it couldn't. That would break sizeof().
Please see the explanation in my other most recent
response here (to Seebs's message).
== 2 of 4 ==
Date: Thurs, Mar 4 2010 8:35 am
From: Tim Rentsch
Keith Thompson <kst-u@mib.org> writes:
> Tim Rentsch <txr@x-alumni2.alumni.caltech.edu> writes:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>> On Feb 22, 5:23 pm, santosh <santosh....@gmail.com> wrote:
>>>> Right, but size_t is maximally portable (whatever that means) while
>>>> unsigned long is not.
>>>>
>>> size_t is the only type that is guaranteed to be able to index any
>>> array. [snip]
>>
>> Oh? Which paragraphs in the Standard provide that guarantee?
>
> size_t is the type yielded by the sizeof operator. The sizeof
> operator may be applied to any type or expression, and yields the
> size in bytes of the type or expression. There is no permission
> for this to fail.
It has to work only for programs with defined behavior.
> Since the number of elements of an array cannot
> exceed its size in bytes, it follows that the number of elements
> can be represented as a size_t.
>
> Finding the relevant paragraphs in the Standard is left as an
> exercise. (You'll likely disagree with some of my reasoning anyway.)
Consider an implementation with SIZE_MAX == 65535, and supplying
an array definition
char too_big[ 100000 ] = {0};
to that implementation. This array definition is legal syntax
and contains no constraint violations -- right? Hence it may be
accepted, either because it's legal or because the implementation
has chosen to define an extension for the undefined behavior. If
it's undefined behavior we're already home free, so let's suppose
for a moment it isn't (ie assume temporarily the declaration is
legal). In that case 'sizeof too_big' would yield a value that
is outside the range of what size_t can represent, which is an
exceptional condition, which is undefined behavior. Hence the
implementation can allow such a declaration, yet size_t cannot
hold a value large enough to index it.
If you disagree with any of the above, would you be so kind
as to supply appropriate section citations or references?
Unless a program contains a syntax error or constrain violation,
it may be accepted without complaint by a conforming implmentation.
Since any program with an array of 100000 bytes is never strictly
conforming, no required diagnostics plus undefined behavior
means the implementation is free to do whatever it wants.
== 3 of 4 ==
Date: Thurs, Mar 4 2010 8:36 am
From: Tim Rentsch
Ian Collins <ian-news@hotmail.com> writes:
> Tim Rentsch wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>>> On Feb 22, 5:23 pm, santosh <santosh....@gmail.com> wrote:
>>>> Right, but size_t is maximally portable (whatever that means) while
>>>> unsigned long is not.
>>>>
>>> size_t is the only type that is guaranteed to be able to index any
>>> array. [snip]
>>
>> Oh? Which paragraphs in the Standard provide that guarantee?
>
> The result type of the sizeof() operator is size_t, so the range of
> size_t has to be large enough to index any array.
I've responded on this in reply to Keith Thompson's followup.
== 4 of 4 ==
Date: Thurs, Mar 4 2010 9:38 am
From: Keith Thompson
Tim Rentsch <txr@x-alumni2.alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Tim Rentsch <txr@x-alumni2.alumni.caltech.edu> writes:
>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>>> On Feb 22, 5:23 pm, santosh <santosh....@gmail.com> wrote:
>>>>> Right, but size_t is maximally portable (whatever that means) while
>>>>> unsigned long is not.
>>>>>
>>>> size_t is the only type that is guaranteed to be able to index any
>>>> array. [snip]
>>>
>>> Oh? Which paragraphs in the Standard provide that guarantee?
>>
>> size_t is the type yielded by the sizeof operator. The sizeof
>> operator may be applied to any type or expression, and yields the
>> size in bytes of the type or expression. There is no permission
>> for this to fail.
>
> It has to work only for programs with defined behavior.
>
>> Since the number of elements of an array cannot
>> exceed its size in bytes, it follows that the number of elements
>> can be represented as a size_t.
>>
>> Finding the relevant paragraphs in the Standard is left as an
>> exercise. (You'll likely disagree with some of my reasoning anyway.)
>
> Consider an implementation with SIZE_MAX == 65535, and supplying
> an array definition
>
> char too_big[ 100000 ] = {0};
>
> to that implementation. This array definition is legal syntax
> and contains no constraint violations -- right? Hence it may be
> accepted, either because it's legal or because the implementation
> has chosen to define an extension for the undefined behavior. If
> it's undefined behavior we're already home free, so let's suppose
> for a moment it isn't (ie assume temporarily the declaration is
> legal). In that case 'sizeof too_big' would yield a value that
> is outside the range of what size_t can represent, which is an
> exceptional condition, which is undefined behavior. Hence the
> implementation can allow such a declaration, yet size_t cannot
> hold a value large enough to index it.
>
> If you disagree with any of the above, would you be so kind
> as to supply appropriate section citations or references?
I think you're right. If the compiler accepts the above declaration
then the mathematical result of ``sizeof too_big'', 100000, cannot be
represented in the appropriate type, size_t. sizeof is just another
operator; its behavior on overflow should be the same as for any other
operator.
But wait, I just realized something very odd. size_t is an unsigned
type. C99 6.2.5p9 says:
A computation involving unsigned operands can never overflow,
because a result that cannot be represented by the resulting
unsigned integer type is reduced modulo the number that is one
greater than the largest value that can be represented by the
resulting type.
So one could argue that, given SIZE_MAX==65535, ``sizeof too_big''
must be 34464.
(On the other hand, ``sizeof too_big'' doesn't have unsigned
*operands*; its the expression as a whole whose result is unsigned.)
I suspect the authors of the standard weren't thinking about "sizeof"
when they wrote 6.2.5p9.
> Unless a program contains a syntax error or constrain violation,
> it may be accepted without complaint by a conforming implmentation.
> Since any program with an array of 100000 bytes is never strictly
> conforming, no required diagnostics plus undefined behavior
> means the implementation is free to do whatever it wants.
In practice, I think most or all implementations sidestep the issue
by disallowing objects bigger than SIZE_MAX bytes -- or, to put it
another way, by making size_t big enough to represent the size of
any supported object. For example, given:
#include <stddef.h>
char huge[(unsigned long long)(size_t)-1];
gcc says:
c.c:2: error: size of array 'huge' is too large
But as you've argued, it doesn't *have* to reject it.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
==============================================================================
TOPIC: Stylistic questions on UNIX C coding.
http://groups.google.com/group/comp.lang.c/t/51d2b24a60d73f18?hl=en
==============================================================================
== 1 of 5 ==
Date: Thurs, Mar 4 2010 8:20 am
From: Keith Thompson
Vladimir Jovic <vladaspams@gmail.com> writes:
> Keith Thompson wrote:
>> Vladimir Jovic <vladaspams@gmail.com> writes:
>>> Scott Lurndal wrote:
>>>> I personally place the condition operator at the front, as
>>>> William does, but nested.
>>>>
>>>> if ((pointer1 != NULL)
>>>> && (pointer1->field7 == 0x152)) {
>>>> return;
>>>> }
>>> if ( ( pointer1 =! NULL )
>>> && ( pointer1->field7 = 0x152 ) ) {
>>> return;
>>> }
>>>
>>> ops && ops
>>
>> if ( pointer1 != NULL &&
>> pointer1->field7 == 0x152 )
>> {
>> return;
>> }
>>
[...]
>
> Yes, you missed the point. I prefer this way :
>
> if ( NULL != pointer1 &&
> 0x152 == pointer1->field7 )
> {
> return;
> }
>
> Can save you some debugging time :)
Oh, I see. I noticed the use of "=!" for "!=" and "=" for "==", but
assumed there were unintentional typos.
``pointer1 =! NULL'', of course, parses as ``pointer1 = !NULL''.
``!NULL'' evaluates to 1, and assigning an int value (other than a
null pointer constant) to a pointer object requires a diagnostic.
But yes, I'm familiar with the convention of putting the constant
expression on the left hand side of a comparison operator, and with
all the arguments in favor of it. Personally, I find it ugly.
No offense.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
== 2 of 5 ==
Date: Thurs, Mar 4 2010 8:27 am
From: Casper H.S. Dik
Keith Thompson <kst-u@mib.org> writes:
>``pointer1 =! NULL'', of course, parses as ``pointer1 = !NULL''.
>``!NULL'' evaluates to 1, and assigning an int value (other than a
>null pointer constant) to a pointer object requires a diagnostic.
And for other types the compiler or lint will also create a
diagnostic.
(4) warning: assignment operator "=" found where "==" was expected
(4) warning: constant operand to op: "!"
>But yes, I'm familiar with the convention of putting the constant
>expression on the left hand side of a comparison operator, and with
>all the arguments in favor of it. Personally, I find it ugly.
>No offense.
Same here.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
== 3 of 5 ==
Date: Thurs, Mar 4 2010 8:29 am
From: Rainer Weikusat
John Gordon <gordon@panix.com> writes:
> In <oct467-nu6.ln1@news.eternal-september.org> Richard <rgrdev_@gmail.com> writes:
>> When discussing vars in computing it is normal to discuss the variables
>> b name.
>
>> You dont say "if pi is larger than p".You say "if p is larger than
>> pi". You're style is nothing more than fancy for fancy's sake IMO.
>
> No, it does actually do something: it will throw a compile error if you
> mistype == as =.
>
> To demonstrate, imagine that you intended to type this:
>
> if (x == 7)
>
> But you mistakenly typed this:
>
> if (x = 7)
>
> This is legal code but will not behave in the way you intended.
It is a bad idea to try to solve social problems with technical
means. The problem behind this is that = in C is a so-called 'false
cognate' for people who are intimately familiar with mathematics, that
is, a term in a foreign language which 'looks' very similar to a
loosely related term in one's mother tongue, but with a (subtly)
different meaning. This means that such people will likely confuse =
and == in C intuitively and have a hard time spotting such an error
since the text 'looks right' according to the set of conventions they
are so used to that they no longer actively think about them.
But this really only means that average people well-versed in
mathematics shouldn't attempt to code in C because they will likely
make basic errors other people wouldn't.
== 4 of 5 ==
Date: Thurs, Mar 4 2010 9:28 am
From: Seebs
On 2010-03-04, John Gordon <gordon@panix.com> wrote:
> No, it does actually do something: it will throw a compile error if you
> mistype == as =.
But gcc gives a warning for it, anyway. And "x == 7" is much more readable
than "7 == x".
At least, for English speakers it is. I don't know; maybe there are languages
in which saying "if x is equal to y" implies that x is the constant and y
is the variable.
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
== 5 of 5 ==
Date: Thurs, Mar 4 2010 9:16 am
From: Richard
John Gordon <gordon@panix.com> writes:
> In <oct467-nu6.ln1@news.eternal-september.org> Richard <rgrdev_@gmail.com> writes:
>
>> When discussing vars in computing it is normal to discuss the variables
>> b name.
>
>> You dont say "if pi is larger than p".You say "if p is larger than
>> pi". You're style is nothing more than fancy for fancy's sake IMO.
>
> No, it does actually do something: it will throw a compile error if you
> mistype == as =.
I know. I program C.
Its a silly little style. Sorry.
The same "error" can happen if "p=q()".
The ugliness and "non naturalness" as well as the inconsistency it
brings in outweigh any advantage.
==============================================================================
TOPIC: help: gcc compilation difference
http://groups.google.com/group/comp.lang.c/t/c99c680c6b425b26?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Mar 4 2010 9:02 am
From: Tim Rentsch
Peter Nilsson <airia@acay.com.au> writes:
> Tim Rentsch <t...@x-alumni2.alumni.caltech.edu> wrote:
>> Ben Bacarisse <ben.use...@bsb.me.uk> writes:
>> > 6.2.6.1 p5 which defines and discusses trap representations
>> > states that:
>> >
>> > Certain object representations need not represent a value
>> > of the object type. If the stored value of an object has
>> > such a representation and is read by an lvalue expression
>> > that does not have character type, the behavior is
>> > undefined. If such a representation is produced by a side
>> > effect that modifies all or any part of the object by an
>> > lvalue expression that does not have character type, the
>> > behavior is undefined. Such a representation is called a
>> > trap representation.
>> >
>> > I read that as forbidding UB when a trap representation is
>> > accessed via an lvalue expression of type char which is the
>> > case here, is it not?
>>
>> I believe that's a misreading.
>
> If it misreads the intent, it's because the intent is not
> clear. ;)
I would not presume to argue that point. :)
>> What the passage says is that if the access type is a non-
>> character type then the behavior is undefined. It does not say
>> that if the access type is a character type then the behavior
>> is defined. Access through a character type interprets the
>> stored value (ie, the representation) according to the type
>> used to do the read; if the access type is (char) or (signed
>> char) and the representation read is a trap representation for
>> that type, it's still undefined behavior, because
>
> To put it another way, the last time this discussion came up,
> the majority view was that trap representations are possible for
> all types except unsigned char (and unsigned bit-fields).
Of course you mean all scalar types -- struct's and union's are
exempt.
> Access to trap representations for non character types is
> explicitly undefined. Access to trap representations for signed
> character types is _implicitly_ undefined due to a lack of
> specification!
Right.
> Note that "[It is implementation-defined] whether the value
> with sign bit 1 and all value bits zero (for the first two),
> or with sign bit and all value bits 1 (for ones' complement),
> is a trap representation or a normal value." does not
> exclude application to signed character types.
>
> Thus, signed character types can have trap representations.
Yes, even in implementations that use 2's complement.
> Whether they can be accessed is a separate issue.
>
> The question remains, why does 6.2.6.1p5 _explicitly_ exclude
> character types?
Probably because in most implementations the character
types don't have trap representations, and therefore they
shouldn't be included in a blanket statement of undefined
behavior. Also character types (notably "plain" char) are
typically used to get around representation issues; the
combination of how must implementations are and what was
(and is?) common usage probably accounts for the exception
being worded as it is. (Of course I'm only speculating...)
>> there's no (Standard-)defined way to
>> produce a value from a trap representation.
>
> What's the standard way to produce a value from a non trap
> representation for an integer type? Why wouldn't that apply?
This mapping is supplied by the required documentation giving the
implementation-defined information for representation of types
(plus the relevant sections of 6.2.6). That documentation
also defines which representations are trap representations,
ie, which representations correspond to "no value".
==============================================================================
TOPIC: Reverse and Alphabetize in under 2kb
http://groups.google.com/group/comp.lang.c/t/11babfbf4fe82c07?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Mar 4 2010 9:04 am
From: Willem
Peter Nilsson wrote:
) Willem <wil...@snail.stack.nl> wrote:
)<snip>
)> As it turns out, it can be done quite easily in 1Kb, though.
)
) Indeed.
)
) % type obfuscate.c
<snip 1000-byte very obfuscated code>
With reasonable variable and function names, I get 666 bytes:
(Note that the original has tabs for indent, which I substituted
for spaces for usenet purposes.)
#include <stdio.h>
#include <string.h>
#include <ctype.h>
void reverse(char *str)
{
if(!*str) return;
size_t len = strcspn(str," \t\n");
if(str[len]) {
reverse(str+len+1);
putchar(str[len]);
}
fwrite(str, len, 1, stdout);
}
void sortwords(char *str)
{
while(*str) {
size_t i, len = strcspn(str," \t\n");
int c;
for(c = 'a'; c <= 'z'; c++) {
for(i = 0; i < len; i++) {
if(tolower(str[i]) == c) {
putchar(str[i]);
}
}
}
str += len;
if(*str) {
putchar(*str++);
}
}
}
int main()
{
char str[1024];
if (fgets(str, sizeof str, stdin)) {
reverse(str);
putchar('\n');
sortwords(str);
putchar('\n');
}
return 0;
}
Which just goes to show that algorithmic improvements are an
order of magnitude more important than peephole 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
==============================================================================
TOPIC: GET THE SIZE of struct in the PREPROCESSOR
http://groups.google.com/group/comp.lang.c/t/5868afedbbea3260?hl=en
==============================================================================
== 1 of 4 ==
Date: Thurs, Mar 4 2010 9:12 am
From: requinham
Hello,
i have a structure in my program and i want generate a compile error
when the size of structure is not pow of two.
my problem is that i don't found the way to get the size of structure
in preprocessor mode and it's necessary to generate a COMPILE ERROR
when the size of my struct is not pow of 2 :(
thank you
== 2 of 4 ==
Date: Thurs, Mar 4 2010 9:48 am
From: ImpalerCore
On Mar 4, 12:12 pm, requinham <requin...@gmail.com> wrote:
> Hello,
>
> i have a structure in my program and i want generate a compile error
> when the size of structure is not pow of two.
>
> my problem is that i don't found the way to get the size of structure
> in preprocessor mode and it's necessary to generate a COMPILE ERROR
> when the size of my struct is not pow of 2 :(
>
> thank you
GLib has a G_STATIC_ASSERT that may do what you want.
http://library.gnome.org/devel/glib/stable/glib-Miscellaneous-Macros.html#G-STATIC-ASSERT:CAPS
== 3 of 4 ==
Date: Thurs, Mar 4 2010 10:09 am
From: Gene
On Mar 4, 12:12 pm, requinham <requin...@gmail.com> wrote:
> Hello,
>
> i have a structure in my program and i want generate a compile error
> when the size of structure is not pow of two.
>
> my problem is that i don't found the way to get the size of structure
> in preprocessor mode and it's necessary to generate a COMPILE ERROR
> when the size of my struct is not pow of 2 :(
>
> thank you
The preprocessor works on the program as text only. It doesn't have
any information about structure sizes. The kind of check you are
after is typically checked in a configure script by compiling,
running, and checking the return value or output of a small program in
preparation for a build. Something like
#include "mystruct.h"
int main(void)
{
size_t test_size = 1;
while (test_size != 0) {
if (test_size == sizeof(MYSTRUCT)) {
return 0;
test_size <<= 1;
}
return 1;
}
== 4 of 4 ==
Date: Thurs, Mar 4 2010 10:37 am
From: Eric Sosman
On 3/4/2010 12:12 PM, requinham wrote:
> Hello,
>
> i have a structure in my program and i want generate a compile error
> when the size of structure is not pow of two.
>
> my problem is that i don't found the way to get the size of structure
> in preprocessor mode and it's necessary to generate a COMPILE ERROR
> when the size of my struct is not pow of 2 :(
The preprocessor cannot get the size of anything, not
even of a char, because the preprocessor operates at a time
before things like `char' have acquired any meaning: They're
just tokens ("preprocessing tokens," actually), and their
eventual effect of declaring types that have sizes is still
in the future.
However, you can cause compilation errors at a later
stage. One way is to declare an array type whose dimension
is invalid if the condition you're interested in doesn't hold:
char foo[ (sizeof(struct s) & (sizeof(struct s)-1)) == 0 ];
If the condition holds this is `char foo[1];' and valid; if the
condition doesn't hold it's `char foo[0];' which is invalid and
should generate a diagnostic. (Unfortunately, some compilers
fail to diagnose zero-dimension arrays; to get diagnostics even
from them you could use `char foo[... == 0 ? 1 : -1];' instead.)
The diagnostic will probably say something about the invalid
array dimension, rather than something helpful about the fact
that sizeof(struct s) isn't a power of two. One thing you can
do about that is use a comment:
/* If the compiler objects to the following declaration,
* the problem is that sizeof(struct s) should be a power
* of two but is not.
*/
char foo[...];
The person who investigates the funny-looking compiler complaint
will presumably arrive at the offending declaration of foo, and
will then see the comment that explains what's *really* wrong.
You don't have to use an array dimension as the thing the
compiler will object to. For example, you could declare a struct
having a bit-field whose width is given by the test expression
(note that `:0' *is* valid as a bit-field width, so make sure
the evaluation produces a negative number on failure).
--
Eric Sosman
esosman@ieee-dot-org.invalid
==============================================================================
TOPIC: Mommy, Where Do Standards Come From?
http://groups.google.com/group/comp.lang.c/t/2ee9317b397797a0?hl=en
==============================================================================
== 1 of 2 ==
Date: Thurs, Mar 4 2010 9:28 am
From: Seebs
On 2010-03-04, Ersek, Laszlo <lacos@ludens.elte.hu> wrote:
> http://pl.atyp.us/wordpress/?p=2719
>
> Please share your thoughts, if you care.
I posted a comment on the blog (still awaiting moderation):
Uh, no.
I was on the ANSI/ISO C committee for about ten years. I was there
as an individual. The closest I ever had to any kind of employer
support was that I had an employer that would only charge half of
the time I spent at meetings to my vacation.
I believe we had at least one other person who went to meetings
because he was personally interested in the language, although my
memoryâs gotten foggy with the years.
But you certainly can, as just any old individual, pay your dues
and show up for meetings. Past that, it's a question of whether
people think you make good arguments.
The C committee may be atypical in that members of the ANSI committee
are part of debates on the ISO committee meetings, but it's certainly
a real-world case in which you can be any old guy off the street
and be a member if you want to.
I agree that his criticism would carry real weight if you couldn't just show
up for meetings if you want to -- so maybe it's a good criticism of some
other standards. I'm pretty sure C++ was the same way C was, though.
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
== 2 of 2 ==
Date: Thurs, Mar 4 2010 11:46 am
From: Kelsey Bjarnason
On Thu, 04 Mar 2010 17:04:02 +0100, Ersek, Laszlo wrote:
> http://pl.atyp.us/wordpress/?p=2719
>
> Please share your thoughts, if you care.
Okay, it's a pretty url, with a cutesy animal name in it.
==============================================================================
TOPIC: problem 1.13 The C programming language
http://groups.google.com/group/comp.lang.c/t/e3b5a2688181479c?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Mar 4 2010 9:34 am
From: joag
I follow your instruction but the part for changing 0 to i in line 55 and
the code is doing practically the same, I tested it against this text
(#### is just for delimiting the text):
###### In your while loop, nword is indexed by the number of characters in
the current completed word (line 26). Do you ever expect to have a
word with 15000 characters in it (line 21)? ######
1 1 9 3 8 6 2 2 0 1 2
and as you see I never print position zero but instead 1 2 and so on,
position one (one repetition) is printed well, position two (9
repetitions) is printed well, position three (3 repetitions) so it is
printed well too, but since there something goes wrong, if you see there
is eight asterisks but they are not aligned.
9 | * * * * * * * * * *
8 | * * * * * * *
7 | * * * *
6 | * * *
5 | * * *
4 | * * *
3 | * *
2 | * *
1 | *
|________________________
1 2 3 4 5 6 7 8 9 10 11
==============================================================================
TOPIC: Best way/library to draw individual pixels on screen? (for fractals)
http://groups.google.com/group/comp.lang.c/t/bf4e0288d8537985?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Mar 4 2010 10:18 am
From: Wolfgang Draxinger
Wolfnoliir wrote:
> I am using GL_RGB format because it seems more natural. Should I try
> GL_BGR instead? What difference would it make?
It might look more intuitive, but believe it or not, most graphics hardware
store pixels BGR order, oftenly padded to 32 bits with zero-bits prior to
the blue bits.
The history behind this is, that pixels are traditionally stored as unsigned
32 bit MSB integers by graphics hardware, where one could e.g. write
0x00ff0000 for blue, 0x0000ff00 for green and 0x000000ff for red. By storing
as such whole pixels could be manipulated by single instructions, instead of
performing the same instruction 3 times for every pixel. Now if you look at
the memory layout of these in MSB format the rest is ovbious.
> I am also using GL_FLOAT. Would I gain performance by changing it to
> GL_UNSIGNED_BYTE?
If using glDrawPixels: Yes. The on screen framebuffer most likely uses an
integer format, so floats require conversion first. Now the way glDrawPixels
works, this conversion must be done by the CPU beforehand. If you go the way
over a floating point texture, then conversion is done by the GPU's
rasterizer pipeline.
Wolfgang
F'up 2 c.g.a.opengl
==============================================================================
TOPIC: C from Fortran Calls
http://groups.google.com/group/comp.lang.c/t/ec59d7fd61d468f8?hl=en
==============================================================================
== 1 of 2 ==
Date: Thurs, Mar 4 2010 11:33 am
From: deadpickle
I'm trying to mix my programming languages. I know Fortran very well
but C I'm not so knowledgable. When I call a C subroutine from Fortran
I use the scheme:
passer = TRIM(output_path)//CHAR(0)
PRINT *, "FORTRAN",passer,a
CALL create_shp(passer, a)
where:
INTEGER :: a
CHARACTER(200) :: passer
In C the subroutine is set as:
void create_shp_(char *output_path, int *a)
{
printf("C %s %d\n",output_path,a);
}
When I run the program I get an output:
FORTRAN /home/thor/output/ 35
C /home/thor/output/ -1074936500
The CHAR match but the int dont. Any Ideas?
== 2 of 2 ==
Date: Thurs, Mar 4 2010 11:45 am
From: Ian Collins
deadpickle wrote:
> I'm trying to mix my programming languages. I know Fortran very well
> but C I'm not so knowledgable. When I call a C subroutine from Fortran
> I use the scheme:
>
> passer = TRIM(output_path)//CHAR(0)
> PRINT *, "FORTRAN",passer,a
> CALL create_shp(passer, a)
>
> where:
> INTEGER :: a
> CHARACTER(200) :: passer
>
> In C the subroutine is set as:
> void create_shp_(char *output_path, int *a)
> {
> printf("C %s %d\n",output_path,a);
> }
>
> When I run the program I get an output:
> FORTRAN /home/thor/output/ 35
> C /home/thor/output/ -1074936500
>
> The CHAR match but the int dont. Any Ideas?
Without knowing the Fortran syntax, it looks like you are declaring 'a'
as an int on the Fortran side and as an int* (pointer to int) in the C
function. I'm guessing CHARACTER(200) maps to an array of char, which
will decay to a pointer to char which explains why that parameter works.
--
Ian Collins
==============================================================================
You received this message because you are subscribed to the Google Groups "comp.lang.c"
group.
To post to this group, visit http://groups.google.com/group/comp.lang.c?hl=en
To unsubscribe from this group, send email to comp.lang.c+unsubscribe@googlegroups.com
To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c/subscribe?hl=en
To report abuse, send email explaining the problem to abuse@googlegroups.com
==============================================================================
Google Groups: http://groups.google.com/?hl=en
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home