On Sat Oct 01, 2005 at 18:23:40 +1000, O Plameras wrote:
Matthew Hannigan wrote:
On Fri, Sep 30, 2005 at 10:09:40AM +1000, O Plameras wrote:
and as C is closely bound
to hardware architecture you must have said something about these data
Actually, C is not necessarily that closely
Benno wrote:
On Sat Oct 01, 2005 at 18:23:40 +1000, O Plameras wrote:
Matthew Hannigan wrote:
On Fri, Sep 30, 2005 at 10:09:40AM +1000, O Plameras wrote:
and as C is closely bound
to hardware architecture you must have said something about these data
#include stdio.h
struct verify {
char initials[2];
int birthdate;
};
int main(void)
{
struct verify holes;
printf (%d\n, sizeof(holes.initials[0]));
printf (%d\n, sizeof(holes.initials));
printf (%d\n, sizeof(holes.birthdate));
printf (%d\n, sizeof(holes));
return 0;
}
Given that the word-byte
On Tue Oct 04, 2005 at 10:15:49 +1000, O Plameras wrote:
Benno wrote:
On Sat Oct 01, 2005 at 18:23:40 +1000, O Plameras wrote:
snippety
What do you mean ? Can you illustrate with C codes ? Do you mean that a
struct
are not allocated contiguous memory ? Do you mean a struct components are
On Mon Oct 03, 2005 at 19:44:44 -0500, [EMAIL PROTECTED] wrote:
#include stdio.h
struct verify {
char initials[2];
int birthdate;
};
int main(void)
{
struct verify holes;
printf (%d\n, sizeof(holes.initials[0]));
printf (%d\n, sizeof(holes.initials));
printf (%d\n, sizeof(holes.birthdate));
[EMAIL PROTECTED] wrote:
#include stdio.h
struct verify {
char initials[2];
int birthdate;
};
int main(void)
{
struct verify holes;
printf (%d\n, sizeof(holes.initials[0]));
printf (%d\n, sizeof(holes.initials));
printf (%d\n, sizeof(holes.birthdate));
printf (%d\n, sizeof(holes));
return 0;
On Mon, Oct 03, 2005 at 07:44:44PM -0500, [EMAIL PROTECTED] wrote:
k, I am a newb, so someone plz quickly explain to me why the variable
'initial'
takes 2 bytes, 'birthdate' takes 4 bytes but the struct which is 2+4 = 6
bytes
takes 8 bytes?
http://www.eskimo.com/~scs/C-faq/q2.13.html
--
On Tue, Oct 04, 2005 at 12:28:51PM +1000, Matthew Hannigan wrote:
http://www.eskimo.com/~scs/C-faq/q2.13.html
A better link, to the whole faq is
http://www.faqs.org/faqs/C-faq/faq/
What's remarkable is the amount of space in the faq
devoted to exactly the issues mentioned in this
Thanks.
Mike
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Matthew Hannigan wrote:
On Fri, Sep 30, 2005 at 10:09:40AM +1000, O Plameras wrote:
and as C is closely bound
to hardware architecture you must have said something about these data
Actually, C is not necessarily that closely bound to hardware architecture.
The the following
On Sunday 02 October 2005 10:00, [EMAIL PROTECTED] wrote:
On Fri, Sep 30, 2005 at 10:09:40AM +1000, O Plameras wrote:
and as C is closely bound
to hardware architecture you must have said something about these data
Actually, C is not necessarily that closely bound to
James wrote:
On Sunday 02 October 2005 10:00, [EMAIL PROTECTED] wrote:
Likewise the POSIX C does not mandate struture
alignment.
The POSIX C stuff has nothing to do here with the issue if you examine
the post.
Read my post !
The statement was that data type is closely bound
On 9/29/05, Angus Lees [EMAIL PROTECTED] wrote:
At Tue, 27 Sep 2005 12:00:09 +1000, Bruce Badger wrote:
In fact, the very best of the JITing VMs can get performance that
exceeds that attainable by static compilation - because there is
more information available at run time to base the
At Tue, 27 Sep 2005 12:00:09 +1000, Bruce Badger wrote:
On 9/27/05, Erik de Castro Lopo [EMAIL PROTECTED] wrote:
There are large classes of problems where running speed is an
important issue. Static typing does make for faster run times
and in cases where that moves your program from being
QuantumG wrote:
Erik de Castro Lopo wrote:
Thats why I'm so keen on O'Caml. It offers even more static analysis
than C and C++. Its significantly more difficult to write bugs into
an O'Caml program than a C or C++ program.
Sounds like the antithesis of Objective-C and other dynamically
On 9/27/05, Erik de Castro Lopo [EMAIL PROTECTED] wrote:
The problem with dynamic typing is that it postones testing for an
important class of errors (type errors) until run time.
Nah. In fact the oposite is true. Static typing is just another form
of premature optimisation!
I make extensive
On 9/27/05, Erik de Castro Lopo [EMAIL PROTECTED] wrote:
There are large classes of problems where running speed is an
important issue. Static typing does make for faster run times
and in cases where that moves your program from being too
slow to being fast enough, that is not a premature
However, other dynamically typed languages like Python, php and to a
lesser extent Perl do not have anywhere near as sane a system. I
suspect that the Smalltalk equivalent of the following Python code
might actually do the right thing:
a = [ 1, help ]
b = a + 10
but Python squeals like
[EMAIL PROTECTED] wrote:
However, other dynamically typed languages like Python, php and to a
lesser extent Perl do not have anywhere near as sane a system. I
suspect that the Smalltalk equivalent of the following Python code
might actually do the right thing:
a = [ 1, help ]
19 matches
Mail list logo
