Programming a Scripting Language

[Rizimar]

New blocks are useful in some switch statements because when you use them to jump to different cases, you can create a new block and create local variables inside of it.

Code: [Select]

switch(var)
{
        case 1:
        {
                int variable; // Declare variable in new block
                // Do other stuff here :P
        }
        break;

        ...

        default:
        break;
}

It's perfectly valid

[TheProgrammer]

New blocks are useful in some switch statements because when you use them to jump to different cases, you can create a new block and create local variables inside of it.

Code: [Select]

switch(var)
{
        case 1:
        {
                int variable; // Declare variable in new block
                // Do other stuff here :P
        }
        break;

        ...

        default:
        break;
}

It's perfectly valid

That is a switch block with a case block, which I've seen many people do that. But the code below is different, it's an expression with a new block. This is my first time seeing people do this.

Code: [Select]


const float pi = 3.14159f;
{
float stinky = pi;
}


[AssKoala]

You said that is a bad style in the code, but funny, you just did that.

I did it in the code I pasted so you could copy and paste it into a source file function and compile it.

In other words, it will compile and gets the point across.

It's bad programming practice to open random blocks.  It's fine in switch statements, though should really be avoided (you don't want to rely on the optimizer if you don't have to do).  Since, normally, a switch will be constantly executing, you don't want to be pushing a new set of values onto the stack every single time you enter a case.

[TheProgrammer]

So the code following is a bad programming practice, right?

Code: [Select]


const float pi = 3.14159f;
{
float stinky = pi;
}


[AssKoala]

So the code following is a bad programming practice, right?

Code: [Select]


const float pi = 3.14159f;
{
float stinky = pi;
}


Actually, that code is perfectly good programming practice.

The compiler will throw out everything inside the braces.

Now, were that in the middle of 500 lines of code and did something meaningful, then it'd be bad programming practice.

[TheProgrammer]

So the code following is a bad programming practice, right?

Code: [Select]


const float pi = 3.14159f;
{
float stinky = pi;
}


Actually, that code is perfectly good programming practice.

The compiler will throw out everything inside the braces.

You're really confusing me. Why would you write a C code that doesn't look like C?

[AssKoala]

You're really confusing me. Why would you write a C code that doesn't look like C?

That code IS C.  It looks like C (and it doesn't look like K&R C because there's no function delcaration).  It is just an "excerpt" that will compile.

If you think that doesn't look like C, you don't know C (or C++ for that matter since the scoping is virtually the same).

Code: [Select]


/* This may or may not compile, I wrote it as part of the post */

#include <stdio.h>

int main() {

    const float pi = 3.14159f;
   
    {
        float stinky = pi;
    }

    return 0;
}


The use of internal braces can be fairly useful in a testing main:

Code: [Select]


/* This may or may not compile, I wrote it as part of the post */

#include <stdio.h>

void foo(int*);
void bar(float*);
void baz(int*);

int main() {
    /* Test foo */
    {
        int i1, i2, i3;
     
        i3 = 6;
        foo(&i1);
        foo(&i2);
 
        if (i3 == (i1-i2)) {
            printf("foo() passes!\n");
        }

    } /* i1, i2, and i3 are popped off the stack and look
        * as if they never existed.  This lets each test
        * think it's in its own separate testing function
        * and removes conflicts without having to write
        * a crapload of testing functions.
        */

    /* Test bar */
    {
        float f1, f2, f3;
        /* .... */
    }
   
    /* Test baz */
    {
        /* .... */
    }

    return 0;
}



This, however, is VERY bad style:

Code: [Select]


/* some function in foo.c, assume constants are defined */
int calculateFoo(int iParam) {
    int i;

    for (i=0;i<10;i++) {
        iParam+=i;
    }

    {
        int temp;
   
        temp = doSomething();

        temp = iParam * PI*PI * temp;
 
        return temp;
    }
}


[TheProgrammer]

Alright, I'm just not skilled enough. I consider this a lesson learned. Thanks master AssKoala.

[Bad Sector]

I used #defines because i like them more than enums (i actually never used enums... i just don't like how they look in the code ). Also when i use #defines most source code editors syntax highlight the code and #defines have different color than enums (which in most cases have the same colors as other pieces of code - like function prototypes for example).

@TP:
Think "{" like a command which encloses other commands and can be used instead of a single command. For example, if's syntax is somewhat like:

Code: [Select]


if (expression) command


so you could write:

Code: [Select]


if (a == 1) printf("hi");


but not

Code: [Select]


if (a==1) printf("hi"); printf("hello");


since printf("hello"); is just another command following "if" not "printf". So you need to group them somehow, This is where { comes and you use it:

Code: [Select]


if (a==1) { printf("hi"); printf("hello"); }


But since { is like a command, it can be used everywhere commands can be used, including plain source code:

Code: [Select]


printf("hi");
{
      printf("hello");
}


which this is equal to:

Code: [Select]


printf("hi");
printf("hello");


[VladTheCompiler]

Hi,

Ahh, the good old #define vs const argument.

Well, I, personally, think macros are evil, and rarely use them. One perfect example of why macros are evil is AK's square macro example. Therefore, I don't very often use

#define PI 3.1415926

The reason is because it can get confusing when you are dealing with a large program. For instance, suppose someone's written some code for a mathematical package, and defined PI as above. Now, suppose you want to add a new function to the library that computes the circumference of a circle. So you write:

float C = 2 * PI * r;

What happens now? Your code doesn't compile. Why? Because PI is implicitly of type double, and you are trying to assign it to type float. Now, you have two choices to remedy that. One is that you can cast PI explicitly to (float), or you can add an f to the end of the definition of PI to make it implicitly float. The latter can be quite devastating, because if in some other place in the library you assumed that PI was a double, and relied on the implicit type to provide double precision, you will lose precision of computation, and that may be quite undesirable.

Any way, my problem with #defining constants is that they don't have an explicit type, so if someone goes in and screws with the value, the implicit type might change, and in the affected parts of the code, the compiler might introduce implicit casts, and not issue any errors or warnings, but the outcome of running the program would be wrong. Therefore, if I were to define PI, I would definitely use:

const double PI = 3.1415926;

Now, if someone passes the law to make PI = 3, and someone goes in and changes my code to:

const double PI = 3;

The precision of my computations is unaffected, because the type of the variable is still double, whereas in a #define statement it would have been int, and I could have got trunkated numbers.

Next, as far as performance concerns go, quite frankly, if I do something like this:

double C = 2 * PI * r;

I fully expect my compiler to precompute 2PI and use the constant value instead of messing with the stack. When I wrote my compiler, as part of the course I mentioned above, it was able to handle such cases of constant propagation, and honestly, if I could handle such cases, then professional compiler writers have no excuse for not doing so, and if for some reason someone uses a compiler that doesn't do that to compile my code, and they incur performance losses, I say it's too bad for them and they should get a normal compiler.

Cheers,

Vlad C

[VladTheCompiler]

Hi,

But since { is like a command, it can be used everywhere commands can be used, including plain source code:

Code: [Select]


printf("hi");
{
      printf("hello");
}


which this is equal to:

Code: [Select]


printf("hi");
printf("hello");


However, it can be confusing to use nested blocks, because:

Code: [Select]


int a = 10;
{
int a = 20;
a *= 20;
}
printf("a = %d\n", a);


Is not equivalent to:

Code: [Select]


int a = 10;
a = 20;
a *= 20;
printf("a = %d\n", a);


Cheers,

Vlad C

[TheProgrammer]

I personally don't like using #define. Vlad has a very good example.
Scott Meyers said that experienced C programmers will especially have
an unnerving time to adjust to C++, since the old C tricks continue to
work in C++ in his Effective C++ book. I was skeptical about that statement,
but I'm starting to believe it now.

Besides, I've really never seen people starting a new block like that.
Maybe I'm just not experienced enough, or maybe it is an old C trick.
I have, however, see people using assert for testing purpose all the
time, and I think assertion is a good feature in C++. Anyway, at least
I've learned something new, thanks AssKoala, badsector and Vlad.

[elias3c]

Get a book on writing a compiler.  It'll help.  A lot.

hey, you know where i can get, compiler writer tuteral on the internet?

[elias3c]

Get a book on writing a compiler.

hey, you know where i can get, compiler writer tuteral on the internet?

[Bad Sector]

Get a book on writing a compiler.

hey, you know where i can get, compiler writer tuteral on the internet?

Read the whole thread from the start.... i have somewhere posted a URL (or link) with a complete compiler writing tutorial