> _However_, using C++ is the "worst" way to write typical "business > application" programs -- at least at this point in time. > There are now two good reasons to use C++; one is to write > "highly optimized" code which uses pointer manipulations, ... > the other is to write for a platform which _only_ supports C++
I'm in the second boat. We do hardware design. The hardware is designed in verilog and verilog-ams. These two languages describe the digital and analog pieces of the chip respectively. To simulate this stuff, you use basically one of two possible tools: one by cadence, the other by synopsys. And if you're heavy in the Verilog-AMS, then you can really only use cadence. Up until recently, all verification was written in verilog. Verilog is an OK language for digital design but a lousy language for verification. It doesn't support anything resembling a pointer or reference. Everything is passed by value. There is nothing in verilog that is intrinsically an object oriented language. Verilog essentially looks like basic C, with some of the capabilities (like pointers) chopped out. A few years ago, the problems with verilog as a verification language became a problem in delivering designs on time. When chips were small, a small, simple testbench was OK. As chips grew, the problems with a dumb language slowed things down. System-Verilog was invented as a language addition which is intended for simulation/verification, not for the hardware design. It has object-oriented concepts, you can create instances of classes. It has pointers. System verilog is more akin to a specialized flavor of C++ or something like that. But this is also not without its problems. Relatively recently, simulators started putting hooks in place so that you could pull in code in from another language and use that instead. This is done through an interface called DPI. Currently, the two main simulator companies support DPI for "C" only. When you cross the boundary from verilog/system verilog to DPI the language you can jump into is "C". After you get into "C", you can expand into c++. The interface files the cross the boundary have to be C, but this can tie into C++ if you want. So, I've been doing verilog testbenches for years, system verilog test benches for years, and they all have their limtations as not being what I would call a "real" language. So, I'm trying to write a testbench in C++, interface it with "C", use that to jump the DPI barrier to verilog, and tie into the hardware simulation. So, I'm limited to c/c++ because we're tied to hardware simulators which can only run hardware languages such as verilog/vhdl and can only interface to one software language, namely c, which can then tie into c++. That is, at the moment, my only option for any testbench that isn't written in verilog or vhdl. The simulator limits me to c and c++. Greg _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
