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.
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)
Name:
Anonymous2009-06-10 17:08
>>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) 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.
Name:
Anonymous2009-06-10 20:08
>>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.
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
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.
Name:
Anonymous2009-06-11 12:08
>>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;
}
>>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?
Name:
Anonymous2009-06-11 22:28
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.
Name:
Anonymous2009-06-12 1:13
>>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.
int main(void)
{
char * s = "";
printf("%zu\n", ARRAY_LENGTH(s));
printf("%zu\n", ARRAY_LENGTH(&s));
printf("%zu\n", ARRAY_LENGTH(f)); // WTF is this shit?
printf("%zu\n", ARRAY_LENGTH(*f)); // WTF?
printf("%zu\n", ARRAY_LENGTH(**f)); // WTF??
printf("%zu\n", ARRAY_LENGTH(***f)); // WTF???
printf("%zu\n", ARRAY_LENGTH(&f)); // WTF?
// printf("%zu\n", ARRAY_LENGTH(&&f)); // WTF is 'label f not defined'?
printf("%zu\n", ARRAY_LENGTH(f())); // where is my side effect?
// printf("%zu\n", ARRAY_LENGTH(&f())); // WTF, why can't I do this then?
int * x = 0;
printf("%zu\n", ARRAY_LENGTH(x++)); // Can you guess what happens?
return 0;
}
None of the above should compile. None of the above compiles in C++. If we are trying to help those who are "retarded enough not to remember the cardinality of the array", as >>21 aptly put it, the usual arguments about manliness and having enough rope are even more irrelevant than usual.
Therefore I must conclude that your statement, also, c does it better
Is grossly inaccurate.
Name:
Anonymous2009-06-12 12:28
>>38 >>41
don't sage if you're replying to the thread. sage if you are saying 'fuck this thread, go to /r/' or whatever. idiot.
>>43
THAT IS NOT WHAT SAGE MEANS. IT HAS A DIFFERENT MEANING ON THE TEXT BOARDS THAN THE IMAGE BOARDS. NOW FUCK YOU. AND >>42 IS RETARDED BECAUSE HE DOES NOT KNOW THE SEMANTICS OF sizeof. FUCK YOU BOTH FOR BEING RETARDED. FUCK YOU.
>>42 sizeof does not evaluate it's operand. ARRAY_SIZE should work the same way as sizeof.
the sepples code posted earlier doesn't compile. the code posted by >>37 does. your code doesn't compile. the obvious conclusion is that people who use sepples are too stupid to understand even the most trivial c programs.
>>45
"when I see someone writing with caps it means he is really pissed off and I successfully trolled him, not that he bothered to just hit the caps lock key and then write normally"
Name:
Anonymous2009-06-13 8:02
>>46 sizeof does not evaluate it's operand. ARRAY_SIZE should work the same way as sizeof.
No, it shouldn't.
the sepples code posted earlier doesn't compile
Are you trolling me by implying that your unable to add #include <iostream>
using namespace std;
Or are you using Borland C++ Builder 3.0?
>>49 Are you trolling me by implying that your unable to add
Copiousness of cocks! Dribbling drift of dongs! Juicing jugs of johnsons! Wealth of wieners! Profusion of peckers! Deluge of dicks! Stacks of shafts! Waves of wiggly wangs! A plethora of penii!
Endless succession of cocks!
Name:
Anonymous2009-06-13 14:20
Whenever I look at sample code for a prospective hire, I look for using statements, and if found I file it in the BIT BUCKET.