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.

[IR]

kwikius wrote:

IR wrote:

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

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

int main()
{
one_phase_windo w 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)Mes sage, 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

[kwikius]

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)Mes sage ring a bell?).

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

int main()
{
one_phase_windo w 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 ApplicationWind ow{
system_window_c ookie cookie; // e.g HWND

ApplicationWind ow() : cookie(NULL)
{
cookie = get_system_wind ow(...);
if (!cookie) {
throw bad_window();
}
}
};

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

struct ChildWindow{
ChildWindow(sys tem_window_cook ie parent); // child needs to have
parent cookie
};
struct ApplicationWind ow_w_child {

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

Or am I missing something?

regards
Andy Little

[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/ScreenSaverMana ger/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

[peter koch]

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/ScreenSaverMana ger/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

[Kaz Kylheku]

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

[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/ScreenSaverMana ger/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

[Alf P. Steinbach]

* 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/ScreenSaverMana ger/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?

[red floyd]

kwikius wrote:

IR wrote:

>kwikius wrote:

>>IR wrote:

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

So there is really no need for that evil two-phase construction.
int main()
{
one_phase_windo w 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 ApplicationWind ow{
system_window_c ookie cookie; // e.g HWND

ApplicationWind ow() : cookie(NULL)
{
cookie = get_system_wind ow(...);
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();
}

[kwikius]

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/ScreenSaverMana ger/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_w indow1::my_cust om_app_window1( std::string const &
name_in)
: base_type(name_ in){

this->add_popup_me nu (".File");
this->add_menu_actio n(".File","Exit ",
&my_custom_app_ window1::exit_a ction);
this->add_popup_me nu (".number");
this->add_menu_actio n(".number","1" );
this->add_menu_actio n(".number","2" );
this->add_popup_me nu (".number","Oth er");
this->add_menu_actio n,".number.Othe r",
"Yep",&my_custo m_app_window1:: dummy_action);
this->add_popup_menu (".Help");
this->add_menu_actio n(".Help","Abou t",
&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 programmaticall y 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
programmaticall y.

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.

[kwikius]

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/ScreenSaverMana ger/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