C++, 64 bit and mulithreads

Hello folks, I'm attempting to learn C++ and was wondering about a couple of things:

1.) 64 bit software - what is it in the code that makes it 64 bit? Does it mean, amongst other things, making integer variables to always be of type 'double' etc..?

2.) Multithreaded - from my reading so far on this all I can seem to find is that its a complex issue, but can anyone explain to me in the simplest possible terms what would make C++ code multithreaded? For example, how would you redesign the "Hello World" programme (if its at all possible) to be multithreaded?

I'm pretty much right at the beginning of my learning experience, so please bare with me if these are stupid questions.

Thanks.
 
tanked said:
what is it in the code that makes it 64 bit?
In the code itself, not a whole lot.

Some datatypes (most notably long and double) can hold larger values on a 64-bit system. But as a beginner you probably shouldn't worry about such details.

Also, once you start relying on specific sizes for these datatypes you're likely to run into all kinds of trouble when you try to compile the code on another computer. There are several applications in the ports tree that only compile on 32-bit machines and you'll have to go to great lengths trying to get them working on a 64-bit machine.

tanked said:
Multithreaded - from my reading so far on this all I can seem to find is that its a complex issue, but can anyone explain to me in the simplest possible terms what would make C++ code multithreaded? For example, how would you redesign the "Hello World" programme (if its at all possible) to be multithreaded?
Making "Hello World" multithreaded would only have (some) educational value, it serves no useful purpose. The idea of multithreaded programming is that you split a task into smaller tasks that can be performed independently and simultaneously.

In a way multithreaded programming can be compared to cooking a meal. The main task is cooking a meal, but there are parts that can be done simultaneously. When you've put a pan of water on the fire for the rice, instead of standing there waiting you could be cutting meat and vegetables in the meantime. Or even better: you rope in somebody else who cuts the veggies while you're cutting the meat and the water is on the fire getting ready.

The problems begin when these smaller tasks get together. You can't put the rice into the boiling water when the meat hasn't even been cut yet. And if there's only one good cutting knife you can't cut the meat when someone else is already cutting the veggies.

In short: doing things in parallel (which is basically what multithreading does) can be very efficient (it obviously saves time), but if you get the timing/synchronization wrong it can easily lead to disaster, either in the kitchen or in your computer.

I recommend that you start with "normal" C++ and save things like 64-bit and multithreading for later. It will then be easier for you to ask good questions and easier for us to explain the answers.

Hope this helps (a bit),

Fonz

P.S. As for the "Hello World" program: it only does one thing, so there's not a whole lot of "parallelization" to be done there.
 
tanked said:
1.) 64 bit software - what is it in the code that makes it 64 bit? Does it mean, amongst other things, making integer variables to always be of type 'double' etc..?
The main (only?) difference is that pointers are 64 bit. A double is a 64 bit floating point number (1 sign, 11 exponent, 52 mantissa bits) and has nothing to do with the 32/64 bit software problem (i.e. you can use doubles on 32 bit architecture). It is also no problem to perform 64 bit integer calculations on 32 bit systems (i.e. long int, or to be more specific int64_t).

2.) Multithreaded - from my reading so far on this all I can seem to find is that its a complex issue, but can anyone explain to me in the simplest possible terms what would make C++ code multithreaded? For example, how would you redesign the "Hello World" programme (if its at all possible) to be multithreaded?

Simple or complex depends on the algorithm, sometimes it is very simple, for example:
Code:
#include <iostream>
#include <omp.h>

using namespace std;

int main(int argc, char **argv) {
  const int numThreads = omp_get_num_procs();

#pragma omp parallel for
  for ( int i = 0; i < numThreads; i++ ) {
    const int ID = omp_get_thread_num();
    cout << "Hello World! I am thread " << ID << endl;
  }
  return 0;
}
On a quad core machine this:
$ g++ -o HelloWorld main.cpp -lgomp && ./HelloWorld
results in:
Code:
Hello World! I am thread 0
Hello World! I am thread 0
Hello World! I am thread 0
Hello World! I am thread 0
and this compile and execute command (note the extra compiler option -fopenmp):
$ g++ -fopenmp -o HelloWorld main.cpp -lgomp && ./HelloWorld
results in:
Code:
Hello World! I am thread 1
Hello World! I am thread 3
Hello World! I am thread 0
Hello World! I am thread 2

I'm pretty much right at the beginning of my learning experience, so please bare with me if these are stupid questions.

Thanks.
No problem, these are valid questions :). My example uses openmp to do the multi threading, it is basically a tool to make single threaded programs multi threaded. pthreads is another way to do multi threading in c++, it is more flexible but at the same time way more complicated than openmp. Search the internet for those keywords, you will find a lot of information and examples.
 
Thanks for all the replies chaps; my goal is to (way, way down the line) create a Windows database client that will connect to a Postgresql database, running on FreeBSD of course, that will be used to record the clock-in/clock-out times for our employees, as well as handle leave requests etc...

The only reason why I asked about multithreading and 64 bit code at such an early stage is because I thought it would be useful to 'future-proof' my application :)
 
tanked said:
Thanks for all the replies chaps; my goal is to (way, way down the line) create a Windows database client that will connect to a Postgresql database, running on FreeBSD of course, that will be used to record the clock-in/clock-out times for our employees, as well as handle leave requests etc...

The only reason why I asked about multithreading and 64 bit code at such an early stage is because I thought it would be useful to 'future-proof' my application :)

For that type of application I wouldn't worry about either of those things.

And if I was you I would just use Qt.

http://qt.nokia.com/downloads

98 Qt4 Video Tutorials
http://www.voidrealms.com/tutorials.aspx?filter=qt

25 C++ Video Tutorials
http://www.voidrealms.com/tutorials.aspx?filter=cpp

Qt4 Docs
http://doc.qt.nokia.com/4.7/index.html

Qt Tutorials
http://doc.qt.nokia.com/4.7/tutorials.html

Qt Example Applications
http://doc.qt.nokia.com/4.7/all-examples.html

Qt C++ and Qt Quick (QML/Javascript)
http://doc.qt.nokia.com/4.7/qtquick.html

Qt Getting Started
http://doc.qt.nokia.com/4.7/gettingstartedqt.html

Qt Educational Videos
http://developer.qt.nokia.com/videos#c-141

Qt Course Materials (Tutorials)
http://qt.nokia.com/learning/education/course-materials

A Bunch of Qt4 Examples
http://www.java2s.com/Code/Cpp/Qt/CatalogQt.htm
 
tanked said:
1.) 64 bit software - what is it in the code that makes it 64 bit? Does it mean, amongst other things, making integer variables to always be of type 'double' etc..?

At high level things are not way too different. Most of the times you have to make sure you are playing nice with pointers arithmetics as in such case pointers are wider. Data types remain the same. In some cases the compiler could promote some integer types to be wider at low level but that is transparent to you. At low level things do really change. For instance if you are moving(porting) from x86 to x64 new instructions and registers appear.

tanked said:
2.) Multithreaded - from my reading so far on this all I can seem to find is that its a complex issue, but can anyone explain to me in the simplest possible terms what would make C++ code multithreaded? For example, how would you redesign the "Hello World" programme (if its at all possible) to be multithreaded?

You need to tell the OS to do that for you. It has really not much to do with the language itself except maybe for the volatile reserved word. Is more complex than single threaded code because of synchronization. Some thread could corrupt memory at another thread or cause problems like deadlocks, race conditions etc. With proper and careful synchronization (it can be coarse at your first attempt of the code) it is not that hard. As a rule of thumb you need to avoid two treads from reading/writing the same memory location at the same time and assume no access order specially in preemptive OSs. There are things like letting threads access without contention on only read operations and make them all wait in case of one thread writing and such but those are more advanced for a start, so you better take a step by step approach there. The biggest problem in bugs caused by multithreading is because they are very hard to reproduce. Mutithreading can turn out to be a nightmare in such case and that's why the general phobia. Can produce erratic bugs here and there and can drive you crazy so be extremely careful when writing complex multithreaded code. I have almost never hit one of those because of being so careful when I do, it is not that complex as most ppl says it is.
 
my goal is to (way, way down the line) create a Windows database client that will connect to a Postgresql database, running on FreeBSD of course, that will be used to record the clock-in/clock-out times for our employees, as well as handle leave requests etc...

If you want a recommendation, use .net (you can use managed c++ with that) and forget about portability issues memory handling and a big etcetera. And also forget about picking library for the GUI and developing the interface is declarative (no need to write code there). You can connect to postgres via ODBC. And you can even run that in linux/*bsd with mono. But if you still want to be more productive just forget about c++ and jump into c#. Is a whole lot easier. No need to deal with .h linking problems and a large etcetera. No even need to deal with pointers. Integrated source code documentation and even linq, alpha expressions, generics and a load of nice stuff to help you get things done quickly.
 
halplus said:
I have almost never hit one of those because of being so careful when I do, it is not that complex as most ppl says it is.
Either you are as intelligent as, say, Stephen Hawking, or you haven't done a whole lot of concurrent and/or distributed programming. And I'm guessing the latter.

Fonz
 
halplus said:
If you want a recommendation, use .net
[snip]
and forget about portability issues
[snip]
But if you still want to be more productive just forget about c++ and jump into c#.
Troll alert!

Fonz
 
From my initial reading (the C++ books I've bought and wikipedia) I get the impression that C# makes things easier for you and helps you avoid mistakes but C++ will ultimately give you better performance. Also the cross-platform GUI frameworks seem to be written in C++ so I think I'll still learn C++. C# certainly interests me though.
 
tanked said:
From my initial reading (the C++ books I've bought and wikipedia) I get the impression that C# makes things easier for you and helps you avoid mistakes but C++ will ultimately give you better performance. Also the cross-platform GUI frameworks seem to be written in C++ so I think I'll still learn C++. C# certainly interests me though.

In my opinion Qt has alot more to offer than wxWidgets, in general documentation, support & tools are all alot better. But that's just my opinion. Have a look at those tutorials I posted.

As for c# programming on, well any opensource operating system. You would be better off just using windows. C# is one of the most hated languages in the open source community, not to mention, Mono was built and is developed by one of the most hated, traitorous programmers in all of history, Miguel de Icaza. There are possible questionable legal concerns also.

I would avoid C# and Java.

C & C++ are great languages. Throw in a little lua and your good to go.
 
Yes I'm going to learn C++ first. I've looked at the Qt links and have installed the Qt Editor and I must say I'm strongly leaning towards Qt; for a beginner like me ample documentation / tutorials is a must and I can't find much for xWidgets.
 
tanked said:
C# certainly interests me though.
C# is nothing more than a half-arsed Java clone created by Microsoft to undermine Java (the portability of which is a major pain in Microsoft's arse). I recommend you stay away from it. C, C++ and Java all have comparative advantages and disadvantages, but the one thing they have in common is that they are all better than C#. Pretty much everything is.

Fonz
 
fonz said:
... are all better than C#. Pretty much everything is.

Agreed!

C# is very frustrating, it doesn't bring anything new to the table other than portability issues and yet seems to be used more than Java and C++ in most internal software for many companies I know of.

This is going to turn into VB6 all over again, where Microsoft just jumps onto the next big gimmick and leaves people like us to clean up the mess and re-implement the software into C++ once and for all...

What is it about companies wanting to use short lived gimmicky platforms for development?
 
tanked said:
From my initial reading (the C++ books I've bought and wikipedia) I get the impression that C# makes things easier for you and helps you avoid mistakes but C++ will ultimately give you better performance. Also the cross-platform GUI frameworks seem to be written in C++ so I think I'll still learn C++. C# certainly interests me though.

If you are going to use Windows clients C# is a valuable option, otherwise it could not be the case. Even if Mono is working very well, if you are going to use mixed clients than you have a full range of languages, including C++, python, ruby, perl, Java and so on and PostgreSQL has a very good support for all of them.
With regard to your application I don't think that multithreading is something you should worry about, after all you are going to send an SQL statement with a very low frequency, so the only reason to get multithreaded is to avoid the GUI locking in case of netwrok latency. I would quote everyone else that suggested Qt since it is a very good toolkit and has support for everything you want, database, multithreading and of course UI. Just consider that official release does not come with native support for PostgreSQL and you have to compile it by yourself.
 
Thankyou fluca1978, I get the impression you know a something about client apps for PostgreSQL; although I'm nowhere near the stage of having to worry about it, I've been wondering what method is most commonly used by software engineers to send queries to PostgreSQL - do they type the queries directly in the C/C++ code or do they use 'Embedded SQL':

http://www.postgresql.org/docs/9.1/interactive/ecpg-concept.html

Thanks.
 
tanked said:
what method is most commonly used by software engineers to send queries to PostgreSQL - do they type the queries directly in the C/C++ code or do they use 'Embedded SQL'
Using an API and using embedded SQL are both common practice. In my experience the former is used somewhat more often, but choices vary.

Fonz
 
Fonz is right, using an API is much more common and conveniente (in my opinion) than using Embedded SQL. The API is usually much more reusable and all the frameworks tend to abstract the connection details with a clean and usable API. Qt offers its own wrapper around a database connection, so you don't have either to know it it is PostgreSQL, Oracle, and so on. Your client program will continue to work (at least until the queries are going to work!). If you want to use the "raw" PostgreSQL API than libpq is your friend. If you are going to use a framework, like Qt (not sure about wxWidgets) search the documentation for a database abstraction layer.
 
Short answer: yes. To build a C++/Postgresql application libpq[xx] is what you need. But if you are going to use a framework, like Qt, check out what features the framework provides. For instance, in Qt you don't have to install libpqxx.
As a final note, please consider that pgadmin3, the official PostgreSQL desktop client, is built using wxwidgets.
 
Thankyou, I knew that Pgadmin3 used wxwidgets which is why I thought it might be a good idea to use it for a client, however documentation for wxwidgets seems pretty sparse whereas there is a wealth of it for Qt.

I didn't realise you wouldn't need the API if using Qt, I'll have to look into that, thanks.
 
tanked said:
Thankyou, I knew that Pgadmin3 used wxwidgets which is why I thought it might be a good idea to use it for a client, however documentation for wxwidgets seems pretty sparse whereas there is a wealth of it for Qt.

I didn't realise you wouldn't need the API if using Qt, I'll have to look into that, thanks.

Database programming is on the third page.

http://www.voidrealms.com/tutorials.aspx?filter=qt

C++ Qt 51 - Intro to Databases with Qt Introduction to SQL Database programming with C++ and Qt
C++ Qt 52 - Basic SQL Query with Qt Learn how to make a basic SQL Query with Qt
C++ Qt 53 - QSQLQuery prepare and bindValue learn how to prepare and bindValue with the QSQLQuery class
C++ Qt 54 - QSqlDatabase with DSN Learn how to work with QSQLDatabase and a DSN
C++ Qt 55 - QSqlQueryModel Learn how to display data with the QSqlQueryModel
C++ Qt 56 - QSqlTableModel Learn how to display and edit data with the QSqlTableModel
C++ Qt 57 - QSqlRelationalTableModel Learn how to display relationships between tables
 
Back
Top