Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Various Data Types Within An Array

Status
Not open for further replies.

prager

Programmer
Jul 14, 2000
5
US
Coming from Clipper to Visual C++. Clipper was written in C, possibly C++ not sure. Anyhow, within Clipper it's possible to store any and all data types including mixing those data types in the elements of a single array. How is that done in C++. As far as I can see it seems it's not possible. Could this be?

Thanks in advance for your assistance.
 
C++ is a type-safe language, so it's not possible.
Why would you want to do that anyways?
 
Possibilities

1) Create an array of void* where every member points to something of a different type

2) Create an array of unions of the types you wish to store

3) Use a structure/class. The old fashioned way when structures did not exist was to have array members pointing to all sorts of stuff.
 
or create a base class that all other types you're using are derived from, then store (smart) pointers to the base class.
But I have a strong feeling that if we knew what you're planning to use this array for, we could find a better solution.
 
Hey cpjust,

<< But I have a strong feeling that if we knew what you're planning to use this array for, we could find a better solution. >>

After thinking about it I came to the same conclusion. In our app we deal with large dynamic arrays incorporating many data types including elements containing multi-dem arrays to the 5th level.

Problem is, is that when I think about it my head starts to smoke!

Thanks for your input.

 
Are they primitive data types (i.e. int, char, float...) or are they structs & classes?
Could/should they be contained in a class?

I don't know what the data represents, but here's an example: If you're storing contact info, you might have char* strings for names, addresses... and ints for age, record id...
Instead of storing that data in one big array, you should create a struct and store those in the array.
Code:
struct Contact
{
   int  RecordID;
   char Name[50];
   char Address[50];
   int  Age;
 ...
};

std::vector<Contact>  contactArray;
 
If it is Clipper - that is basically DB2, which, in MS lingo is Foxpro. Why not try Foxpro - you may not have to write any code at all.
 
Hey xwb,

I'm so darn tired of learning new languages (I thought Clipper would be the last) that I could just .... Anyhow, I decided to just dive in and rewrite the app (about 250,000 lines of code in Clipper) in C++ assuming C++ will be around for a while. I looked at all the alternatives that would get Clipper to a Windows program but they all were just; a font end bluff. xHarbour, Five Win, etc.

 
Clipper is basically a database language. The variant types will be used in tables so that will be a structure of some sort. The clipper apps are huge because most of the code is just moving data from the forms to the tables and from the tables to the reports. It was SQL in its infancy when not many people knew it. If you look at SQL now, it is so much neater.

It also has some kind of B-tree index mechanism which made it really fast for DOS when used with random records. Only problem is that many users did not use it properly. In a simple minded way, the database is just an array of structures.

To convert it, you need to work out

1) all the tables
2) all the queries
3) all the input forms
4) all the output records

So as not to reinvent the wheel, get a database package, something like sqlite (source code in C). This will do the tables for you. The queries can be translated to SQL. Clipper's SQL wasn't quite there so there will be some minor mods. All you need to do is the forms and reports. It will be a lot simpler than rewriting a whole clipper app.

Clipper checks for uniqueness during insertion. You could do that with a STL map or MFC map (MFC is faster) if you do not wish to follow the SQLite route.

I went through a similar exercise in 1992. Pity SQLite didn't exist then.

 
Forgot to add - Clipper also has views. Most of the time these are just the same tables with fewer columns so just the table and don't bother with the views.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top