C++ and data access

[SelArom]

hi, I have been trying to get into C++ for a while now. My background is in VB.net. I do have experience programming with C++ (and some C) through my classes, but nothing complex... the biggest thing that I seem to be having trouble comprehending is how data access is handled.

the main aspect is developing applications that are data-driven. see .net makes it easy to connect to different data sources like databases, access files, and xml files. but whenever I look in C++ books they always talk about using the STL like lists, stacks, and other structures. But is that really the way you're supposed to do it? Am I supposed to load an ENTIRE data set into memory then pull out the data that I need from there? I've seen some mention of working with records, but that seems clunky and inefficient...

so I guess what I'm asking is, what are some of the different ways that serious application developers store and access data when they are working in C++? and by serious, I don't necessarily mean like Microsoft Windows devs... rather I mean just not the simple little rinky dinky programs that are in textbooks. like maybe just someone who wants to say write a program to keep logs of notes or structured collections like bills or something like that, or maybe as complex as an email system, but without having to rely on a rdbms...

thanks in advance for your insight
-SelArom

[thekashyap]

It depends on the data, but simplest answer would be an SQL database.
Most/all DBs provide C/C++ APIs for access.

You guessed correctly abt STL, its a set of template classes created to make life easier for a programmer, and NOT for the purpose to providing a way storing/accessing huge amount of data persistently.

[SelArom]

thank you for your reply. that is what I figured... but if the solution is to use a database system of some sort, what advantage is there to using c++ over say one of the new .net languages? since the bottleneck is the database and not memory, why would I develop the application in c++? (this isn't intended to be sarcastic, I really want to learn more about why people still use c++ to develop applications)

thanks
-SelArom

[Narue]

>see .net makes it easy to connect to different data sources like
>databases, access files, and xml files.
This is true.

>but whenever I look in C++ books they always talk about using the STL
>like lists, stacks, and other structures.
That's because those books teach standard C++ and can't reasonably cover such things as database access and XML processing. :icon_rolleyes:

[thekashyap]

why would I develop the application in c++?

For the love of it.. :)

First, when you're developing something using .NET or MFC or J2XX or some such framework, the design of their application is [to some extent] limited. If the designer is not too experienced I would say it's limited to a large extent. In C++ on the other hand you have a free hand at that.
Secondly from my own experience I'll say this: Framework (MFC, J2XX...) based applications are bound to be slower than the ones written without them (C/C++, Core Java) as the a developer of framework has to consider a larger group of clients than the developer of a single application. Thus the developer of a single application will surely design something that's more fitting to his/her requirements.
Third reason is there are no frameworks for business logic part of applications, say if you're developing an application that connects a stock broker to a stock exchange and provides for all trading facilities, you'll have frameworks (e.g. .NET) that can make life easier to create a GUI and access to DB, but it can't provide you any help in implementing the rules/regulations of stock trading, so this has to be done in C++/Java/...
A word on STL, it's meant only for aiding in implementing your business logic. Take teh previous example, once you've read teh data from DB you need to make some decisions based on that by correlating them and applying some rules, to hold this data in memory and manipulate it you'll use STL.
Finally IMHO .NET is meant for interoperability of different languages/technologies. And that's what it should be used for.

[~s.o.s~]

> Third reason is there are no frameworks for business logic part of applications

There is always J2EE. Business methods of the Entity bean having CMT (container managed transactions) are implemented by the container.

[thekashyap]

> Third reason is there are no frameworks for business logic part of applications

There is always J2EE. Business methods of the Entity bean having CMT (container managed transactions) are implemented by the container.

Thought someone might say that.. :).. Even in telecom domain we have frameworks (aka platforms) that provide basic services needed by telco applications, but same issue there as well.. I would still say that a guy designing on his own will do a better job (surely not as easily)..

[~s.o.s~]

Say that in a Java forum and you would get gobbled up by the supreme freaks who believe that the more things the container does, the better. In case you haven't worked with J2EE, in almost every scenario, CMT does a great job. The only times 'own designing' i.e. BMT is required is when fine grained control is required over transcations, a thing rarely needed is normal J2EE applications.