Curly bracket question

Well, you're probably missing a '}'. :)

If you're using any decent programming editor, it should be pretty obvious where to put it, since the indentation level won't "look right" somewhere.

Alternatively, run the program through indent or astyle and look at the output to see where the indentation isn't right.

I don't see how you expect the compiler to know where the missing bracket belongs.

I don't get it: what do you mean by "a back up system"?

I don't see how it's the compiler's fault.

I'm just using the standard Raisonance kit, I don't know how to patch in a descent editor. I've got stuff like PN2, but there seems to be little advice on how to stuff it into my compiler

My 1996 PCB design package has 4 undo files levels, *.bak1,*.bak2 etc, all the raisonance stuff is have a single .bak file

Quite agree, it's my fault, just wondering the best way to improve my programming knowledge, the help files are comprehensive, but uninformative

martin

It sounds like you need a real editor and a revision control system. There are many to choose from (I'm an emacs+svn guy).

Using a real editor will help lots. One of the reasons that IDEs generally suck is that the editor sucks. The rest of the "features" in IDEs are usually mediocre at best, and the documentation is usually useless.

It is hiding in a comment?

Well young man, go here:

and download pclint. It will find where your problem lies.

Oh, and belated birthday greetings. You do realise that 60 is the new

Oh, and just in case dementia is setting in already, there's one other thing. You have to install and run the pclint as well as downloading it.

;-)

... snip ...

That's 64, not 60. Unfortunately it is hard to pass off the years between 74 and 80.

Are you claiming pclint is now freely downloadable?

The missing brace can hide in one of the header files.

One technique is to binary search for the point where adding the extra brace fixes things. If it fixes it at the end of main(), try moving it nearer the beginning of the source file (keeping it outside other definitions, like routines, structures, or initialization lists). At some point you'll go too far and you'll get the opposite message ("unexpected left brace") and you'll know the problem is below that point.

If you discover that the problem is fixed by putting a brace just after an #include (and not when its on the prior line), the problem will be in the include.

Arghhh -- the Evil -- it burns!

Sorry, I'm a vi+rcs guy and there hasn't been enough emacs bashing on here lately. '-)

Yup. Getting really familiar with one, ideally cross-platform, editor is a Good Thing.

I like the way that Imagecraft handles the "problem" in their IDE, by allowing the user to select and use their own favorite editor instead of the IDE's built-in one. It installs with hooks for a dozen well-known (and not so) programmer's editors (including EMACS!) plus a spot to define a new one if none of the others match.

The downside is that features like code completion may be missing, but there's the real upside of continuing to use one's own finger-macros.

Back at the OP: might give "indent" a try if the IDE doesn't include a code reformat option.

There is a free (GPL) lint tool available at

... snip ...

I have that. I was wondering about pclint, which is better.

Unless, the compiler is shockingly bad it will be using simple text files. You can just edit them outside of the IDE and use them in the IDE. Some IDE's even detect files that change while they are loaded.

Even shockingly bad IDEs often allow exporting and importing text files which you can then edit. I've done this with PLC IDEs.

If you are running Windows you might take a look at Notepad++. Not high end but easy enough to start with.

Longer term, I strongly recommend PC-Lint (and turn the errors up until they are slightly painful). It's feedback will help you learn good habits quickly. Don't let a warning pass without understanding its source.

Not as quick as getting even a halfways decent editor but take a look at a version control system. When I'm working on a project any version that actually compiles gets archived.

Robert

Too bad it's so expensive for Linux users. :(

I spent a few days battling with splint, and never got it to do anything useful.

In order to elimiate warnings about code like this:

unsigned uint8_t b; b = 5;

You had to turn off warnings for code like this:

unsigned uint8_t b; b = 12345;

After asking about this and several other significant problems on the splint mailing list I was told that splint is intended as a research project and not as something that's meant to be useful for checking real-world source code.

At that point, I gave up on split.

Oops. Disregard the "unsigned" in the above example.

A serious impediment to switching for me.

Robert

I agree they need a cheaper Linux version - but I think the Win32 console version will work with Wine on Linux, check the Gimpel discussion list.

No thanks. I'm not willing to jump through hoops for the sake of rewarding Gimpel's antiquated pricing policies. If they want me as a customer, they're going to have to price the Linux version lower.

Would that be transparent to make? IE could make call it and get the error codes returned (with the messages piped accordingly of course)?

Robert

Thanks for that, downloaded it and will play with it soon. Does that mean I'll have double dementia?

martin