Shall I move from C to Java?

So, you're saying you want to redefine C such that experienced C programmers won't be able to read your code?

Just who are you planning on hiring to work on this?

Well, why not just refrain from using "goto"? I've been coding in C for nearly 20 years and have yet to use it myself (yes, I know it's good for exception handling). Were I to see one in a code review I'd be scrutinizing it closely, and probably trying to suggest realistic alternatives.

If you're trying to control developers by putting it in some universal header file they'll get around you one way or another; if you're trying to avoid using it yourself -- just avoid it.

how do you think

p(); if(xxx=yyy) goto L1; else { do_something(); v(); }

if the language support multi-thread, the debug time will be less.

a save language should not let user see the OS.

If you want a "safe" language that was designed to operate in a multithreaded environment and do systems/embedded programming, then there are approximately two answers, that I know of: Ada and Modula-3. There are certainly groups of people with extended versions of Java and C# doing approximately that too, though. Eiffel might fit the bill, and generally compiles through C, which might help.

Most practitioners just use C or assembly, and leave the safety and threading to higher-level tools (such as static checkers or code review processes) and operating systems.

If you want state of the art type safety, you might want to investigate erlang, ocaml, sml and hascall, but I don't know that anyone is using them for embedded work, unless you count telephone exchanges (quite a few of which run erlang) as embedded systems, which they probably are...

In news: snipped-for-privacy@k79g2000hse.googlegroups.com timestamped Tue, 14 Aug 2007 10:00:47 -0700, dick posted: |-------------------------------------------------------------------------| |"[..] | | | |another question is how to disable "goto", can I write #define goto | |error("no goto")" | |-------------------------------------------------------------------------|

Yes, but someone else can simply type #undef goto

Stupid questions deserve equaly stupid answers.

VLV

And you are always there to oblige, right? ;^)

Sorry, I couldn't resist...

On Aug 15, 10:23 am, Vladimir Vassilevsky

The question may have been ill-formed but I do not have enough information to judge that its intent was stupid.

Is there any Macro can hide the OS routine?

I believe that C syntax extension is a cheaper solution than a new language.

Actually in Embedded world, C has a lot syntax extension such as "interrupt fun()"...

So can we have "exclusive fun()" or "exclusive {...}"?

What OS routine are you referring to?

Are you planning on writing a compiler for only your use?

Which a don't use (or trust come to that). Although others certainly do. The syntax varies considerably as well.

And these would do what exactly?

Robert

Why do you want to use critical sections in the first place ?

I would consider critical sections harmful. A program with lots of critical sections cluttered all over the program is a sign of bad architectural design, which is also prone to priority inversion and other problems.

With proper data structure design and proper partitioning of functionality into (server)tasks, the need for critical sections would be greatly reduced.

In single processor embedded systems, disabling the interrupts (which also disables task switching), doing 2-4 lines of critical code and then enabling interrupts should satisfy the needs for critical sections. If this is not enough, you should look at your architectural design.

Paul

How many times have you had the opportunity to re-architect a badly designed system?

So you treat C as an abstract ASM or a machine generator?

I know why C is an OLD language. Just because the C community is not willing to improve it. C evolve slower than English.

So you treat C as an abstract ASM or a machine code generator?

I know why C is an OLD language. Just because the C community is not willing to improve it. C evolve slower than English.

First, Paul is describing how you can handle certain problems regardless of the language being used. So I don't understand your reply in this context.

Second, you are not totally wrong when you see a relationship between C and ASM: C was developed as high level 'assembly' for building the Unix operating system.

Third, you may regard the low-level look-and-feel of C as a disadvantage, but right for the above mentioned use, e.g. OSes but also embedded systems, it is advantageous to have precise control: C statements do what they must do and nothing else.

Of course this may not be what you want, but then you are free to use any other tool that suits you well, and it is no reason to start mocking about a presumed "C community". Have a look at comp.std.c and see how different people have many different opinions on the directions of the C language: a monolithic "C community" with a single voice denying change does not exist.

Rob Windgassen