• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
tiresandplanes

Why isn't my array working?

19 posts in this topic

Hi, I'm not sure why this isn't working. I define SIZE at the beginning but it seems not to work. I replaced SIZE with a different number and it worked fine. Why isn't it recognizing what SIZE is?

 

#include <stdio.h>

#define SIZE 10;

    main()
    {
        int i, array[SIZE];
    for(i = 0; i < SIZE; i++)
    {
    array[i] = 0
    }
    }

Errors I get:
C:\Users\Gary\Desktop\c\firstproga.c||In function 'main':|
C:\Users\Gary\Desktop\c\firstproga.c|7|error: expected ']' before ';' token|
C:\Users\Gary\Desktop\c\firstproga.c|8|error: expected expression before ';' token|
C:\Users\Gary\Desktop\c\firstproga.c|10|error: 'array' undeclared (first use in this function)|
C:\Users\Gary\Desktop\c\firstproga.c|10|note: each undeclared identifier is reported only once for each function it appears in|
C:\Users\Gary\Desktop\c\firstproga.c|11|error: expected ';' before '}' token|
||=== Build finished: 4 errors, 0 warnings (0 minutes, 0 seconds) ===|
 

0

Share this post


Link to post
Share on other sites

Ahh thanks! For some reason the book has a semi-colon at the end of a macro. It really threw me off. Must just be a typo in the book. Thank you guys!

0

Share this post


Link to post
Share on other sites

Ahh yeah in the original program I did have the semi there, I had to retype it on a different computer and forgot it. thanks.

0

Share this post


Link to post
Share on other sites
'array' is a keyword in C++ IIRC, so it's a good habit to not use it as a variable name. Rather than using #define to define constants it's better to just make constants:
const size_t SIZE = 10;
This gives you type control and avoids macro expansion problems like the one you encountered.

Using #define is almost the same as using your a text editor's 'find-and-replace' function. There are some cases where it's useful, but usually it causes more problems than it solves.
1

Share this post


Link to post
Share on other sites

'array' is a keyword in C++ IIRC, so it's a good habit to not use it as a variable name. Rather than using #define to define constants it's better to just make constants:

const size_t SIZE = 10;
This gives you type control and avoids macro expansion problems like the one you encountered.

Using #define is almost the same as using your a text editor's 'find-and-replace' function. There are some cases where it's useful, but usually it causes more problems than it solves.


I am pretty sure "array" is not a keyword in c. There is the std::array type, but that's only in c++.

Also, nice analogy there with the "find and replace", I've never thought about it like that. Edited by ultramailman
0

Share this post


Link to post
Share on other sites

'array' is a keyword in C++ IIRC, so it's a good habit to not use it as a variable name. Rather than using #define to define constants it's better to just make constants:

const size_t SIZE = 10;
This gives you type control and avoids macro expansion problems like the one you encountered.

Using #define is almost the same as using your a text editor's 'find-and-replace' function. There are some cases where it's useful, but usually it causes more problems than it solves.

The problem with const size_t is that a global variable defined like that is addressable, and must be generated in the object file. #define, for it's faults, does not have this problem. Therefore I consider a #defined macro to be the preferred general purpose way to declare constants in C.

 

C++ has slightly different rules for global constants, so there the convention is different; in c++ global constants have internal linkage, and do not allocate storage if nothing takes their address.

Edited by King Mir
0

Share this post


Link to post
Share on other sites

Rather than using #define to define constants it's better to just make constants:

const size_t SIZE = 10;
This gives you type control and avoids macro expansion problems like the one you encountered.

Using #define is almost the same as using your a text editor's 'find-and-replace' function. There are some cases where it's useful, but usually it causes more problems than it solves.


Actually, I don't think this is true in C. I couldn't get this to work:
const int N = 10;

struct S {
  int i[N];
};
Edited by Álvaro
1

Share this post


Link to post
Share on other sites

I am using K & R to learn C and I was just copying what they did. There was a typo in the book, and I didn't know it was bad to use macros.

0

Share this post


Link to post
Share on other sites

Rather than using #define to define constants it's better to just make constants:

const size_t SIZE = 10;
This gives you type control and avoids macro expansion problems like the one you encountered.

Using #define is almost the same as using your a text editor's 'find-and-replace' function. There are some cases where it's useful, but usually it causes more problems than it solves.

 

Actually, I don't think this is true in C. I couldn't get this to work:
const int N = 10;

struct S {
  int i[N];
};

I had forgotten about this additional problem. Yeah, that's the other reason to use a macro. Constant variables are not constant expressions.

Edited by King Mir
0

Share this post


Link to post
Share on other sites

I am using K & R to learn C and I was just copying what they did. There was a typo in the book, and I didn't know it was bad to use macros.

It's not for this. Just don't do it in C++.

 

K & R is a very old book though. There should be better, more modern, books out there. In particular, it's bad practice (and may be against C99, I'm not sure) to use implicit return int like you do. You should explicitly write "int main".

0

Share this post


Link to post
Share on other sites

I am using K & R to learn C and I was just copying what they did. There was a typo in the book, and I didn't know it was bad to use macros.

 

It's not bad to use macros per se. But if you do then you need to understand the consequences of using them and give yourself some strict guidelines in doing so. In C programming, they can be quite useful (extremely so, in some cases). The flip side is that it is easy to create macros that do not behave the way you expect them to. In C++, there are better, less error-prone alternatives, hence macros are frowned upon in the general case. But even in C they should be used with care. For simple constant values like SIZE, they are perfectly safe. When I program C, I prefer macros for that situation unless I need several related constants, in which case I'd use an enum, You just need to keep in mind any issues that may arise from the data type being used (i.e. signed vs unsigned, integer vs floating point), but that's something you need to be aware of with any variable.

1

Share this post


Link to post
Share on other sites

Álvaro, on 11 Feb 2013 - 13:49, said:
Actually, I don't think this is true in C. I couldn't get this to work:

const int N = 10;

struct S {
  int i[N];
};

That would definitely be a good case to use them. (I didn't say never to use them.) I think you can still use const values in stack arrays though. They cause so many problems so easily I just really think it's best to avoid them wherever possible.

King Mir, on 11 Feb 2013 - 13:29, said:
The problem with const size_t is that a global variable defined like that is addressable, and must be generated in the object file. #define, for it's faults, does not have this problem. Therefore I consider a #defined macro to be the preferred general purpose way to declare constants in C.

Why is this a problem? I don't follow.
0

Share this post


Link to post
Share on other sites


Álvaro, on 11 Feb 2013 - 13:49, said:
Actually, I don't think this is true in C. I couldn't get this to work:

const int N = 10;

struct S {
  int i[N];
};


That would definitely be a good case to use them. (I didn't say never to use them.) I think you can still use const values in stack arrays though. [...]


Sort of. C99 has variable-length arrays, which is why it will work if you use a `const' variable as the size of an array on the stack. Edited by Álvaro
1

Share this post


Link to post
Share on other sites

.
King Mir, on 11 Feb 2013 - 13:29, said:
The problem with const size_t is that a global variable defined like that is addressable, and must be generated in the object file. #define, for it's faults, does not have this problem. Therefore I consider a #defined macro to be the preferred general purpose way to declare constants in C.

Why is this a problem? I don't follow.

Álvaro pointed out the bigger issue, which is that constant variables are not compile time constants from a language perspective, and so cannot be used in array sizes generally. I was pointing out that the compiler is not required to promote them to compile time constants.
0

Share this post


Link to post
Share on other sites

King Mir, on 12 Feb 2013 - 16:59, said:
Álvaro pointed out the bigger issue, which is that constant variables are not compile time constants from a language perspective, and so cannot be used in array sizes generally. I was pointing out that the compiler is not required to promote them to compile time constants.

Ah. I get you. Are there any plans to update C any more? Seems like something that could easily be standardized.
0

Share this post


Link to post
Share on other sites

King Mir, on 12 Feb 2013 - 16:59, said:
Álvaro pointed out the bigger issue, which is that constant variables are not compile time constants from a language perspective, and so cannot be used in array sizes generally. I was pointing out that the compiler is not required to promote them to compile time constants.

Ah. I get you. Are there any plans to update C any more? Seems like something that could easily be standardized.

The C working group is definitely alive and updating, and C11 recently came out, but, as far as I know, changing the nature of const to match C++ is not something anyone is pushing for. The latest proposals can be found here http://www.open-std.org/jtc1/sc22/wg14/www/docs/PostPortland2012.htm

 

 

But there's not as much energy for improving C as there is for C++, and even C99 adoption has been poor. Notably Visual studio does not and does not  plan to support C99.

1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0