if you run it in devc++ it will work.Code:#include <stdio.h>
int main()
{
int bil;
scanf("%d", &bil);
int kotak[bil];
return 0;
}
can someone explain why this can be happening?
my lecturer also doesn't know about this
Printable View
if you run it in devc++ it will work.Code:#include <stdio.h>
int main()
{
int bil;
scanf("%d", &bil);
int kotak[bil];
return 0;
}
can someone explain why this can be happening?
my lecturer also doesn't know about this
C99, VLA ( variable length arrays ). gcc supports ( in some way ) VLA's for quite a while already.
Kurt
If you use the -pedantic option with gcc, it will issue the following warnings (see gcc's documentation):
foo.c: In function ‘main’:
foo.c:9: warning: ISO C90 forbids variable-size array ‘kotak’
foo.c:9: warning: ISO C90 forbids mixed declarations and code
C99 also allows you to write ugly code variable declarations throughout your program, instead just at the beginning.
Quzah.
Can someone explain me in a very easy explanation? I don't get it at all..
If I'm able to use that then I don't have to use malloc again?
Like has been said already, it's a feature new in C99.
But most everyone uses C89 if they want to write portable code.
No I'm afraid it's not a replacement for malloc. I'm pretty sure a variable sized array inside a function will be allocated on the stack (hence of limited size). But even worse if you should return a pointer to this array, the pointer would be invalid and writing to it would likely crash your program. It's kind of equivalent to the old alloca() function I think.
However if you only need the array for your current function then it is pretty nice. The array will get 'freed' when the function returns (by virtue of your stack pointer being restored to the callers context.). So you need never call free in that case. Now trying to find a fully compliant C99 compiler on the major platforms though might be an issue. Thus C99 code could not be considered particularly portable.
What's the politics behind it taking so long for compilers to support C99? Didn't C++98 have reasonably complete support years ago? And is gcc progressing towards complete support in the near future? I know it can be run in (not fully implemented) C99 mode with -std=c99.
For microsoft they probably feel there is not enough of a market to make it worthwhile implementing it. Their flagship IDE supports C++ and then some of their .net languages like C#. The only real hope is for C++ to decide to support C99 as a subset of the language.
Frankly there are very few C99 compliant compilers out there and none of them are free and maybe only one of them runs on windows. gcc claims to be close, however the two most important changes for scientific programming, variable length arrays and complex numbers are either not supported or broken for gcc
http://gcc.gnu.org/c99status.html
.
C99's strength is really in the scientific computing area, which I guess compiler writers see no use for.
VLA's are essentially useless candy IMO.
The biggest problem is what happens if your VLA no longer fits on the stack (assuming that is where VLAs get created on a given machine). Even the best scenario results in the program being killed by the OS. On an embedded system, it probably just trashes someone else's memory. Nor is there a way of finding out in advance whether it will succeed or not, just close your eyes, pray and take a jump.
Of course, a lot of naive programmers are going to take unchecked user input, and create their VLA directly from that. Most of them won't even bother to check for negative numbers, nevermind huge positive numbers.
At least with malloc, there is a clearly defined way of being told there is no more room, and from there you can take appropriate action.
uh... you mean to say *fully* compliant, right? because:
Quincy 99
Code::Blocks
Dev-C++
Pelles C
are all free, and all run on Windows.
If you're not fully compliant, then you're not compliant. Don't they teach people anything in school any more? Didn't you ever learn that "in a true or false question, if any of it is false, then the whole thing is false"? Thus, is it compliant? No.
Quzah.
Compliance in so much as it pertains to the more notorious of the C99 standards, such as those that make it possible for the OP's code to compile. In this context, the qualifier "fully" makes it clearer as to whether it complies with every C99 standard, as it is not uncommon to refer to a compiler as C99 even though it supports only the majority of these standards. It's a shame the english language isn't completely boolean quantifiable huh?
> Quincy 99
> Code::Blocks
> Dev-C++
You do know the difference between an IDE and a compiler right?
Because all of those things are IDEs which basically come 'out of the box' with the MinGW port of gcc as the actual compiler.
Yes all true, but it has a place. If you need scratch memory allocated dynamically it can be quite convenient. For example if I'm doing a bunch of matrix operations, or even a bunch of rotations using quaternions for graphics applications, I'd like to be able to allocate some temp memory of small but possibly unknown size; use it for my calculations and then discard it.
I suppose also, if you want to get a little more sophisticated you can try to increase your stack size. I know how to do that in assembly language, but I'm not sure about the various C compilers. Microsoft no doubt has some pragmas that support it and maybe gcc does to. Unfortunately MS has decided in recent versions of their compilers that inline assembly is simply not necessary any more.
quincy 99 is a bit obscure but I'd love to find out more about it. Is it a preprocessor that outputs C code? Is it fully C99 compliant eg VLAs and complex number support?
Dev-C++ will be gcc based and hence has their C99 limitations (eg no VLAs and no complex number support). By the way the reason why I want C99 complex number support is that a complex number is essentially double c[2] ; an array of 2 doubles. That plays nicely with Fortran which is why they chose this.
Pelles I am well aware of. It is missing several C99 features as well. VLAs are only partially supported, if they are dirt simple. I don't think for example you could dynamically allocate an array of pointers to some other complex type and I don't think it would allocate multidimensional arrays (not that I ever use C multi-D arrays.) Also of course, no one supports complex.
Yup I've seen the list. Have you seen the price list? I think Dinkumware's C99 libraries are about $200 and then the front end from Edison Design costs some money, and then you still need a valid C89 compiler, which I suppose you could get for free. Then there is the cost of an IDE if you use that sort of thing and who knows if it plays nicely with C99 etc. etc.
In other words the support for C99 isn't exactly overwhelming.