XSpice codemodeling for dummies?

[Kevin Aylward]

Chuck Harris wrote:

Active8 wrote:

Tell it to Dennis Richie, the designer of the "C" language, he
codes:

for(;{
}

As do I.


i can read it, but i'm not use to or fond of it. it reeks of java.

It can't reek of java, it preceeds java by more than 20 years!

the style:

for(;{
}

is known as *K&R style*. I know, because I have been using it since
the late '70s when I was programming in "C" on early Unix edition 6
and 7 on PDP-11/70s.


The reason I format my "C" code that way is it saves 1 line per
block. This makes it easier to see an entire complicated block in a
single screen without in any way obscuring the block nature of the
language.


unless you add another line. then your on another screen.

If are used to the language, it is no problem to see the beginning
letter of the for, while, if, function, ... as the beginning of that
block.

But seriously, this is simply a matter of personal preference...
I've never met a good "C" programmer who couldn't bounce back and
forth from one style to the other as necessary. But given that it
is you Kevin, it really doesn't surprise me that you would be so
intolerant of coding styles that don't match your own.

-Chuck



c's nice for embedded, but C++ rules. those old c habits, functions,
etc. creeping into application codes are bad, IMHO.


C++ needlessly bloats the code.

Nope.

Mission Statment:

The fundamental mission of any and all software (in business) is to
maximise the financial profit returned to the financial investor of the
code producer. Nothing else matters.

For example, writing a GUI is Windows API functions will take an order
of magnitude longer then writing in MFC. In the cases where such code is
hypothetically larger, it is clearly not needless based on the mission
statement.

It is the primary reason that
people need 160GB hard disks, and 1Gb of ram on their computers.

Don't be bloody daft. You don't really believe that do you? The reason
one needs large memory is because applications have gotten larger and do
more, ie. more features, irrespective of the coding language.

Secondly, for 99.99% of applications memory and speed is simply not an
issue. There are millions of MS VC programmers out there, not embedded,
500Mhz real-time ones. Sure, there are applications that are quite
thrifty, but one has to move with the times.

A good programmer writes good code. It doesn't matter much what
language he uses.

Thats right.

C++ allows ALL of C's dirty tricks, and more.

I disagree. Its quite the opposite. C++ type checking is designed
specifically to stop you doing this. C is a complete nightmare. It lets
you do anything. For example, its difficult to set a pointer to one
function type to another in C++. The compiler wont let you do it
directly. The reality is, if the the code compiles, it usually works. I
have done a lot of work in both c and c++, an its a no brainer, c++ is
the only way to go.

Kevin Aylward
salesEXTRACT@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.

 

[Active8]

In article <bkdjms$jc7$1@bob.news.rcn.net>, cfharris@erols.com says...

Active8 wrote:

Tell it to Dennis Richie, the designer of the "C" language, he codes:

for(;{
}

As do I.


i can read it, but i'm not use to or fond of it. it reeks of java.

It can't reek of java, it preceeds java by more than 20 years!

the style:

for(;{
}

is known as *K&R style*. I know, because I have been using it since
the late '70s when I was programming in "C" on early Unix edition 6 and
7 on PDP-11/70s.

i was pretty sure the if(){ style was K&R, but i meant that the first
time i saw that style was in java code, so for me it reeks of java. by
"reek", i suppose i mean that i don't like java that much and that
opinion is reinforced by my first attemts to use swing which IIRC came
with my first JDK. non of the example code ran. it crashed.

of course the examples in my Schildt and Petzold books didn't work
either. i had to mix and match and use the MSDN lib to get what i wanted
done. live and learn, i guess. maybe that's why it's called
"developement".

The reason I format my "C" code that way is it saves 1 line per block.
This makes it easier to see an entire complicated block in a single
screen without in any way obscuring the block nature of the language.


unless you add another line. then your on another screen.

If are used to the language, it is no problem to see the beginning
letter of the for, while, if, function, ... as the beginning of that
block.

But seriously, this is simply a matter of personal preference...
I've never met a good "C" programmer who couldn't bounce back and
forth from one style to the other as necessary. But given that it
is you Kevin, it really doesn't surprise me that you would be so
intolerant of coding styles that don't match your own.

-Chuck



c's nice for embedded, but C++ rules. those old c habits, functions,
etc. creeping into application codes are bad, IMHO.

C++ needlessly bloats the code. It is the primary reason that
people need 160GB hard disks, and 1Gb of ram on their computers.

i've seen side by side examples of C++ code that takes not much more
memory/disk space than the equiv asm routine. i imagine the object
oriented part can cause bloat, but OO is why we use C++ anyway.

A good programmer writes good code.

thanks
mike

It doesn't matter much what
language he uses. C++ allows ALL of C's dirty tricks, and more.


mike

 

[Active8]

[snip]

C++ needlessly bloats the code.

Nope.

Mission Statment:

The fundamental mission of any and all software (in business) is to
maximise the financial profit returned to the financial investor of the
code producer. Nothing else matters.

For example, writing a GUI is Windows API functions will take an order
of magnitude longer then writing in MFC. In the cases where such code is
hypothetically larger, it is clearly not needless based on the mission
statement.

It is the primary reason that
people need 160GB hard disks, and 1Gb of ram on their computers.

Don't be bloody daft. You don't really believe that do you? The reason
one needs large memory is because applications have gotten larger and do
more, ie. more features, irrespective of the coding language.

not to mention that fact that there are more apps available these days
and everybody wants 'em. i've forgotten more apps that i have installed
than i remember.

Secondly, for 99.99% of applications memory and speed is simply not an
issue. There are millions of MS VC programmers out there, not embedded,
500Mhz real-time ones. Sure, there are applications that are quite
thrifty, but one has to move with the times.

yeah. i learned to get out of that fossil mentality long ago. RAD is
where it's at.

A good programmer writes good code. It doesn't matter much what
language he uses.

Thats right.

C++ allows ALL of C's dirty tricks, and more.


I disagree. Its quite the opposite. C++ type checking is designed
specifically to stop you doing this.

good point. i wasn't sure what he meant by "dirty tricks."

mike

C is a complete nightmare. It lets
you do anything. For example, its difficult to set a pointer to one
function type to another in C++. The compiler wont let you do it
directly. The reality is, if the the code compiles, it usually works. I
have done a lot of work in both c and c++, an its a no brainer, c++ is
the only way to go.

Kevin Aylward
salesEXTRACT@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.

 

[Active8]

In article <MPG.19d1a0833ac22c4f989857@news.east.earthlink.net>,
mcolasono@earthlink.net.invalid says...

In article <K4F9b.1483$065.1059191@news1.news.adelphia.net>,
j.michael.elliottAT@REMOVETHEOBVIOUSadelphiaDOT.net says...

Active8 wrote:

i sometimes look for Kevin/Mike exchanges in the thread view just to
break the monotony this one wasn't very good. the flame level
just wasn't there. they're slacking.

but that brings up something i've been thinking of lately.
considering that the PSpice documentation raises more questions than
it answers... that the docs are nearly useless...

i was thinking it may have been easier to just use SS and LTSpice for
sims. you know, generate a netlist from SS where at least the
capture part is a no brainer. at least creating parts should be
easier than it is in LTSpice. drop the netlist in LTSpice and probe
the output in SS.

can you imagine the shit that could get started between those two
when i start hammering them both with questions? ^2

Oh, that would be good. That would be very good. Sort of the cyber
equivalent of tossing two cats in a bag, but without the cruelty, since
any damage would be self-inflicted by two humans who, unlike cats, have
choice in the matter.

I like the way you think.

ok. get your boss(es) to pull out the stops on the funding for that code
you want me to write. i can't even remember what it was you wanted to
add.

sorry. elliot and englehardt are two different names and i wasn't paying
attention.

mike

Start selling the tickets

state fair's in town next week. i'll see if i can get a vendor or the
ticket office to take a few tens of thousands on consignment. they can
ask the demolition derby customers, "Will you be liking to enjoy a tasty
flame war with your front row seats, sir?" I could sell anything at this
fair. but the ink jet refill gal's got to go. she's such a fraud.

brs,
mike


i've saved as many of helmut's LTSpice answers as i came across, just
in case. he's put out some good help for creating new parts. maybe
Linear should put him on the payroll.


Helmut's stuff is top-notch.

MikeE

 

[Tom Loredo]

Kevin Aylward wrote:

he codes:

for(;{
}

I know. Its dreadful.

As long as you indent properly, I fail to see why it's dreadful. The big
open source projects that adopt this convention also adopt good indentation
conventions that essentially make the braces superfluous in any case.

But I'm probably biased about this. Although I code regularly in C and
other languages, my main language nowadays is Python. Python recognizes
both the importance of readability and the superfluidity of block delimiters
when you properly indent, so there are NO block delimiters---the indentation
does it! This essentially forces the entire community to write similar
looking code, which aids code understanding and reuse. And getting more
code to fit in one screen definitely *is* a practical advantage of this, IMO.

FWIW, NASA is investing a lot in Python's scientific computation capability;
it's the main language currently being used for internal software development
at the Space Telescope Science Institute. I wouldn't write a SPICE engine
in Python, so I'm not advocating that! But Python sure might be handy for
"steering" an engine written in C....

Cheers,
Tom

 

[Chuck Harris]

Simple to try Kevin, write yourself the following function
in C:

#include <stdio.h>
int main()
{
printf("Hello World!!!\n");
}

and

then in C++:

#include <iostream.h>
int main()
{
cout << "Hello World!!!\n";
}


in linux, you will find for the "C" version:

-rwxrwxr-x 1 chuck chuck 11542 Sep 20 09:26 a.out

and for the "C++" version:

-rwxrwxr-x 1 chuck chuck 13017 Sep 20 09:29 a.out

And that is just a stupid simple little program that everyone has
to try sometime.

If you try it with microsoft's compilers, you will see the same ratio
of size difference, only about 5x so. Eg. 50-60K


Write anything you want, anything at all, and the C++ version will
be much larger than the C version. The difference between the C and
the C++ version will really grow with any increase in complexity. It
REALLY grows if you start to let C++ do some of its fancy multiple
inheritance stuff. Or late bindings.

Speed reduction of C++ over C is similarily large.

Sure, feature creap is responsible for some of the gross sizes of
modern software, but the language and the bloat it incourages is more
responsible.

As to the dirty tricks, C has had all of the same type checking and
template mechanisms as C++ for the last 15 years. ANSI C added them
back in the '80s. You can still run dirty if you want to, just as
you can in C++. There are compiler flags in each language to turn
of the warnings.

-Chuck



Kevin Aylward wrote:

Chuck Harris wrote:


It is the primary reason that
people need 160GB hard disks, and 1Gb of ram on their computers.


Don't be bloody daft. You don't really believe that do you? The reason
one needs large memory is because applications have gotten larger and do
more, ie. more features, irrespective of the coding language.

Secondly, for 99.99% of applications memory and speed is simply not an
issue. There are millions of MS VC programmers out there, not embedded,
500Mhz real-time ones. Sure, there are applications that are quite
thrifty, but one has to move with the times.


A good programmer writes good code. It doesn't matter much what
language he uses.


Thats right.


C++ allows ALL of C's dirty tricks, and more.


I disagree. Its quite the opposite. C++ type checking is designed
specifically to stop you doing this. C is a complete nightmare. It lets
you do anything. For example, its difficult to set a pointer to one
function type to another in C++. The compiler wont let you do it
directly. The reality is, if the the code compiles, it usually works. I
have done a lot of work in both c and c++, an its a no brainer, c++ is
the only way to go.

Kevin Aylward
salesEXTRACT@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.

 

[Kevin Aylward]

Chuck Harris wrote:

It is the primary reason that
people need 160GB hard disks, and 1Gb of ram on their computers.


Don't be bloody daft. You don't really believe that do you? The
reason one needs large memory is because applications have gotten
larger and do more, ie. more features, irrespective of the coding
language.

Secondly, for 99.99% of applications memory and speed is simply not
an issue. There are millions of MS VC programmers out there, not
embedded, 500Mhz real-time ones. Sure, there are applications that
are quite thrifty, but one has to move with the times.


A good programmer writes good code. It doesn't matter much what
language he uses.


Thats right.


C++ allows ALL of C's dirty tricks, and more.


I disagree. Its quite the opposite. C++ type checking is designed
specifically to stop you doing this. C is a complete nightmare. It
lets you do anything. For example, its difficult to set a pointer to
one function type to another in C++. The compiler wont let you do it
directly. The reality is, if the the code compiles, it usually
works. I have done a lot of work in both c and c++, an its a no
brainer, c++ is the only way to go.


Simple to try Kevin, write yourself the following function
in C:

#include <stdio.h
int main()
{
printf("Hello World!!!\n");
}

and

then in C++:

#include <iostream.h
int main()
{
cout << "Hello World!!!\n";
}


in linux, you will find for the "C" version:

-rwxrwxr-x 1 chuck chuck 11542 Sep 20 09:26 a.out

and for the "C++" version:

-rwxrwxr-x 1 chuck chuck 13017 Sep 20 09:29 a.out

And that is just a stupid simple little program that everyone has
to try sometime.

You miss the point. I dont care about a 12% memory increase. Its zero,
to an engineering approximation, in 1000000's of real applications.

If you try it with microsoft's compilers, you will see the same ratio
of size difference, only about 5x so. Eg. 50-60K

There is more to it than this. This is not an AB test. There are various
issues involved here. For example, there is an initial overhead. A 3
line "hello world" windows app on its own could be 100k. However, once
you add 100k+ lines it might still be only 3Meg.

Many application, e.g spice, simply allocate large arrays for data. Any
C++ overhead is insignificant in these cases. e.g. I have CArrays, and
allocate 100k chunks, overhead is minuscule.

Write anything you want, anything at all, and the C++ version will
be much larger than the C version.

Nope. It depends on the program, and it practice, not significant in
engineering terms. i.e. return on investment.

The difference between the C and

the C++ version will really grow with any increase in complexity. It
REALLY grows if you start to let C++ do some of its fancy multiple
inheritance stuff.

Never use this feature. Probably, few do.

Or late bindings.

Well, I'm only a hack, so I will have to look this one up. Do you mean
runtime resolutions as in dll's?

Speed reduction of C++ over C is similarily large.

It can't be. C++ includes C as a subset. You just access a pointer to do
data contained in classes.

Sure, feature creap is responsible for some of the gross sizes of
modern software, but the language and the bloat it incourages is more
responsible.

No chance, in my opinion. As soon as you start allocating chunks of
memory for data, that memory dominates. Imo, C++ allows one to write
bigger programs, more reliable/easier, so by default, bigger programs
might well use c++


Kevin Aylward
salesEXTRACT@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.

 

[Active8]

[snip]

Never use this feature. Probably, few do.

Or late bindings.

Well, I'm only a hack, so I will have to look this one up. Do you mean
runtime resolutions as in dll's?

sort of. in VB it has to do with how you declare/invoke a COM (ActiveX)
object.

in VB it would be (note: ' in VB is // in C/C++

Public crap as Object

' that would reguire late binding because we don't know what needs to be
' instanciated, yet. so then you'd do (VB auto caps keywords but i'll
'abbrev)

if condition
Set crap = New MyControl ' IIRC
else
set crap = new HerControl
end if

for early binding, you declare the exact object and it will be
instanciated at runtime thus using memory regardless of whether the
control ever gets used.

Public crap as ADODC.Recordset

or maybe it's

Public crap as new ADODC.Recordset

in C++ it's the same thing but different. i use skeletons i wrote for
DCOM and ActveX (in ATL) and i can't access my bio-memory for the
nuances to explain it effectively, but you'd know about it if you used
it and you know where to find the info if you get the urge to do it.

brs,
mike

Speed reduction of C++ over C is similarily large.

It can't be. C++ includes C as a subset. You just access a pointer to do
data contained in classes.


Sure, feature creap is responsible for some of the gross sizes of
modern software, but the language and the bloat it incourages is more
responsible.

No chance, in my opinion. As soon as you start allocating chunks of
memory for data, that memory dominates. Imo, C++ allows one to write
bigger programs, more reliable/easier, so by default, bigger programs
might well use c++


Kevin Aylward
salesEXTRACT@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.