Choosing the right STL structure

Any thoughts welcome.

I have to rewrite an old C prog using C++. Thoughts by colleagues are that C++ is not as productive as C so this is a type of evaluation exercise.

The prog is batch (console), reads response time test results from a text file and then outputs response time statistics (percentiles, timeline, SD, averages, etc).

So I have:

a) A test
b) Many transaction scripts (complete business processes)
c) Many events within scripts (timing points)
d)Many response times for each event (between a few hundred and tens of thousands).

The input is structured and thus cannot be presorted.

So I have created a class for the individual events (a,b and c above): testname, scriptname, event name, eventid, description fields. The eventid is a combined char key (testname_scriptname_event name) and is thus unique. This class represents a,b and c above.

Each eventid of course has many timings.

Example eventid 'aaa066_001_A0' where testname='aaa066', scriptname = '001', and event name = 'A0'.

And a MMAP : char eventid, double responsetime. Example: 'aaa006_001_A0', 2.53
And a MMAP : double timeofresponse, double responsetime. Example: 122052054424.398499, 2.53

I need to sort the MMAP and then read it start to finish to formulate the statistics. I do not need to insert, delete or update the MMAPs beyond append to end as they are created.

Question : Is the MMAP the best STL class to use?

Thanks for looking

Quote:

---

Thoughts by colleagues are that C++ is not as productive as C so this is a type of evaluation exercise.

---

LOL. This can qualify for the joke of the week.

I never heard of MMAP before. There is not such class in STL. Did you mean std::map? That is something different. The map is a hash table. It's useful for quick access to elements. You don't sort the map. It's automatically sorted. But you can't have multiple values with the same key. If you need that use a std::list and std::sort() to sort it.

Quote:

---

Originally Posted by cilu

LOL. This can qualify for the joke of the week..

---

well I'm fighting the C++ corner even though I only picked up the manual 10 days ago.

Quote:

---

Originally Posted by cilu

I never heard of MMAP before. There is not such class in STL. Did you mean std::map? That is something different. The map is a hash table. It's useful for quick access to elements. You don't sort the map. It's automatically sorted. But you can't have multiple values with the same key. If you need that use a std::list and std::sort() to sort it.

---

Sorry I thought MAP and MMAP were good references (commonly used in typedefs) but pls forgive, I'm a beginner.

Indeed by MAP I meant std::map and by MMAP I meant std::multimap. According to the manual multimap allows duplicate keys while MAP does not.

But if they are presorted by way of a tree all well and good. Just hope I don't get a whopping performance hit.

But are there any other STLs I should consider? From my reading of the manual I don't see any but I'm a bit short of complex examples. Don't want to start and then get C++ kicked into touch because I chose the wrong data structure.

Quote:

---

Originally Posted by nigelhoath

Any thoughts welcome.

I have to rewrite an old C prog using C++. Thoughts by colleagues are that C++ is not as productive as C so this is a type of evaluation exercise.

---

Have your colleagues evaluate this:

Code:

---

#include <string>
#include <iostream>

int main()
{
  std::string s;
  cout << "Enter your name: ";
  cin >> s;
  cout << "\n" << s;
}

---

Write the equivalent program in C. While they waste time coding everything, I wrote this program in under 30 seconds.

Second, it is not fair that you do not know C++ enough to evaluate things for other people who do not know the language. You can make a total mess of a C++ program if you do not have the experience in it. You can turn something that should take no time into something very inefficient very easily.

Only an intermediate to expert C++ programmer can truly determine if and how to make a C++ program efficient. Beginner programmers tend to make too many mistakes (passing things by value, not using the proper standard algorithms, etc.).

As far as map goes, a std::map has logarithmic search time. If you have 1,000,000 items in the tree, it should take 20 or less probes into the tree to find the item.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by cilu

Did you mean std::map? That is something different. The map is a hash table. It's useful for quick access to elements. You don't sort the map. It's automatically sorted. But you can't have multiple values with the same key. If you need that use a std::list and std::sort() to sort it.

---

The std::map is a red-black tree, not a hash table. That's *why* it's sorted. std::tr1::unordered_map is the hash table.

Also, std::multimap is a better solution to the multiple-keys problem.

Thanks guys for the comments.

Paul: With regard to productivity that is a big subject and I think you would agree has little to do with a non realistic small code sample comparison (but your example is fun and I might do some bear baiting with it). If I was going to pick one measurement it would be bugs per 1000 lines of code - but another thread, another day.

I note in general C++ is noted for the large size in terms of functionality (and thus you could say flexibility). I personally have a lot of OO experience and naturally lean that way, Thus my desire to seriously consider C++, or certainly invest some time evaluating it.

Being open systems driven I can rule out C#. Certainly Java will be, and is, part of our plans.

So for now I will push on with multimap, and if time permits plug in some alternatives, espcially if performance is an issue.

Quote:

---

Originally Posted by nigelhoath

With regard to productivity that is a big subject and I think you would agree has little to do with a non realistic small code sample comparison

---

I'd say that the point is that the C++ standard library offers more than the C standard library, and related libraries like Boost and POCO save you the effort of having to develop sets of basic (and sometimes not so basic) and portable components.

Quote:

---

With regard to productivity that is a big subject and I think you would agree has little to do with a non realistic small code sample comparison (but your example is fun and I might do some bear baiting with it).

---

His example is small, but it illustrates a very code point. With C++ you have fairly massive amounts of reliable and heavily tested code in the STL and boost. To get the same kinds of functionality in C, you're going to have to invest huge amounts of time writing and testing your own code to do the same things (even if you already happen to have that code, you had to invest in creating it at some point in the past). String operations are one small example, but then you have all of the containers in the STL, all of the algorithms... and then there's the huge mass of stuff in boost.

Quote:

---

Originally Posted by nigelhoath

Thoughts by colleagues are that C++ is not as productive as C so this is a type of evaluation exercise.

---

This is the most unfounded statement I have seen in a very long time.:ehh: With all due respect, where is their evidence for this?:confused: I would be very interested in an example where writing in C is more productive than writing the equivalent in C++!

Quote:

---

Originally Posted by nigelhoath

If I was going to pick one measurement it would be bugs per 1000 lines of code - but another thread, another day.

---

But the point is, that, if you gave a programmer who was equally proficient in C and C++ a program to write, where as they might need 1000 lines to write something in C, the same functionality in C++ would only require a fraction of the number of lines. Less lines means less possibility for errors, more readability, and less time debugging (should errors occur) because it is easier to see when something is wrong. In addition, because C++ is a typesafe language, the compiler is far more likely to pick up coding errors at compile time than a C compiler would for a C program. This again inavoidably means less errors get past the compiler per 1000 lines of code, which leads to more reliable code. Added to this the RAII idiom used by many resource handling classes in C++ leads to safe acquision and dispatch of resources - this again means less error prone code.

As far as I see it (and I have yet to be proved wrong), for a proficient programmer, C++ is almost inavoidably more productive.

Quote:

---

Originally Posted by nigelhoath

Thanks guys for the comments.

Paul: With regard to productivity that is a big subject and I think you would agree has little to do with a non realistic small code sample comparison

---

That's the whole point -- how small the code is, and it is realistic if you look at the big picture. To do this very simple thing in 'C', you have to introduce a way to dynamically size a char buffer, making sure it has room for input. Then you have to check if the memory allocation failed. Then you have to clean up, etc. etc. A rank beginner can do it on their first or second try. To do this in 'C', even experts could get it wrong the first time.

Also, that small code example is just a microcosm of the difference between coding in C++ using the proper standard components, and coding in straight 'C'.

Quote:

---

(but your example is fun and I might do some bear baiting with it). If I was going to pick one measurement it would be bugs per 1000 lines of code - but another thread, another day.

---

I would dare say that using the proper standard components, the bugs are far less in C++ than in 'C'.

Do the 'C' programmers protect every single usage of things such as strcpy(), strcmp(), memcpy(), etc. that may overflow a buffer? If not, that is a bug. A C++ programmer using the proper classes need not worry about this. Even Stroustrup, the author of the C++ language, designed it so that the coder produces less bugs than a traditional 'C' programmer.

I am not saying you can't have bugs in a C++, that would be ridiculous. But I can tell you that more often than not. if given an application to develop and you have an expert C programmer vs. an expert C++ programmer, and both programmers must start out using only what's available in the language and language library, the C++ programmer would not only be finished faster, the code (in terms of lines of code) would be smaller, and there would be less bugs.

For example, while the 'C' programmer is trying to code a linked list to store customer data, the C++ programmer does this:

Code:

---

#include <list>

struct CustomerData
{
  char name[30];
  //... whatever else
};
std::list<CustomerData> CustomerList;

---

Finished. Not only that, this code is guaranteed to be portable to any compliant ANSI C++ compiler, so it isn't a home-made class (as the 'C' coder would have to resort to). While the C++ programmer is moving on to bigger and better things in developing the application, the C coder is still writing and debugging to make sure the head node is not NULL, the data inserted is inserted in the right place, etc.

Quote:

---

I note in general C++ is noted for the large size in terms of functionality (and thus you could say flexibility). I personally have a lot of OO experience and naturally lean that way,

---

You don't need to use any object-oriented programming in C++. There are other paradigms, such as policy-based programming using templates.

Regards,

Paul McKenzie

Paul very well stated and hopefully you won't mind if I use your words on my colleagues.

"You don't need to use any object-oriented programming in C++. There are other paradigms"

This I think is interesting. I have heard C programmers inferring OO is a must but from what I see I could well write any C program in C++ with little alteration.

In defence of the C programmers I know they rarely if ever write a C prog from scratch. Code reusability in our field is the way. That said as automation testers we see a lot of test environments that differ little from one to another. Especially in terms of network protocols, the thing we script and reproduce. It is largely a matter of find a test driver that is similar and if necessary make some minor changes.


Well many thanks Paul and et al. I'll let you know if I win the day.

Quote:

---

Originally Posted by nigelhoath

"You don't need to use any object-oriented programming in C++. There are other paradigms"

This I think is interesting. I have heard C programmers inferring OO is a must but from what I see I could well write any C program in C++ with little alteration.

---

You could do that, but the issues that I see is the eventual creeping in of C++ constructs into a program that started out as 'C'. This often leads to buggy programs, since C++ has object types that you cannot reliably use 'C' coding on.

To be more explicit, 'C' has only one category of data types called POD (Plain-Old-Data) types, while C++ supports POD and non-POD types. It's the non-POD types that trip up C programmers attempting C++ code. Things such as calling memcpy(), memset(), malloc() when using non-POD types is potentially fatal in a C++ program.

So I would recommend not trying to code a mixture of C and C++ programming techniques in the same application unless you know exactly what you're doing (usually this can be accomplished by a person experienced in both C and C++. The opinion of many is that no matter the experience you have in 'C', you are not an experienced C++ programmer because C++ looks like 'C').

What I mean by not having to use object-oriented methods, there is a paradigm in C++ called policy-based programming, where there is little, if any use of object-oriented programming (i.e. usage of virtual functions, polymorphism, etc.). To properly exploit this, you have to be an experienced and close to expert C++ programmer. It isn't for the beginner C++ programmer. Here is a link:

http://en.wikipedia.org/wiki/Policy_based_programming

Note that even the Standard Template Library uses very little, if any object-oriented techniques. None of the STL containers are designed to be used in an OO style (lack of virtual destructor is the dead-giveaway). I've read that the inventor of STL was against any usage of the containers as "base classes" to be derived from.

Regards,

Paul McKenzie

While I don't completely follow the above, I'd say that the most useful attribute of C++ over C (besides the STL, of course) is the class destructor. This is the very basis of the RAII concept, and makes for a very powerful tool when it comes to cleanup.

Anything that can be done in C with functions like

Code:

---

something_open();

....
something_close();

---

or whatnot, you have to be careful to actually close everything that gets opened no matter what control path is taken----and moreover, to only do so once. It can be tricky. But with C++ you can design a simple class with

Code:

---

class SomethingObject
{
    SomethingObject()
    { something_open(); }
    ~SomethingObject()
    { something_close(); }
};

---

and then all you have to do is place one of these on the stack when you need it, and there is no possibility of failing to clean up or doing so multiple times----it's all done for you.

This isn't object-oriented programming in the usual sense, but it does leverage the power of objects quite effectively.