Re: [Boston.pm] C++ books
Greg London writes: I would like a book that introduces c and c++ from the point of view of showing the best practices first and comp-sci theory gets put in the second edition so I don't have to buy it. I would highly recommend 'The Design and Evolution of C++' by Stroustrup. It's an older book now, but still was written with a great deal of perspective on the use of C++ and does a good job of explaining why many things are the way they are -- which of those things are for the best and which are not. Probably better value, and with much more perspective, you could pick up 'Handbook of Programming Languages Vol I', which is the one covering C++. This is an excellent tome that covers the design of C++ in even more detail and includes more specific material about right-ways wrong-ways to do things. It also covers other languages and is a great collection of such writing. While I can understand a (apparent) desire to avoid Comp Sci basics, I recommend always looking at the history of the design of a language -- or at least the design of that language -- in order to understand how to use it effectively. For example, unless I'm missing something fundamental, I don't see any reason to have parameters to a c++ function ever be a pointer. If I need an in/out, I pass by reference. You might want to move that pointer without declaring yet another variable asking the compiler to figure out another register mapping. That is, change the address the pointer itself contains. There's also the various and many flavors of a sequence of characters in c++. You could have an array of chars, a pointer to an array of chars, a std::string, a sstream, and I'll be DAMNED if c++ isn't designed so that not one of them will work in every situation. Yes, of course. This is much like how the C programmer on a UNIX system has a choice between using FILE handles or file descriptors -- neither is able to do everything the other does, and there are important reasons for that, even though one is implemented using the other -- each represents a set of tradeoffs and the more complicated FILE structure imposes certain burdens on the programmer. Similarly, std::string is a great way to get a very friendly interface to string data, but that friendliness is built upon certain requirements in terms of data content and access patterns. So, really, if the way to move text around is with strings then I'd like a book that starts out introducing strings and then later on, when some stupid exception to the rule comes up, it goes into char* or streams and explains the difference at that point. That was the sort of book I was looking for. Probably doesn't exist because no one will agree on the best way to pass strings around in c++. Using std::string is the best way to handle most strings most of the time -- for typical business application programming. _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, direct memory management, and other such techniques to produce fast code -- which one should then be calling from a more flexible and convenient language, such as Java or Perl; the other is to write for a platform which _only_ supports C++ (or C and C++), such as an embedded controller for some archaic hardware system -- in which case one is unlikely to be writing a typical business application. _So_, the best way to use C++ strings is only the best way when you're writing code which is the least appropriate code to use C++ to write. YMMV. ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] C++ books
_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 Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] C++ books
On Mon, Apr 15, 2013 at 11:09 AM, Greg London em...@greglondon.com wrote: [...] 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++. I'm writing some C++ at the moment that fits into the first group (performance-critical code). For unit testing I've been emitting TAP protocol and testing it with prove, but are there better approaches? I get a test file with a lot of code that looks like this: printf( %s %d: Some useful description and maybe a number %d\n, (expected_value == test_value) ? ok : not ok, ++tests, some_useful_debugging_info ); I find it manageable, but I'm wondering about the next guy. ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] C++ books
I get a test file with a lot of code that looks like this:
printf(
%s %d: Some useful description and maybe a number %d\n,
(expected_value == test_value) ? ok : not ok, ++tests,
some_useful_debugging_info
);
I find it manageable, but I'm wondering about the next guy.
I've coded up a library of c++ functions for my infrastructure:
void increment_error_count(){
err_cnt++;
if(err_cnt10){
exit 1;
}
}
void error(string desc){
increment_error_count();
cout ERROR: desc endl;
}
void pass(string desc){
increment_pass_count();
cout pass : desc endl;
}
void expected_actual(
int expected;
int actual;
string desc
){
cout expected expected, actual=actualendl;
if(expected==actual){
pass(desc);
}else{
error(desc);
}
}
Then in the test, your code:
printf(
%s %d: Some useful description and maybe a number %d\n,
(expected_value == test_value) ? ok : not ok, ++tests,
some_useful_debugging_info
);
would look something like this:
expected_actual(expected_value ,test_value, some useful description);
We have a number of actual_expected functions to handle diferent types and
range checking and what not. They all print out the actual and expected
values, so you don't have to do that formatting in the test call.
cause usually if there is a failure, the very next thing we need to know
is the actual value we got versus the expected value we wanted.
The error logging will stop after some number of errors occurs, so you're
not wasting sim time.
Each test ends by doing an end-of-test-report which prints out pass count
and error count and prints out and overall-result string. the perl script
scrapes this value and puts it in a report.
We have hundreds and hundreds of tests. so the goal is to keep the
tests as absolutely short as possible.
___
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] C++ books
Ben Tilly bti...@gmail.com writes: ... I'm writing some C++ at the moment that fits into the first group (performance-critical code). For unit testing I've been emitting TAP protocol and testing it with prove, but are there better approaches? I get a test file with a lot of code that looks like this: printf( %s %d: Some useful description and maybe a number %d\n, (expected_value == test_value) ? ok : not ok, ++tests, some_useful_debugging_info ); I find it manageable, but I'm wondering about the next guy. I've used Aeryn (which has disappeared from the Internet?) http://web.archive.org/web/20090322042351/http://aeryn.tigris.org/ and Boost test http://www.boost.org/doc/libs/1_38_0/libs/test/doc/html/index.html I dunno, they served their purpose, but what can you say about a unit test framework? It helps you run your code and check your values. Big deal. I don't feel like I was very much farther ahead (and in some ways behind because I deal now from outside with code that tells me (forcefully with real walls thrown up) it's private or doesn't export its interface from a dll, and I'd like to test more than the public interface sometimes though some claim that's stupid) from when I used to put #ifdefed out main functions in every file to check what's in that file completely manually. Both these frameworks were harder to get going than Test::Less and Test::More, but not dramatically so. I don't think either supports TAP output. I've heard that many people use Google's unit test framework. ACCU periodically has an article in their journals surveying test frameworks. The names of the frameworks seem to change every couple years. Writing a unit test framework maybe is like the C++ programmer equivalent of what writing an mp3 player is for gtk and qt programmers? Here's an article from 2007 that mentions the ones I mention in this email: http://accu.org/index.php/journals/1326 If you scout around more, maybe you can find newer recommendations. Probably stackoverflow would be a good place to look. If I were looking today, maybe I'd look at Cute, especially if people around me were using eclipse. Its author has an article about it here: http://accu.org/var/uploads/journals/Overload75.pdf This maybe is a better, more up to date guide to get the gist of it: http://cute-test.com/projects/cute/wiki/Writing_and_Running_CUTE_Unit_Test_Suites - Mike ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] C++ books
I would highly recommend 'The Design and Evolution of C++' by Stroustrup. It's an older book now, but still was written with a great deal of perspective on the use of C++ and does a good job of explaining why many things are the way they are -- which of those things are for the best and which are not. In my opinion, Stroustrup's book is a must-read for anybody interested in computer language design. It's a shining example of something that has rarely been attempted: explaining WHY a language works the way it does. You may come out of reading it with a new appreciation of C++ or with a new hatred of his boneheaded design priorities (or perhaps some of each as I did), but either way you will know a lot more about the kinds of tradeoffs one must make when designing a language. If you just want to learn to program in C++, Stroustrup may not be the best use of your time. ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
