Language extension

[linuxdude]

on the first assignment what about syntax errors. I am looking for a ( or a word Can I assume they won't have

for )

or something like that.

[Thantos]

Um linuxdude you are going from Pascal to C so you shouldn't be looking for

for (

should be more along the lines of

for i := 0

[linuxdude]

I figured we could have both types of for loops in the code

[Thantos]

Ah, I would guess if there is a syntax error then you ignore it

[linuxdude]

One last question. Will all the for loops conditional part at least be on one line? Also can we assume that variable name isn't a keyword??

[Sang-drax]

Do not assume anything

[Prelude]

>but when is it due?
As long as it takes everyone to finish. When everyone who signed up in the first month submits and entry, the contest will be judged and the results posted. So feel free to take your time and do a good job.

>I figured we could have both types of for loops in the code
Yes. The extension shouldn't effect use of the rest of the language at all.

>I would guess if there is a syntax error then you ignore it
If it's a syntax error with the extension then you should handle it appropriately. I don't expect the preprocessor to completely understand anything more than the extension that it implements, but valid extension syntax should usually compile into valid C or C++ code.

>Will all the for loops conditional part at least be on one line?
Not necessarily. C and C++ are free-form languages.

>Also can we assume that variable name isn't a keyword??
Adding a check to ensure that the variable is a valid identifier and not a keyword would be a very good idea. The variable name does count as the syntax of the extension. Besides, such a check is relatively easy anyway.

[linuxdude]

what about a loop like this. How is it in PASCAL?

for(i=0;i<250;x+=2);
or
for(i=0;i<100;x^=20);

Do we have to incorporate those. And if so what is the syntax?

[Thantos]

Pascal for loops only increment or decrement by 1.

[jverkoey]

hmm, i'd enter this contest, but i'm too busy working on my actual language, lol. I'll just submit an OST->C++ converter program

[Prelude]

>is that what you mean?
That would be a good start, but don't forget that the string has to be able to grow and shrink on its own. So using a statically sized array in the preprocessor doesn't meet the requirements.

[Thantos]

I think the approach and method is for you to figure out.

[Prelude]

>that means that i will heavily use realloc()?
Well, you don't have to. You could use malloc to allocate an array of some insanely huge size so that realloc or anything similar is unnecessary. As for the actual implementation, that's up to you to decide. You get to weigh different options and choose the one that fits the task best.

[Prelude]

ok, one more question and i am done: what's better:
a.realloc() ,or
b. free() and then malloc() ?
thanks

I don't like realloc. Any benefits you could get are destroyed by unpredictable behavior. You're effectively tricked into thinking that you're getting something when you're simply introducing subtle bugs. So rather than this:

T *temp = realloc(p, new_size);
if (!temp) {
  error("Memory exhausted");
}
else {
  p = temp;
}

I prefer to do this:

T *temp = malloc(new_size);
if (!temp) {
  error("Memory exhausted");
}
else {
  memcpy(temp, p, old_size);
  free(p);
  p = temp;
}

Now you can be sure of what's happening. Instead of hoping that any pointers into the memory block will not be invalidated, you ensure that they are so that they can be reseated accordingly. You also avoid sticky issues where realloc actually frees the memory instead of resizing it.

[Prelude]

>but isn't somehow like that realloc() is implemented?
Yes, but realloc may or may not change the address of the original pointer which may or may not invalidate any pointers into the original memory. I'd rather be sure that it did so rather than hope it didn't and potentially get burned later when accessing a pointer outside of my address space.

>here you meanthat it first frees the memory, then tries to alllocate a new block and it fails, right?
No, I means that if the size is 0, realloc is the equivalent of free. No resizing is done, the memory is lost. The part that's sticky is that if the size were somehow set to 0 by accident, you'll end up accessing freed memory later.