Is c# so easy? Easier than c? Think again...

  • Thread starter Thread starter jbailo
  • Start date Start date
Hi Fergus Henderson , You say :
" That single line of C code will
_ silently ignore any failures _ . "

I hope the hell it does !

Unless you're debugging the code ,
you never want your code to complain or halt .

For example , unless your debugging ,
dividing by zero should be a non issue .
 
I like the C language the best because it makes the most sense.
Both C and C++ support goto label,
Click to expand...

'sides typing GOTO reminds you of all the fun you had with BASIC...
 
The line of code u are talking about is the precise way of doing it....
nothing less or more...

and we anyway need a loop to access out whatever have been received thru
the port...

Keyur Shah
732-423-0745
 
You are crazy



jbailo said:
Day Is C#

Day Is C++++++

Day Is C

I uzzzz Czzzzz

Czzzz assbackass, RPNzzz,
In-Fixzzzing-Notashunzzzz.

you don't know what hood is good
until you is programmzzz in Czzzzzzz

Sa Czzzz
Izn, Sa c#
Izn, Sa c
Izn, Sa c++++++

Sa Czzzzzzz

Exclamation POINT (!)
Click to expand...
 
Jeff said:
[ Reposted , This time to the right groups ]

Hi mlw , You say :
" What do you mean ' line oriented ? ' "

You must be a young whipper snapper .
Click to expand...

Not likely, I worked on a Sun One and a vax 11/780. You know, the old
machines. I have been in the field for 20 years.
In the early days ,
some editors would only edit one line at a time .

They were " Line Oriented " .

My preprocessor , in MS Dev C++ 6.0 ,
won't let me do something like this :

int X; #define Mac1(X) X++; #define Mac2(X) X--; Mac1(X);

If there a better preprocessor ?
Click to expand...

In your example, I don't see what the would be a benefit. Macro definitions
have no effect in compiled code. The are filtered out from the compile
stage so it is unnessisary to have them terminated with a semicolon.

In general, your line is confusing at best, because you have two elements in
a line which have no real effect on the code.

They are not "line oriented" per say, like old cobol, but the parser does
read one line at a time. You can make it span lines with a back slash.
 
["Followup-To:" header set to comp.os.linux.advocacy.]
'sides typing GOTO reminds you of all the fun you had with BASIC...
Click to expand...

goto's are fun!

if (istrouble)
goto hell;

hell:
 
Jeff said:
Hi Eric Matteson , You say :
" The simple traditional C language is
the best high-level language that I know of . "

As an old timer myself , I tend to agree with you .

But you can can convert all of your old C programs
into C++ programs in just a few minutes .

Why do this ?

Because I've found that
there is more documentation and support for C++ .

If you stick with C you'll be left behind .
Click to expand...
[snip]

I'm an old C guy, and I use C++ almost exclusively. I use it mostly like a
better C with classes. There is nothing in C that can't be done in C++, but
the converse is not true.

Yea, a lot of people will say, "C++ lets you make bad programs," this may be
true, but strict C allows really ugly stuff, especially when you try to do
the stuff C++ allows but C does not. Look at the GTK compared to QT.
 
Jeff said:
Hi Fergus Henderson , You say :
" That single line of C code will
_ silently ignore any failures _ . "

I hope the hell it does !

Unless you're debugging the code ,
you never want your code to complain or halt .

For example , unless your debugging ,
dividing by zero should be a non issue .
Click to expand...

divide by zero will almost always cause a hardware fault, and it will be
pushed back up to the process, where you will have to deal with it
asyncronously.
 
[ Reposted , This time to the right groups ]

Hi mlw , You say :
" What do you mean ' line oriented ? ' "

You must be a young whipper snapper .

In the early days ,
some editors would only edit one line at a time .

They were " Line Oriented " .

My preprocessor , in MS Dev C++ 6.0 ,
won't let me do something like this :

int X; #define Mac1(X) X++; #define Mac2(X) X--; Mac1(X);

If there a better preprocessor ?
Click to expand...

If reliable code is your aim, you should avoid macros as they are not type
safe. It is much better to use inlines. The second advantage of inlines is
that you can also step into the inline code with the debugger.

Ian
 
In comp.os.linux.advocacy, Jeff Relf
<[email protected]>
wrote
Hi Fergus Henderson , You say :
" That single line of C code will
_ silently ignore any failures _ . "

I hope the hell it does !

Unless you're debugging the code ,
you never want your code to complain or halt .

For example , unless your debugging ,
dividing by zero should be a non issue .
Click to expand...

Is that what the Yorktown was doing? :-)
 
Hi Spooky , You say :
" Is that what the Yorktown was doing ? :-) "

The Yorktown ? What is that ?

It sounds more like a city than a piece of code .
 
Jeff said:
Hi Spooky , You say :
" Is that what the Yorktown was doing ? :-) "

The Yorktown ? What is that ?

It sounds more like a city than a piece of code .
Click to expand...

For me it sounds much more like a warship. And it is
It is the one which had to be *towed* back into harbour after Windows shut
down the complete network, leaving the ship without propulsion. Another
example of windows superiority: Divide by zero and you disable complete
ships. Good, sound OS design
 
Hi mlw , You say :
" divide by zero will almost always cause a hardware fault ,
and it will be pushed back up to the process ,
where you will have to deal with it asynchronously . "

In non-debug mode , That's not true at all .

By default , Microsoft's old sixteen bit compilers
did throw an exception for a floating point divide by zero ,
Even when you weren't in debug mode .

But that drastic error was fixed with the 32 bit stuff .

The following code will only toss an exception
if you compile for _ Debugging _ :

int XXX= 1, YYY= 0; XXX /= YYY;

Non-debug code _ Should _ never halt or complain .
 
Jeff said:
Hi mlw , You say :
" divide by zero will almost always cause a hardware fault ,
and it will be pushed back up to the process ,
where you will have to deal with it asynchronously . "

In non-debug mode , That's not true at all .

By default , Microsoft's old sixteen bit compilers
did throw an exception for a floating point divide by zero ,
Even when you weren't in debug mode .

But that drastic error was fixed with the 32 bit stuff .

The following code will only toss an exception
if you compile for _ Debugging _ :

int XXX= 1, YYY= 0; XXX /= YYY;

Non-debug code _ Should _ never halt or complain .
Click to expand...

It "should" because the result is undefined.
 
Hi mlw , You say :
" It "should" because the result is undefined . "

Well you better try to get Microsoft
to change it's default behavior then !

I'm using MS Dev C++ 6.0 on Win98 .

Build some divide by zero errors in release mode ,
( not debug mode )
try both floating point and integers ...
No interrupts will happen .
 
Hi mlw , You say :
" I don't see what the would be a benefit . "

I assume you don't know of a preprocessor
that is not line oriented then ... Oh well .

How archaic .
 
The language isn't the entire issue.

First of all, C# is supposedly an object oriented language. (I say
'supposedly' because I've never looked at it carefully. I'm only
repeating what the press has reported on it.) Therefore, it should be
compared to other object oriented languages, including those that
enforce OOP or simply allow it as an optional programming paradigm. Some
of these are: Java, C++, Perl, etc.

Then, you have to answer some important questions about each language,
such as: number of platforms supported, library support, o/s system APIs
for each platform, portability, multiple vendor support, etc.

The biggest problem I can see with C# is that it was designed by
Microsoft as a language coupled to an environment (.NET) that would
forever bind developers to Windows. With the development of the Mono
project, this is no longer true. So, as a developer, how much time and
money are you willing to spend when Microsoft drops C# and comes out
with their next strategic move? Ask the J++ developers how they are
feeling right about now.
 
ECMA and ISO isnt a windows machine.

GTK# isnt windows specific, Mono isnt windows specific.

Have you ever read any of the specifications?

While you are dilly dallying about fancy footing and whining I will be to
market before you. Thats what counts, thats what made microsoft what it is,
they where there when needed.

Be mr.fancy pants all you want. I will be there first :D
 
ECMA and ISO isnt a windows machine.

GTK# isnt windows specific, Mono isnt windows specific.

Have you ever read any of the specifications?

While you are dilly dallying about fancy footing and whining I will be to
market before you. Thats what counts, thats what made microsoft what it is,
they where there when needed.

Be mr.fancy pants all you want. I will be there first :D
Click to expand...

I'm not principally a developer. I'm a customer. Over the past 10 years
I have yet to see anyone successfully port applications we use to
Windows. They have been available on SunOS, HPUX and AIX for years. And
the port to Linux was trivially simple, according to the developers.
They believe that it won't be much more difficult for OS X. The code I
do write is to tie these applications together, so I need something that
can interoperate between multiple systems.

One other thing you have to consider when selling apps. to _informed_
customers: We can calculate our cost application ownership quite easily.
We don't so much care how easy it was for the vendor to crank out. In
fact, in my experience, platforms that support quick and dirty s/w
development tend to get exactly that kind of product built for them. And
then we, the end users, have to pay.
 
Back
Top