An enigma

So, /prog/, a C question: I have int somevariable [10][10]; How do I declare a pointer to the first row of this array?

0/10

int * firstRow = &somevariable[0];

More generally:
int * row = &somevariable[10*i]; where i is the row number you want

Is there any reason why you cant just do
int * firstRow = somevariable;   ?

int * firstRow = &somevariable[0];
Why not
int            *
       firstRow =
      &somevariable[
                  0
                 ]
;
then faggot.

>>6
lrn2makereadablecode

int
*//*
firstRow
=//=//somevariable[5*1/0.25]
&somevariable/*
some&variable
somevariable&
*/
[
0
]//
;

>>5
you can

HAXUS THE GREAT

>>7
nice!

>>9
A fatal error occured!
Please post less often!

int *row = somevariable[0];

He asks a pointer to the first row. That means something which points to a row. Expressions of type int * point to an integer int. What OP literally asks for is this:


int (*rows)[10] = somevariable;

Of course it wouldn't behave, in most cases, any differently than `somevariable', in fact, `somevariable' becomes a pointer of such type in most expressions.

>>12
+1, proper formatting of *.

>>13
somevariable IS a pointer. Arrays in c are just synatic sugar for pointers and pointer arithmetic

>>15
Syntactic sugar implies indifference to semantics. Try this,


int (*row)[10];
int somevariable[10][10];

printf("%u != %u\n", sizeof row, sizeof somevariable);

As you see, semantically, the two expressions, `sizeof row' and `sizeof somevariable' are different. That means arrays are not syntactic sugar for pointers.

>>16
P.S. forgot to cast the sizeof expressions to (unsigned). Either that, or use %zu. (and there's always the argument that %lu and (unsigned long) is the most portable thing to do among implementations)

>>16
you also forgot that the standard doesn't guarantee that those two values will be different...

>>18
I did not; I did not want to mention this minute detail because I'm sure >>15 would miss the 'accidental' case. It'd be even worse if he asked me for an existing implementation that does this, because how could I explain to him the concept of ds9k?

I know some people would complain that this program is a syntax error and even if I introduce a main definition it lacks the necessary prototypes in scope therefore the call to printf is undefined. Yes, I know of such people. I don't hang with them because I'm not a compiler maintainer though.

If you want to be really pedantic, you could claim the standard does not actually guarantee that you could have an object definition with type int somevariable[10][10] in a conforming implementation. (See section 4 Environment in the standard)

(ie sizeof (int) * 100 > SIZE_MAX)

(ie sizeof (int) * 100 > SIZE_MAX)
sizeof (int) would have to be at least 656 for that to happen… I guess that's about as likely as sizeof (int(*)[10]) being equal to sizeof (int) * 100.

>>16
sizeof(variable) is syntactic sugar for BEING RETARDED ENOUGH NOT TO REMEMBER THE TYPE OF THE VARIABLE and sizeof(array) is syntactic sugar for BEING RETARDED ENOUGH NOT TO REMEMBER THE (CONSTANT) CARDINALITY OF THE ARRAY.

Faggot.

>>21

Yes because sizeof(variable) is always the same value on every system under the fucking sun.

>>22

And nobody would ever EVER want to develop code for multiple platforms EVAR

>>21
It's clear enough that you've not put more than a week into Sepples. IHBT.

>>21
[b][u]CARDINALITY[/u][/b]

Hahaha-haha.

>>22
Let's assume variable was declared as int variable;
How is then sizeof(variable) any different from sizeof(int)?

>>25
;-)

>>26

You assume knowledge of the types or sizes of the variables.

Perhaps you imply that sizeof obj is syntactic sugar for sizeof (T), where the definition of obj is T obj; You'd be wrong; sizeof is allowed to evaluate its argument with VLAs. Even if we assume VLAs do not exist or are of no interest to our project, you can only do as much as replace what you know of. That which you do not know of, only the compiler can know. Here's an example


#include <stdio.h>
#include "3rdparty/foo"

int main(void) {
    size_t i;
    for(i = 0; i < sizeof foo / sizeof foo[0]; i++)
        foo_doit(foo + i);
    return 0;
}

sepples is such a cool language, it doesn't mess around with all that abstraction BS, it keeps you right down there with the implementation details the whole time, where REAL PROGRAMMERS dwell.

>>28
Do you really think of this? First, we're talking about C (though neither C++ has 'syntactic sugar' for arrays. C provides an important thin layer on top of the assembly language. The language is grammatically abstracted as much as it should for its purpose. If you knew anything about abstraction you'd be able to recognize this.

>>29
You might be surprised, but C++ actually much more robust and turnkey array support than C.
[code=cpp]
template <typename T, int length>
int array_length(const T (&t)[length])
{
    return length;
}

int main(int argc, char* argv[])
{
    char s[] = "abc";
    cout << array_length(s) << endl;
}
[/code]

>>29
I've composed about three lengthy responses to this, when I finally realized, IHBT. Well done.

>>29
here I bought this for you: )

>>32
Awww. And who says programmers can't be sweet? ;-)

Just believe in yourself OP! I know you can make it happen!

>>30

Why should I be surprised? C++ is more advanced than C. It was supposed to be so from the start.

>>31
No you didn't; you couldn't possibly have a good argument, because I hit the nail.

>>35
because I hit the nail.
With a herring.

>>35
your sepples doesn't work.
also, c does it better.
#include <stdio.h>
#define ARRAY_LENGTH(array) (sizeof (array)/sizeof *(array))
int main(void)
{ char s[] = "abc";
  printf("%zu\n", ARRAY_LENGTH(s)); }

also, back to /b/, please. it was the broken bbcode that gave you away.

>>36
That'd mean that I actually addressed the points which had to be addressed, but I did so poorly. Can you address the points to be addressed in an elegant manner instead? Assuming you're not >>30; I've lost all hope for >>30, he is quite obviously a "moron".

>>37
Did you really meant to quote me, >>35, and not >>30?

To type, or not to type: that is the question:
Whether 'tis nobler in the mind to suffer
The slings and arrows of compile-time checking,
Or to take arms against a sea of segmentation faults,
And by opposing end them? Don't bazooka cast: to sleep;
No more; and by a sleep to say we end
The heart-ache and the thousand natural shocks
That void* is heir to, 'tis a consummation
Devoutly to be wish'd. To die, to sleep;
To sleep: perchance to dream: ay, there's the rub;
For in that undefined behavior what bugs may come
When we have shuffled off to the next project,
Must give us pause: there's the respect
That makes calamity of so long life;
For who would bear the whips and scorns of time,
The preprocessor's wrong, /prog/'s contumely,
The pangs of despised w_chars, the while(1) delay,
The insolence of iteration and the spurns
That patient merit of the unworthy takes,
When he himself might his quietus make
With a null pointer? who would structs bear,
To grunt and sweat under a static life,
But that the dread of free after malloc,
The undiscover'd country from whose bourn
No local returns, puzzles call-by-value
And makes us rather bear those ills we have in C
Than fly to others that we know not of like Scheme?
Thus enterprise does make cowards of us all;
And thus the native hue of resolution
Is sicklied o'er with the UML,
And enterprises of great pith and moment
With this regard their currents turn awry,
And lose the name of action.

>>38
you posted both >>35 and >>30. /b/tards like yourself usually don't notice replies to any of your posts except the most recent one.