470,834 Members | 1,784 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,834 developers. It's quick & easy.

Does c++ have an uniform class library?

JTL
I have learnt java before and now begin to learn c++

what puzzle me is that seem that different SDKs(c++builder, vs.net,
gcc..) has its own class library
we know that in java there are only one uniform class library
so that the codes I written in JBuilder can just copy to JCreator or
Eclipse
and they all run well

does c++ have such an uniform class library so that I could just learn
only one time
and then I can use it in c++builder or vs.net or gcc, just the same
codes
what's this uniform class library's name?

if they(c++builder, vs.net,gcc) use different librarys, what class
library do they use?
which library is most usefully or most common ?

Thank you very much in advance.

Dec 1 '06 #1
38 2230
JTL wrote:
I have learnt java before and now begin to learn c++

what puzzle me is that seem that different SDKs(c++builder, vs.net,
gcc..) has its own class library
we know that in java there are only one uniform class library
so that the codes I written in JBuilder can just copy to JCreator or
Eclipse
and they all run well

does c++ have such an uniform class library so that I could just learn
only one time
and then I can use it in c++builder or vs.net or gcc, just the same
codes
what's this uniform class library's name?
Yes, the language standard (ISO/IEC 14882) describes a number library
facilities that every C++ compiler is supposed to provide. These
libraries are sometimes called "the Standard C++ library", or "standard
template library, STL" (they are not 100% identical, STL is older).
if they(c++builder, vs.net,gcc) use different librarys, what class
library do they use?
which library is most usefully or most common ?
The standard library is the common subset of them all.

D.
Dec 1 '06 #2
* JTL:
I have learnt java before and now begin to learn c++

what puzzle me is that seem that different SDKs(c++builder, vs.net,
gcc..) has its own class library
In addition to the C++ standand library, yes.

we know that in java there are only one uniform class library
so that the codes I written in JBuilder can just copy to JCreator or
Eclipse
No, we don't know that. Java has a more extensive "standard" library
than C++, except that (nit-picking my own statement) Sun chickened out
from the standardization process so that Java isn't standardized.
Still, Java isn't so poor a language that there aren't any third-party
libraries.

and they all run well
That might seem to be the case for simple applications, yes.

does c++ have such an uniform class library so that I could just learn
only one time
and then I can use it in c++builder or vs.net or gcc, just the same
codes
what's this uniform class library's name?
That's the C++ standard library. But the standard library intentionally
covers only functionality that is very general and platform-independent.
The C++ model is that instead of one huge standard library you can
choose the third-party library you want, or make your own (and that's
why Java's platform-independence is founded on a virtual machine and
platform-specific adaptions of its libraries, written in C and C++).

if they(c++builder, vs.net,gcc) use different librarys, what class
library do they use?
which library is most usefully or most common ?
Undoubtedly the C++ standard library.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Dec 1 '06 #3
On 2006-12-01 18:59, JTL wrote:
I have learnt java before and now begin to learn c++

what puzzle me is that seem that different SDKs(c++builder, vs.net,
gcc..) has its own class library we know that in java there are only
one uniform class library so that the codes I written in JBuilder can
just copy to JCreator or Eclipse and they all run well

does c++ have such an uniform class library so that I could just
learn only one time and then I can use it in c++builder or vs.net or
gcc, just the same codes what's this uniform class library's name?

if they(c++builder, vs.net,gcc) use different librarys, what class
library do they use? which library is most usefully or most common ?
There is something called STL (Standard Template Library) which is a
very powerful library, though it's nowhere near as comprehensive as
those of Java or .Net or most others. However depending on what you
want to do with your application they can be more than enough. STL is
part of the C++ standard so you can expect it to work with any decent
C++ compiler.

STL does not include any GUI-features so if you're out to make
applications with a GUI you'll have to find some third-party library to
use, there are a couple of third-party libraries/frameworks providing
GUI-classes and more that try to be platform-independent, meaning that
the code should just work when going from Linux to Windows or such. Qt
and GTK are examples of such libraries/frameworks.

--
Erik Wikström
Dec 1 '06 #4
Apart from STL there are many libraries. Boost is the most popular, but
I think you might like this one:
http://appinf.com/poco/docs/
Looks quite similar, doesn't it?

Dec 1 '06 #5
JTL
Thank you very much for your help

I get more clearly now
different SDK have its own library
but all of they can use the Standard C++ library
so now I plan to begin with the STL
and use MFC to make UI

Dec 3 '06 #6
IR
JTL wrote:
and use MFC to make UI
You'd really better use wxWidgets or Qt. Or if you *have* to use
something Microsoft specific, their WTL. If you have access to Borland
C++ Builder, their VCL is not that bad for RAD (and it is very easy to
learn and use).

But the MFC is one of the worst pieces of code I ever saw, and is
really outdated by now. Unless you have legacy MFC code to maintain
(which, according to your post, I doubt), don't even bother learning
it.

Just my thoughts though.

--
IR
Dec 3 '06 #7
JTL
do you means wxWidgets or Qt is better than MFC in making windows UI?
but I haven't heard them before......
I think as I want to make UI in MS windows,it's better to choose MS's
MFC....

Dec 4 '06 #8

JTL wrote in message <11********************@80g2000cwy.googlegroups.co m>...
>do you means wxWidgets or Qt is better than MFC in making windows UI?
but I haven't heard them before......
I think as I want to make UI in MS windows,it's better to choose MS's
MFC....
wxWidgets URL: http://www.wxwidgets.org

--
Bob R
POVrookie
Dec 4 '06 #9
On 2006-12-04 16:03, JTL wrote:
do you means wxWidgets or Qt is better than MFC in making windows UI?
but I haven't heard them before......
I think as I want to make UI in MS windows,it's better to choose MS's
MFC....
Just because you've heard a lot about MFC does not make it good, rather
you might have heard about it because many consider it not good :-)
And besides, MFC is on it's way out, if you want to learn something, go
for something that will last a few years, if you still want to go the MS
way take a look at .Net. If not you might want to take a look at Qt,
which is quite well known (along with others).

--
Erik Wikström
Dec 4 '06 #10
JTL
it sounds interesting that Qt and wxWidgets can be used in windows and
linux
I know nothing about the C++ world...

if I don't need UI,the STL is the best choice to learn,is it right£¿

do Qt or wxWidgets need a runtime environment?
(just as java need the JRE and .net need the .net framework)

as in WindowsXP,how do they build a window?
in java,it call JRE,and JRE call the windows API,is it right£¿
in .net,it call .net framework,and .net framework call the windows
API,is it right£¿
but in MFC or Qt or wxWidgets,it just call the windows API directly to
make a window,is it right£¿

so the .net must need the customer to install the .net framework(like
java)
but Qt or wxWidgets don't need so, just run it,is it right£¿

Dec 5 '06 #11
On Dec 5, 11:17 am, "JTL" <jtl.zh...@gmail.comwrote:
it sounds interesting that Qt and wxWidgets can be used in windows and
linux
I know nothing about the C++ world...

if I don't need UI,the STL is the best choice to learn,is it right?
Yes, since it can be used always (even if you use a GUI) you should
take some time to learn it.
do Qt or wxWidgets need a runtime environment?
(just as java need the JRE and .net need the .net framework)
Don't know about wxWidgets but Qt does not need on. I suspect that
wxWidgets don't need one either, since it's not the Java GUI or .Net
GUI that does require the runtime but rather the languages. I'm not
sure, but it might be possible to do unmanaged .Net GUI, in which case
you would not need a runtime either (but you'll still need the .Net
libraries installed).
as in WindowsXP,how do they build a window?
in java,it call JRE,and JRE call the windows API,is it right?
in .net,it call .net framework,and .net framework call the windows
API,is it right?
but in MFC or Qt or wxWidgets,it just call the windows API directly to
make a window,is it right?
Probably, but you don't have to worry about that.
so the .net must need the customer to install the .net framework(like
java) but Qt or wxWidgets don't need so, just run it,is it right?
Qt will require you to distributa a DLL-file (on windows) along with
your application, unless you compile it statically.

--
Erik Wikström

Dec 5 '06 #12
JTL
so all of them must call the windows API finally to make a window
what's this windows API's name?(does it have?)
is it a library or some DLLs?
and what's the "win32 program"
are they the same?

Dec 6 '06 #13

JTL wrote:
so all of them must call the windows API finally to make a window
what's this windows API's name?(does it have?)
The Windows API. ;-)

(No, I'm serious! That's its name. No one ever said that MS products
don't have descriptive names.) It's somewhat infomally called the Win32
API
is it a library or some DLLs?
DLLs are libraries. Specifically, they're ones that could be loaded
during the execution of your program rather than linked in at compile
time. (DLL stands for dynamic link library. Again with the descriptive
names.)
and what's the "win32 program"
A program built that uses the Windows API.
Note though that the Windows API is a pure C API, so you don't get the
benefits of C++ language features. It's very instructive to write at
least a simple program using it at some point, but I'm not sure that I
would want to use it for an actual project because it's not C++.

I don't quite get what all the hating is with MFC actually, especially
among those who advocate wxWidgets. There's some MFC macro uglyness,
but that's also present in wxWidgets. (At least was a couple years
ago...) However, the other posters are correct in saying that its on
its way out. MS is pushing .Net now, and Windows Forms.

Evan

Dec 6 '06 #14
* Evan:
>
Note though that the Windows API is a pure C API, so you don't get the
benefits of C++ language features. It's very instructive to write at
least a simple program using it at some point, but I'm not sure that I
would want to use it for an actual project because it's not C++.
Parts of the Windows API are adapted to script languages, and large
tracts of it (the COM-based parts) are adapted to early C++.

I don't quite get what all the hating is with MFC actually, especially
among those who advocate wxWidgets.
Mostly that MFC employs two-phase construction. From that, other
equally Bad things follow, which can be summarized as dynamic type
checking and no type checking replacing static type checking. That's
not to say that any particular other library is better, just that MFC
was intentionally designed for C programmers moving to C++: the most
C++'ish features were IIRC removed from the original more C++-like
framework called AFX (that name still lingers in MFC's code).

It's an example of the market place not being ready for radical change
but accepting with whooping joy a small incremental change (it's just
like we always done -- easily recognized -- only better!), which
then becomes a de facto standard for some years, until its bizarre
limitations become too painful to stand.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Dec 6 '06 #15

"""JTL ÐÉÓÁÌ(Á):
"""
I have learnt java before and now begin to learn c++

what puzzle me is that seem that different SDKs(c++builder, vs.net,
gcc..) has its own class library
we know that in java there are only one uniform class library
so that the codes I written in JBuilder can just copy to JCreator or
Eclipse
and they all run well

does c++ have such an uniform class library so that I could just learn
only one time
and then I can use it in c++builder or vs.net or gcc, just the same
codes
what's this uniform class library's name?

if they(c++builder, vs.net,gcc) use different librarys, what class
library do they use?
which library is most usefully or most common ?

Thank you very much in advance.


http://magegame.ru/?rf=626f6764616e

Dec 6 '06 #16

Alf P. Steinbach wrote:

<..>
Mostly that MFC employs two-phase construction. From that, other
equally Bad things follow, which can be summarized as dynamic type
checking and no type checking replacing static type checking.
>From what I can see some form of two phase construction seems to be
necessary, and it seems to be the way things are done in most GUI libs.
At the level of the application window at least:

int main()
{
my_window w;

w.start(); // or run or open or modal loop etc

// if here user pushed button "Exit" or whatever

}

Once the window is 'switched on' the application turns form a
procedural application to an event driven one. Without differentating a
dead and live window (IOW if using single phase construction) you can't
pass windows around before the window event loop starts:

void f(window w)
{
/* ... do something with window*/
}
int main()
{
window w; // single phase construction style window
f(w) ;// f actually entered only after the window has been closed
}

regards
Andy Little

Dec 6 '06 #17
IR
kwikius wrote:
Alf P. Steinbach wrote:

<..>
>Mostly that MFC employs two-phase construction. From that, other
equally Bad things follow, which can be summarized as dynamic
type checking and no type checking replacing static type
checking.
>>From what I can see some form of two phase construction seems to
be
necessary, and it seems to be the way things are done in most GUI
libs. At the level of the application window at least:

int main()
{
my_window w;

w.start(); // or run or open or modal loop etc

// if here user pushed button "Exit" or whatever

}

Once the window is 'switched on' the application turns form a
procedural application to an event driven one. Without
differentating a dead and live window (IOW if using single phase
construction) you can't pass windows around before the window
event loop starts:

void f(window w)
{
/* ... do something with window*/
}
int main()
{
window w; // single phase construction style window
f(w) ;// f actually entered only after the window has been
closed
}
A window and it's contents exist and can be accessed/modified
independently of whether you are running the event loop or not (does
Send(Notify)Message ring a bell?).

So there is really no need for that evil two-phase construction.
Cheers,
--
IR
Dec 6 '06 #18

IR wrote:
A window and it's contents exist and can be accessed/modified
independently of whether you are running the event loop or not (does
Send(Notify)Message ring a bell?).

So there is really no need for that evil two-phase construction.
int main()
{
one_phase_window w;
}

Where exactly are you going to put your send_message in, before the
window runs, or after it quits?

regards
Andy Little

Dec 6 '06 #19
* kwikius:
Alf P. Steinbach wrote:

<..>
>Mostly that MFC employs two-phase construction. From that, other
equally Bad things follow, which can be summarized as dynamic type
checking and no type checking replacing static type checking.
>>From what I can see some form of two phase construction seems to be
necessary, and it seems to be the way things are done in most GUI libs.
At the level of the application window at least:

int main()
{
my_window w;

w.start(); // or run or open or modal loop etc

// if here user pushed button "Exit" or whatever

}

Once the window is 'switched on' the application turns form a
procedural application to an event driven one. Without differentating a
dead and live window (IOW if using single phase construction) you can't
pass windows around before the window event loop starts:

void f(window w)
{
/* ... do something with window*/
}
int main()
{
window w; // single phase construction style window
f(w) ;// f actually entered only after the window has been closed
}
Since you're (as I recall) developing a GUI framework for C++ with the
aim of inclusion in Boost or perhaps even the standard (that would be
C++1x?), it is perhaps on-topic to discuss this.

No, two-phase construction is not necessary, not even for modal dialogs.
The main thing to note about about modal dialogs is that from the
client code's view they're not really windows. They're functions.

I once implemented a little app -- it's a Windows system tray app for
controlling the screen saver -- just demonstrating the principle, that
once you have an object in hand, it's fully constructed and working,
strict C++ RAII principle. There are a few bugs but people were very
happy with it; I use it myself... You can find the source code at <url:
http://home.no.net/alfps/root/programs/ScreenSaverManager/download.html>.

Since then, early 2002, others have reportedly done the same but as
full-fledged GUI frameworks.

One that at least from the discussion about it sounded very OK, using
templates and the standard library and strictly C++ RAII-oriented, was
discussed in a series of articles in some C++ magazine (not DDJ);
perhaps you'll find it by searching the net.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Dec 6 '06 #20
IR
kwikius wrote:
IR wrote:
>A window and it's contents exist and can be accessed/modified
independently of whether you are running the event loop or not
(does Send(Notify)Message ring a bell?).

So there is really no need for that evil two-phase construction.

int main()
{
one_phase_window w;
}

Where exactly are you going to put your send_message in, before
the window runs, or after it quits?
Making a window visible / invisible has nothing to do with it's
construction. Closing a window doesn't necessarily destroy it.
Although it is a bad design IMHO, I often saw windows that could be
used for multiple tasks, some of these tasks not requiring the
window to be displayed on screen.

An example of such (bad) design would be a WYSIWYG "preview" window
that can be driven to print a document, without the need to display
the window itself. In such a case, the window and it's contents are
fully constructed and functional even though the window is not
displayed.
The point I'm trying to make is that objects that require two-phase
construction are not in a *useable* state as long as the second
phase has not been successful.
Displaying a window is an *optional* feature.

So you can construct it, use synchronous messages to simulate user
interaction and get the desired side effects (on MS Windows the
synchronous message API is Send(Notify)Message, opposed to the
asynchronous PostMessage API which really needs an event loop), then
destroy it.

In such a case you never displayed the window, and you never entered
the event loop...
Cheers,
--
IR
Dec 6 '06 #21

IR wrote:
kwikius wrote:
IR wrote:
A window and it's contents exist and can be accessed/modified
independently of whether you are running the event loop or not
(does Send(Notify)Message ring a bell?).

So there is really no need for that evil two-phase construction.
int main()
{
one_phase_window w;
}

Where exactly are you going to put your send_message in, before
the window runs, or after it quits?

Making a window visible / invisible has nothing to do with it's
construction. Closing a window doesn't necessarily destroy it.
OK just to clarify, what you are saying is that you need to have
connected to the display system by the time you exit the window ctor?

struct ApplicationWindow{
system_window_cookie cookie; // e.g HWND

ApplicationWindow() : cookie(NULL)
{
cookie = get_system_window(...);
if (!cookie) {
throw bad_window();
}
}
};

The problem is that for child windows AFAICS you are restricted to
(smart) pointers

struct ChildWindow{
ChildWindow(system_window_cookie parent); // child needs to have
parent cookie
};
struct ApplicationWindow_w_child {

ChildWindow m_child; // cant do this
ApplicationWindow_w_child() : m_child(???) {//* */}
};

Or am I missing something?

regards
Andy Little

Dec 6 '06 #22
Alf P. Steinbach wrote:
happy with it; I use it myself... You can find the source code at <url:
http://home.no.net/alfps/root/programs/ScreenSaverManager/download.html>.
Cute!. and useful. I will probably keep that :-)

BTW the precompiled help file as downloaded didnt seem to display any
content on my system, so I had to compile it locally.

So to get back to the subject, what you are saying is that you should
get the system window cookie for the window (e.g by cookie I mean the
HWND in windows) in the constructor of your window class?

<...>
One that at least from the discussion about it sounded very OK, using
templates and the standard library and strictly C++ RAII-oriented, was
discussed in a series of articles in some C++ magazine (not DDJ);
perhaps you'll find it by searching the net.
Do you mean win32GUI ?

regards
Andy Little

Dec 6 '06 #23

kwikius skrev:
Alf P. Steinbach wrote:
happy with it; I use it myself... You can find the source code at <url:
http://home.no.net/alfps/root/programs/ScreenSaverManager/download.html>.

Cute!. and useful. I will probably keep that :-)

BTW the precompiled help file as downloaded didnt seem to display any
content on my system, so I had to compile it locally.

So to get back to the subject, what you are saying is that you should
get the system window cookie for the window (e.g by cookie I mean the
HWND in windows) in the constructor of your window class?

<...>
One that at least from the discussion about it sounded very OK, using
templates and the standard library and strictly C++ RAII-oriented, was
discussed in a series of articles in some C++ magazine (not DDJ);
perhaps you'll find it by searching the net.

Do you mean win32GUI ?
win32gui is/was a very nice library for windows. Unfortunately it was
not maintained and when I downloaded it some month ago I could not get
it to work (I spend about two afternoons on this). A pity.
One thing I disliked about the library was the use of "magic" numbers -
Windows IDs. This and the use of the resource editor are ackward and
should be avoidable. But apart from that a potentially very nice
library.

/Peter
>
regards
Andy Little
Dec 6 '06 #24
JTL wrote:
it sounds interesting that Qt and wxWidgets can be used in windows and
linux
.... and have bindings from other languages.

Python: wxPython
Common Lisp: wxCL

Dec 6 '06 #25

Alf P. Steinbach wrote:
happy with it; I use it myself... You can find the source code at <url:
http://home.no.net/alfps/root/programs/ScreenSaverManager/download.html>.
Cute!. and useful. I will probably keep that :-)

BTW the precompiled help file as downloaded didnt seem to display any
content on my system, so I had to compile it locally.

So to get back to the subject, what you are saying is that you should
get the system window cookie for the window (e.g by cookie I mean the
HWND in windows) in the constructor of your window class?

<...>
One that at least from the discussion about it sounded very OK, using
templates and the standard library and strictly C++ RAII-oriented, was
discussed in a series of articles in some C++ magazine (not DDJ);
perhaps you'll find it by searching the net.
Do you mean win32GUI ?

regards
Andy Little

Dec 6 '06 #26
* kwikius:
Alf P. Steinbach wrote:
>happy with it; I use it myself... You can find the source code at <url:
http://home.no.net/alfps/root/programs/ScreenSaverManager/download.html>.

Cute!. and useful. I will probably keep that :-)

BTW the precompiled help file as downloaded didnt seem to display any
content on my system, so I had to compile it locally.

So to get back to the subject, what you are saying is that you should
get the system window cookie for the window (e.g by cookie I mean the
HWND in windows) in the constructor of your window class?
Yep.

I mean, have you tried extending a control in a typical GUI framework?

First that happens is that one discovers that this or that can't be done
/here/, because there's no API window yet, not there either, oh dang,
what's the actual /sequence/ of these calls? Not to mention that with
two-phase you get virtual calls down to a derived class' code before the
base class sub-object has been fully (logical level) initialized: bang
crash. And the frustrating thing is the knowledge that all this
[censored] is /unnecessary/, that it's just due to the framework
developers designing the framework for "C++ as better C", not for C++.

<...>
>One that at least from the discussion about it sounded very OK, using
templates and the standard library and strictly C++ RAII-oriented, was
discussed in a series of articles in some C++ magazine (not DDJ);
perhaps you'll find it by searching the net.

Do you mean win32GUI ?
*Checking the web page*

Yes.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Dec 6 '06 #27
kwikius wrote:
IR wrote:
>kwikius wrote:
>>IR wrote:

A window and it's contents exist and can be accessed/modified
independently of whether you are running the event loop or not
(does Send(Notify)Message ring a bell?).

So there is really no need for that evil two-phase construction.
int main()
{
one_phase_window w;
}

Where exactly are you going to put your send_message in, before
the window runs, or after it quits?
Making a window visible / invisible has nothing to do with it's
construction. Closing a window doesn't necessarily destroy it.

OK just to clarify, what you are saying is that you need to have
connected to the display system by the time you exit the window ctor?

struct ApplicationWindow{
system_window_cookie cookie; // e.g HWND

ApplicationWindow() : cookie(NULL)
{
cookie = get_system_window(...);
if (!cookie) {
throw bad_window();
}
}
};
I think he means this sort of thing.

void show_dialog()
{
CSomeDialog dlg;

// YECCCH!!! TWO-PHASE INITIALIZATION HERE!!!!!
dlg.this_item = something;
dlg.that_item = something_else;
// etc...
rc = dlg.DoModal();
}

Dec 7 '06 #28
peter koch wrote:
kwikius skrev:
Alf P. Steinbach wrote:
happy with it; I use it myself... You can find the source code at <url:
http://home.no.net/alfps/root/programs/ScreenSaverManager/download.html>.
Cute!. and useful. I will probably keep that :-)

BTW the precompiled help file as downloaded didnt seem to display any
content on my system, so I had to compile it locally.

So to get back to the subject, what you are saying is that you should
get the system window cookie for the window (e.g by cookie I mean the
HWND in windows) in the constructor of your window class?

<...>
One that at least from the discussion about it sounded very OK, using
templates and the standard library and strictly C++ RAII-oriented, was
discussed in a series of articles in some C++ magazine (not DDJ);
perhaps you'll find it by searching the net.
Do you mean win32GUI ?

win32gui is/was a very nice library for windows. Unfortunately it was
not maintained and when I downloaded it some month ago I could not get
it to work (I spend about two afternoons on this). A pity.
One thing I disliked about the library was the use of "magic" numbers -
Windows IDs.
I agree about the us of magic numbers. My reference to the system
window cookie in my other posts in this thread was merely to illustrate
an implemntation detail. You should be able to get at the cookie to
hook into the native system, but I agree that it shouldnt be exposed
unnecesarily. Nevertheless the window cookie, or window handle is the
connection point to the system so I think its important to have it as
an, as far as possible opaque, but nevertheless visible Concept.

As far as child window id's go, it is usually possible to map them to a
cookie and so to a platform independent lightweight window type (
basically one that is owned by the system) , which nevertheless
provides "the usual operations", and it is possible to generate id's
automatically internally as required.

For menus my current scheme consists of treating them basically as a
directory tree structure accessed via paths. This works well for menus
as they naturally have unique names per branch. Internally the string
id is mapped to a string_handle so that as well as accessing via text
paths one can create a path consisting of a list of ids, which may
provide faster access. Here FWIW is what my current working test app
menu construction scheme looks like. It is somewhat reminiscent of the
one in Ultimate++ AFAICS:

my_custom_app_window1::my_custom_app_window1(std:: string const &
name_in)
: base_type(name_in){

this->add_popup_menu (".File");
this->add_menu_action(".File","Exit",
&my_custom_app_window1::exit_action);
this->add_popup_menu (".number");
this->add_menu_action(".number","1");
this->add_menu_action(".number","2");
this->add_popup_menu (".number","Other");
this->add_menu_action,".number.Other",
"Yep",&my_custom_app_window1::dummy_action);
this->add_popup_menu(".Help");
this->add_menu_action(".Help","About",
&my_custom_app_window1::about_command);

}
(The leading dots are optional but seem to help legibility)
it will also work on arbitrary long paths of course, and the idea is
that you can enable, disable, grey out, get state and change the
callbacks , all via the paths as above. You can also get hold of child
nodes direct if you wish to work at one level.
This and the use of the resource editor are ackward and
should be avoidable.
Personally I dont like the GUI style widget editors much,for designing
controls. IMO It is usually superior and easier to maintain, to size a
modal dialog box, say, at runtime based on the size of the text, images
and so on, so that if these change or are of arbitrary size,constant
borders, spacing and so on are calculated automatically on the fly /
and or according to some 'look and feel' function, so I am trying to
make sure this is easy to achieve programmatically in the language
rather than via custom scripts. Overall this goes for any of the
'resource' stuff. I think by default it should not be necessary to need
resources and it should be possible to create everything
programmatically.

Having created Quan physical quantities library...

http://quan.sourceforge.net/quan_mat...tml/index.html

.... naturally I use Quan physical length units for dialog boxes. This
may not be everyones taste but once you know the size of a text
character in mm, or whatever your favourite unit is, I find it is
satisfying to provide spacings and so on in terms of millimeters or
inches or whatever rather than pixels, which gives you a constant look
independent of display hardware.

Dec 7 '06 #29

Alf P. Steinbach wrote:
* kwikius:
Alf P. Steinbach wrote:
happy with it; I use it myself... You can find the source code at <url:
http://home.no.net/alfps/root/programs/ScreenSaverManager/download.html>.
Cute!. and useful. I will probably keep that :-)

BTW the precompiled help file as downloaded didnt seem to display any
content on my system, so I had to compile it locally.

So to get back to the subject, what you are saying is that you should
get the system window cookie for the window (e.g by cookie I mean the
HWND in windows) in the constructor of your window class?

Yep.
OK. but the drawback of this AFAICS is that you can only have pointers
(e.g boost shared_ptr) to child windows as members of a winow class I
don't see a way around that.
Nevertheless I will try implementing the single phase construction
scheme. I did a quick test of it in my current test app and lo and
behold I got an exception from a child window that wanted its parent:-)
I mean, have you tried extending a control in a typical GUI framework?
Maybe I just got used to it. Seriously though, I have tried and often
got very frustrated in MFC . I much prefer the raw SDK in Windows.

regards
Andy Little

Dec 7 '06 #30

Alf P. Steinbach wrote:
* kwikius:
<...>
So to get back to the subject, what you are saying is that you should
get the system window cookie for the window (e.g by cookie I mean the
HWND in windows) in the constructor of your window class?

Yep.
If the window has a child, where does it get the informtion to
construct it?

regards
Andy Little

Dec 7 '06 #31
* kwikius:
Alf P. Steinbach wrote:
>* kwikius:

<...>
>>So to get back to the subject, what you are saying is that you should
get the system window cookie for the window (e.g by cookie I mean the
HWND in windows) in the constructor of your window class?
Yep.

If the window has a child, where does it get the informtion to
construct it?
Huh?

In the example code I gave there were a number of child windows, but no
such problem.

At least as I recall.

Generally, in C++ the information needed to construct "owned" objects is
passed in as arguments to a constructor, or embedded in constructor code
or in code called from a constructor.

It's possible that FAQ item 23.6, "Okay, but is there a way to simulate
that behavior as if dynamic binding worked on the this object within my
base class's constructor?" is relevant (although I don't know what your
question really is).

The reason I think it might be relevant: FAQ item 23.6 resulted from
considerations about mismatch of statically type safe construction (as
in C++) versus dynamically typed construction (as in e.g. Windows API
window construction). You can read my original proposal for that FAQ
item (in the proposal numbered 20.7, and with different terminology, we
now call it "dynamic binding during initialization" (Marshall's idea)
rather than "virtual construction" (my idea)) at <url:
http://home.no.net/alfps/faq_proposal/@virtual-functions.html>.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Dec 7 '06 #32
Alf P. Steinbach wrote:
* kwikius:
Alf P. Steinbach wrote:
* kwikius:
<...>
>So to get back to the subject, what you are saying is that you should
get the system window cookie for the window (e.g by cookie I mean the
HWND in windows) in the constructor of your window class?
Yep.
If the window has a child, where does it get the informtion to
construct it?

Huh?

In the example code I gave there were a number of child windows, but no
such problem.
OK. I have quickly perused your screensaver code, but not studied it in
detail. When you talk of child windows in the screensaver app are you
talkng about modal dialogs or persistent child windows?
At least as I recall.

Generally, in C++ the information needed to construct "owned" objects is
passed in as arguments to a constructor, or embedded in constructor code
or in code called from a constructor.
Well if you think of a windows application as a tree with the
application window as the root, then you can deduce that as the tree
grows arbitrarily large then the number of arguments to the root window
ctor will grow to ridiculous and umanageable size.

I am interested in the one phase v two phase construction issue. I
don't see why it shouldnt be possible to provide for both paradigms,
but it does affect the structure of code dramatically afaiks.
It's possible that FAQ item 23.6, "Okay, but is there a way to simulate
that behavior as if dynamic binding worked on the this object within my
base class's constructor?" is relevant (although I don't know what your
question really is).

The reason I think it might be relevant: FAQ item 23.6 resulted from
considerations about mismatch of statically type safe construction (as
in C++) versus dynamically typed construction (as in e.g. Windows API
window construction). You can read my original proposal for that FAQ
item (in the proposal numbered 20.7, and with different terminology, we
now call it "dynamic binding during initialization" (Marshall's idea)
rather than "virtual construction" (my idea)) at <url:
http://home.no.net/alfps/faq_proposal/@virtual-functions.html>.
OK I will take a look at those links. To provide a concrete example
AFAIKS one way to create a persistent single phase child window in is
as a non member of the parent:

int main()
{
app_window w; // w gets window system cookie in ctor,
//parent knows nothing about child windows

child_window child(w); // child window has all necessary info to
construct it.

w.run();

}

Whether the creation order is a stack or a tree amounts to the same
thing

The alternative approach of making the child a member seems to me to
require ( for scaleability) two phase construction.

regards
Andy Little

Dec 7 '06 #33
* kwikius:
Alf P. Steinbach wrote:
>* kwikius:
>>Alf P. Steinbach wrote:
* kwikius:
<...>

So to get back to the subject, what you are saying is that you should
get the system window cookie for the window (e.g by cookie I mean the
HWND in windows) in the constructor of your window class?
Yep.
If the window has a child, where does it get the informtion to
construct it?
Huh?

In the example code I gave there were a number of child windows, but no
such problem.

OK. I have quickly perused your screensaver code, but not studied it in
detail. When you talk of child windows in the screensaver app are you
talkng about modal dialogs
No.

or persistent child windows?
Please define the term.

>At least as I recall.

Generally, in C++ the information needed to construct "owned" objects is
passed in as arguments to a constructor, or embedded in constructor code
or in code called from a constructor.

Well if you think of a windows application as a tree with the
application window as the root, then you can deduce that as the tree
grows arbitrarily large then the number of arguments to the root window
ctor will grow to ridiculous and umanageable size.
Nope. ;-)

An analogy may help.

Think of the object structure of a non-windowing program, with
single-phase construction of all objects. There's a huge collection of
objects. The number of arguments to the top-level object's constructor
(if there is a top-level object) is unaffected: the structure isn't
specified at that point.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Dec 7 '06 #34

Alf P. Steinbach wrote:
* kwikius:
Alf P. Steinbach wrote:
* kwikius:
Alf P. Steinbach wrote:
* kwikius:
<...>

So to get back to the subject, what you are saying is that you should
get the system window cookie for the window (e.g by cookie I mean the
HWND in windows) in the constructor of your window class?
Yep.
If the window has a child, where does it get the informtion to
construct it?
Huh?

In the example code I gave there were a number of child windows, but no
such problem.
OK. I have quickly perused your screensaver code, but not studied it in
detail. When you talk of child windows in the screensaver app are you
talkng about modal dialogs

No.

or persistent child windows?

Please define the term.
modeless in Windows terminology. You can remove focus from them and
they will persist as entities, unlike modal dialogs which keep focus (
You cant click a button in another window for example) until closed
bythe user

At least as I recall.

Generally, in C++ the information needed to construct "owned" objects is
passed in as arguments to a constructor, or embedded in constructor code
or in code called from a constructor.
Well if you think of a windows application as a tree with the
application window as the root, then you can deduce that as the tree
grows arbitrarily large then the number of arguments to the root window
ctor will grow to ridiculous and umanageable size.

Nope. ;-)
Hmm. Well looking at the faq, it seems that if I rename any child
window member to child window 'factory' then everybodies happy ;-)

Seriously I want to try to provide simple solutions where possible.
Object factories and virtual ctors are too 'geeky' for what I am trying
to achieve. The aim is that a beginner can get a simple GUI app running
as easily as possible.

FWIW I did say that I had ideas to present my efforts as a standard
GUI, but I also implied I hope not to get overexcited, as from previous
experience I don't seriously expect my stuff to be acceptable. From
experience with Quan , which was presented and rejected by boost:

http://quan.sourceforge.net/quan_mat...tml/index.html

The outcome of that is that I think it has put physical quantity
libraries on the radar slightly, and some of the ideas in Quan have
been used in other quantities libs now in the boost vault

At the end of the day I am writing the framework primarily for myself,
hence e.g the use of Quan quantities for dialog units and so on. I am
howvere trying to use standard components where possible . No std::tree
though unfortunately :-(
An analogy may help.

Think of the object structure of a non-windowing program, with
single-phase construction of all objects. There's a huge collection of
objects. The number of arguments to the top-level object's constructor
(if there is a top-level object) is unaffected: the structure isn't
specified at that point.
Whether the tree consists of windows or not doesnt seem to be relevant
AFAICS. The only point of debate is when the tree is considered
constructed. Again call the tree a factory and everybodies happy. This
is basically the scheme I use in my menu example.

regards
Andy Little

Dec 7 '06 #35
* kwikius:
>
[snip]
Seriously I want to try to provide simple solutions where possible.
Object factories and virtual ctors are too 'geeky' for what I am trying
to achieve.
Yes, that was the argument used to "simplify" AFX to MFC... Not that
AFX was necessarily much better, of course. But you've seen the result.

The aim is that a beginner can get a simple GUI app running
as easily as possible.
Yes, that's what simplicity, like RAII, buys you.

I'm sorry but I don't understand the rest.

It seems there is a communications gap, talking from very different
backgrounds (different experience, different assumptions?). I know that
the scheme I'm advocating is sound, doable and simple, because I've done
it, and provided a working app as a concrete example, and because others
have also done it. And I'm unable to relate the counter-arguments or
questions to anything, to get a grip on what they might really be about.

Perhaps your project is more in line with <url:
http://smartwin.sourceforge.net/>, a framework by Thomas Hansen designed
"get a simple GUI app running as easily as possible", rather than what I
envisioned?

Perhaps some collaboration there could be fruitful?

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Dec 7 '06 #36

Alf P. Steinbach wrote:
* kwikius:
[snip]
Seriously I want to try to provide simple solutions where possible.
Object factories and virtual ctors are too 'geeky' for what I am trying
to achieve.

Yes, that was the argument used to "simplify" AFX to MFC... Not that
AFX was necessarily much better, of course. But you've seen the result.

The aim is that a beginner can get a simple GUI app running
as easily as possible.

Yes, that's what simplicity, like RAII, buys you.

I'm sorry but I don't understand the rest.
If you mean renaming windows to window 'factories':

http://smartwinlib.org/faq.php?id=4

<...>
Perhaps your project is more in line with <url:
http://smartwin.sourceforge.net/>, a framework by Thomas Hansen designed
"get a simple GUI app running as easily as possible", rather than what I
envisioned?
WEll.. I am hoping to produce something cross platform, but as regards
a standards proposal, don't hold your breath, even if I deliver it.
regards
Andy Little

Dec 7 '06 #37
IR
kwikius wrote:
IR wrote:
>kwikius wrote:
IR wrote:

A window and it's contents exist and can be accessed/modified
independently of whether you are running the event loop or not
(does Send(Notify)Message ring a bell?).

So there is really no need for that evil two-phase
construction.

int main()
{
one_phase_window w;
}

Where exactly are you going to put your send_message in, before
the window runs, or after it quits?

Making a window visible / invisible has nothing to do with it's
construction. Closing a window doesn't necessarily destroy it.

OK just to clarify, what you are saying is that you need to have
connected to the display system by the time you exit the window
ctor?

struct ApplicationWindow{
system_window_cookie cookie; // e.g HWND

ApplicationWindow() : cookie(NULL)
{
cookie = get_system_window(...);
if (!cookie) {
throw bad_window();
}
}
};

The problem is that for child windows AFAICS you are restricted to
(smart) pointers

struct ChildWindow{
ChildWindow(system_window_cookie parent); // child needs to have
parent cookie
};
struct ApplicationWindow_w_child {

ChildWindow m_child; // cant do this
ApplicationWindow_w_child() : m_child(???) {//* */}
};

Or am I missing something?
I rather thought of an inheritance tree, something along the
lines...

struct Window // base class for all windows
{
system_cookie cookie;
Window(system_cookie parent)
: cookie(0)
{
cookie = create_system_window( /*...*/ );
//...
}
};

struct MyChildWindow : public Window
{
MyChildWindow(system_cookie parent) : Window(parent) { /*...*/ }
};

struct MyAppWindow : public Window
{
MyChildWindow m_child;
MyAppWindow()
: Window(0), // top level, has no parent
m_child(Window::cookie) // cookie is valid here
{ /*...*/ }
};

Or am I the one missing something important?

For better encapsulation, I'd even pass a pointer to a Window object
instead of exposing the raw system cookie in the constructors, but
this is a mere detail here.

I also know of a GUI library (namely, Borland's VCL) which provides
on-demand "cookie construction".
I'm not sure this very design changes anything to the problem we are
discussing, but I thought I'd mention it.

Roughly,

class Window
{
system_cookie m_cookie;
system_cookie m_parent; // see comment below
public:
system_cookie cookie()
{
if (!m_cookie)
{
cookie = create_window( /*...*/ );
//...
};
return m_cookie;
}
Window(system_cookie parent)
: m_cookie(0),
m_parent(parent)
{
// leave m_cookie alone until really needed
}
};

The drawback IMHO with this latter approach is that one needs to
maintain a copy of a window's parameters in the Window class (eg.
the window's parent must be stored so that it is available to the
cookie() method, etc).
Cheers,
--
IR
Dec 7 '06 #38

IR wrote:
kwikius wrote:
IR wrote:
kwikius wrote:
IR wrote:

A window and it's contents exist and can be accessed/modified
independently of whether you are running the event loop or not
(does Send(Notify)Message ring a bell?).

So there is really no need for that evil two-phase
construction.

int main()
{
one_phase_window w;
}

Where exactly are you going to put your send_message in, before
the window runs, or after it quits?

Making a window visible / invisible has nothing to do with it's
construction. Closing a window doesn't necessarily destroy it.
OK just to clarify, what you are saying is that you need to have
connected to the display system by the time you exit the window
ctor?

struct ApplicationWindow{
system_window_cookie cookie; // e.g HWND

ApplicationWindow() : cookie(NULL)
{
cookie = get_system_window(...);
if (!cookie) {
throw bad_window();
}
}
};

The problem is that for child windows AFAICS you are restricted to
(smart) pointers

struct ChildWindow{
ChildWindow(system_window_cookie parent); // child needs to have
parent cookie
};
struct ApplicationWindow_w_child {

ChildWindow m_child; // cant do this
ApplicationWindow_w_child() : m_child(???) {//* */}
};

Or am I missing something?

I rather thought of an inheritance tree, something along the
lines...
<.. cut examples>

hmm... Clearly I need to try out these scenarios. On reflection I can
see the benefits of single phase construction and I hadnt really
thought about it prior to this discussion, so I will see what I can
come up with in my testbed toolkit

regards
Andy Little

Dec 7 '06 #39

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by Curious | last post: by
8 posts views Thread by kiranchahar | last post: by
4 posts views Thread by Alex Vinokur | last post: by
reply views Thread by mihailmihai484 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.