- Frequently Asked Questions (FAQ)

 Home >  FAQ on different themes > Frequently Asked Questions (FAQ)

Section 1 of 4 - Prev - Next
All sections - 1 - 2 - 3 - 4

Archive-name: Xt-FAQ
Version: $Id: FAQ-Xt,v 1.44 1995/03/27 15:22:22 ware Exp ware $

		    The X Toolkit Intrinsics F.A.Q
			  A monthly posting

This article contains the answers to some Frequently Asked Questions
(FAQ) from about the X Toolkit Intrinsics.  To submit
questions (preferably with an answer) send email to:

or you can find out more about me as:

This FAQ is available on the archive site in the directory:


The name under which a FAQ is archived appears in the Archive-name
line at the top of the article.  This FAQ is archived as Xt-FAQ.  It
is also archived in


All code fragments are public domain.  


0.  Xt Glossary
1.  Software Versions
2.  Related FAQ's
3.  Why does my app core dump when I use signals/alarms/cthreads?
4.  How do I use a different visual than the default?
5.  Which visual should an application use?
6.  Why do only Shell widgets have a Visual?
7.  Which visual, depth and colormap do Shells inherit?
8.  I've done all the above and I still get a BadMatch error.  Why?
9.  Why doesn't my widget get destroyed when I call XtDestroyWidget()?
10. How do I exit but still execute the DestroyCallbacks?
11. How do I resize a Shell widget?
12. Why can't XtAppAddInput() handle files?
13. What good books and magazines are there on Xt?
14. What Widgets are available?
15. What alternatives to the Intrinsics are there?
16. How do I pass a float value to XtSetValues?
17. How do I write a resource converter?
18. How do I open multiple displays?
19. What changed from R3 to R4 to R5?
20. Where are the resources loaded from?
21. What order are callbacks executed in?
22. How do I know if a widget is visible?
23. How do I reparent a widget in Xt, i.e. XtReparentWidget()?
24. Why use XtMalloc, XtFree, etc?
25. How to debug an Xt application?
26. Why don't XtAddInput(), XtAddTimeout() and XtAddWorkProc() work?
27. What is and how can I implement drag and drop?
28. How can I add a C++ member function as a widget callback?
29. How can I identify the children of a manager widget?
30. Can I use XtMoveWidget(), ... to move widgets I created?
31. Why is XtGetValues() on XtNx, XtNy of my top level shell wrong?
32. Why do some people use XmN as resource names?
33. How do I make my life easier when designing an application?
34. Why can't I override translations? Only the first item works.
35. Why do I get "Warning: Widget class version mismatch"?
36. Where can I get a good file-selector widget?
37. Where can I find a hypertext widget or source code?
38. What widget is appropriate to use as a drawing canvas?
39. What is this link problem with _get_wmShellWidgetClass, XtInherit?
40. Why does XtGetValues not work for me (sic)?
41. Is this a memory leak in the X11R4 XtDestroyWidget()?!
42. Is this a memory leak in the X11R4 deletion of work procs?!
43. How do I query the user synchronously using Xt?
44. How do I simulate a button press/release event for a widget?
45. How to use Fallback resources (can I specify colors)?
46. What is the preferred way of setting the application resources?
47. How to get rid of that annoying flicker during updates?
48. How are created, managed, mapped, realized, etc. related?
49. How to use the String definition from a C++ library?

Subject: 0.  Xt Glossary

o The Xt Intrinsics implement an object oriented interface to C code
  to allow useful graphical components to be created.  Included with
  this are classes that provide the base functionality: Object,
  RectObj, Core, Composite, Constraint, Shell, OverrideShell, WMShell,
  etc.  The terms "Xt" and "Intrinsics" are used interchangeably,
  however, they are used very precisely to mean a specific library of the X
  window system.  In particular, it does not include the Athena,
  Motif, OLIT or any other widget set.  Without further widgets the
  Intrinsics are not especially useful.

o A widget refers to a user interface abstraction created via Xt.  The
  precise use, is any object that is a subclass of the Core class.  It
  is used loosely to refer to anything that is a subclass of the
  Object class although these are more accurately called windowless
  widgets or gadgets.

o Xlib is the C interface to the X11 protocol.  It is one layer below
  the Xt Intrinsics.  Typically a widget uses relatively few Xlib
  functions because Xt provides most such services although an
  understanding of Xlib helps with problems.

Subject: 1.  Software Versions

The following are the latest versions of Xt based software:
	Software	Version		Released	Next Expected
	X11R4		patch 18			(none)
	X11R5		patch 26	11/3/93		(none)
	X11R6		patch 13	11/3/95		(see R6.1)
	X11R6.1		patch 1		3/11/96		soon
	Athena Widgets	(see X11R6)
	Motif		2.0		6/21/94		??
	OLIT		??		??		??
	Xtra		2.5		6/15/92		??
	Xw		X11R4				(none)
	Xcu		X11R5				(none)
	fwf		4.1		5/24/96		??

Subject: 2.  Related FAQ's

David B. Lewis (uunet!craft!faq) maintains the FAQ on X.  It
is posted monthly on and located in:


Liam R. E. Quin ( posts an FAQ list on Open Look to  

Ken Sall ( posts an FAQ list on Motif to it is also in


Pete Ware ( posts an FAQ list for; it is in


John L. Cwikla ( posts an FAQ list that contains freely
available widgets; it is in:


Subject: 3.  Why does my app core dump when I use signals/alarms/cthreads?

In brief, Xlib, Xt and most widget sets have no mutual exclusion for
critical sections.  Any interrupt handler is likely to leave one of
the above libraries in an inconsistent state -- such as all the
appropriate flags not yet set, dangling pointers, in the middle of a
list traversal, etc.  Note that the ANSI C standard points out that
behavior of a signal handler is undefined if the signal handler calls
any function other than signal() itself, so this is not a problem
specific to Xlib and Xt; the POSIX specification mentions other
functions which may be called safely but it may not be assumed that
these functions are called by Xlib or Xt functions.

The only safe way to deal with signals is to set a flag in the
interrupt handler.  This flag later needs to be checked either by a
work procedure or a timeout callback.  It is incorrect to add either
of these in the interrupt handler.  As another note, it is dangerous
to add a work procedure that never finishes.  This effectively
preempts any work procedures previously added and so they will never
be called.  Another option is to open a pipe, tell the event loop
about the read end using XtAppAddInput() and then the signal handler
can write a byte to the write end of the pipe for each signal.
However, this could deadlock your process if the pipe fills up.

Why don't the Intrinsics deal with this problem?  Primarily because it
is supposed to be a portable layer to any hardware and operating
system.   Is that a good enough reason -- I don't think so.

        Note: the article in The X Journal 1:4 and the example in O'Reilly
Volume 6 are in error.

Subject: 4.! How do I use a different visual than the default?

This requires a more complicated answer than it should.  A window has
three things that are visual specific -- the visual, colormap and
border pixmap.  All widgets have their own Colormap and BorderPixmap
resource; only shell widgets have Visual resources (another questions
deals with why shells have a Visual).  The default value of these
resources is CopyFromParent which does exactly what it says.  In the
shell widget CopyFromParent gets evalulated as DefaultVisualOfScreen
and DefaultColormapOfScreen.  When any one of the three resources is
not properly set, a BadMatch error occurs when the window is
created.  They are not properly set because each of the values depends
on the visual being used.  

How to get this to work?  There are two parts to the answer.  The
first is if you want an application to start with a particular visual
and the second is if you want a particular shell within an application
to start with a different visual.  The second is actually easier
because the basic information you need is available.  The first is a
little harder because you'll need to initialize much of the toolkit
yourself in order to determine the needed information.

 * Some sample code to start up an application using something other
 * than the default visual.
 * To compile:
 *	cc -g visual.c -o visual -lXaw -lXmu -lXt -lXext -lX11 -lm
 * To run:
 *	./visual -geometry 300x300 -depth 24 -visual StaticColor -fg blue -bg yellow
 * you need to move the mouse to get the particular visuals colormap
 * to install.


typedef struct
	Visual	*visual;
	int	depth;
} OptionsRec;

OptionsRec	Options;

XtResource resources[] =
	{"visual", "Visual", XtRVisual, sizeof (Visual *),
	XtOffsetOf (OptionsRec, visual), XtRImmediate, NULL},
	{"depth", "Depth", XtRInt, sizeof (int),
	XtOffsetOf (OptionsRec, depth), XtRImmediate, NULL},

XrmOptionDescRec Desc[] =
	{"-visual", "*visual", XrmoptionSepArg, NULL},
	{"-depth", "*depth", XrmoptionSepArg, NULL}

main (argc, argv)
	int		argc;
	char		**argv;
	XtAppContext	app;		/* the application context */
	Widget		top;		/* toplevel widget */
	Display		*dpy;		/* display */
	char		**xargv;	/* saved argument vector */
	int		xargc;		/* saved argument count */
	Colormap	colormap;	/* created colormap */
	XVisualInfo	vinfo;		/* template for find visual */
	XVisualInfo	*vinfo_list;	/* returned list of visuals */
	int		count;		/* number of matchs (only 1?) */
	Arg		args[10];
	Cardinal	cnt;
	char		*name = "test";
	char		*class = "Test";

	 * save the command line arguments

	xargc = argc;
	xargv = (char **) XtMalloc (argc * sizeof (char *));
	bcopy ((char *) argv, (char *) xargv, argc * sizeof (char *));

	 * The following creates a _dummy_ toplevel widget so we can
	 * retrieve the appropriate visual resource.
	cnt = 0;
	top = XtAppInitialize (&app, class, Desc, XtNumber (Desc), &argc, argv,
			       (String *) NULL, args, cnt);
	dpy = XtDisplay (top);
	cnt = 0;
	XtGetApplicationResources (top, &Options, resources,
				   XtNumber (resources),
				   args, cnt);
	cnt = 0;
	if (Options.visual && Options.visual != DefaultVisualOfScreen (XtScreen (top)))
		XtSetArg (args[cnt], XtNvisual, Options.visual); ++cnt;
		 * Now we create an appropriate colormap.  We could
		 * use a default colormap based on the class of the
		 * visual; we could examine some property on the
		 * rootwindow to find the right colormap; we could
		 * do all sorts of things...
		colormap = XCreateColormap (dpy,
					    RootWindowOfScreen (XtScreen (top)),
		XtSetArg (args[cnt], XtNcolormap, colormap); ++cnt;

		 * Now find some information about the visual.
		vinfo.visualid = XVisualIDFromVisual (Options.visual);
		vinfo_list = XGetVisualInfo (dpy, VisualIDMask, &vinfo, &count);
		if (vinfo_list && count > 0)
			XtSetArg (args[cnt], XtNdepth, vinfo_list[0].depth);
			XFree ((XPointer) vinfo_list);
	XtDestroyWidget (top);

	 * Now create the real toplevel widget.
	XtSetArg (args[cnt], XtNargv, xargv); ++cnt;
	XtSetArg (args[cnt], XtNargc, xargc); ++cnt;
	top = XtAppCreateShell ((char *) NULL, class,
				dpy, args, cnt);

	 * Display the application and loop handling all events.
	XtRealizeWidget (top);
	XtAppMainLoop (app);
	return (0);

You can also try:


The AppPlusShell adds the following to the application shell:

1) Visual/Colormap control thru resources
2) EditRes built in (can be turned on/off)
3) Catches the WM_DELETE_WINDOW

	It does this thru the following added resources:

For 1:

For 2:

For 3:

	The algorithm is as follows, in this order:

1) if XtNvisualID is set try to use the visual with this id, if
it exists.

2) if XtNapplicationDepth is set try to find a visual with 
that depth, otherwise set it to DefaultDepth().  This allows 
users to have:

*applicationDepth: 24

which will be used if it exists.  applicationDepth is needed
instead of *depth, since, IMO, most users will want to do

*depth: 24 

which would screw up for any subwidgets, if there were no visual
with a depth of 24.  Note that the depth gets correctly set in the 
initialize too.

3) if XtNvisualClass is set then find the visual with the that
class and the greatest depth.

4) if all else fails use the default visual/default depth.

5) if we the visualID == default visual id, and XtNusePrivateColormap
is FALSE, then use the default colormap, otherwise, create an
appropriate one.

	There only other thing of interest is if you define MOTIF
the code uses some Motif functions instead of their X/Xt
equivalents, but otherwise should work with pretty much any
Xt widget set.

	I use a version of this code in our product, and so it has
been used on just about every major U*x platform with success.

Subject: 5.  Which visual should an application use?

This is a point that can be argued about but one opinion is there is
no way for an application to know the appropriate visual -- it has to
be specified by the user.  If you disagree with this then your
application probably falls into the category of always using the
default visual or it is hardware specific and expects some particular
visual such as 24bit TrueColor with an OverlayPlane extension (or some

Why?  No application runs in isolation.  Depending on the way a server
allocates resources I may not always want your application to run in
TrueColor mode if it is going to mess up my other applications.  I may
be very upset if it chooses to run in GreyScale instead of PsuedoColor
or just monochrome.

As an example, on a low end color Sun server there are many different
possible visuals: monochrome, 256 entry colormap, static gray, static
color, and a 3/3/2 TrueColor.  The SGI Iris's offer all the above 
plus 12 bit TrueColor, 24 bit TrueColor, an Overlay Plane.

Subject: 6.  Why do only Shell widgets have a Visual?

This is strictly by convention.  It makes it possible for an arbitrary
widget to know that the visual it uses can be found by looking for the
shell widget that is its ancestor and obtaining the visual of that

A widget can have its own visual resource.  If it does, it must have
its own realize method to use the visual when it calls
XCreateWindow().  You should also make this a resource that can be
obtained with XtGetValues() so other widgets can find it.  A
reasonable value is probably XtNvisual.

Subject: 7.  Which visual, depth and colormap do Shells inherit?

The default value for these resources are set to CopyFromParent.  This
is interpreted as the DefaultColormapOfScreen(), DefaultDepthOfScreen()
and the default visual of the screen if the widget has no parent -- i.e.
it is an applicationShellWidgetClass and the root of your widget tree.

If the parent of the widget is not null, then the shell copies
colormap and depth from its parent and uses CopyFromParent as the

Subject: 8.  I've done all the above and I still get a BadMatch error.  Why?

Some resource converters improperly cache references.  This was
especially true of X11R3 and earlier versions of Motif.

Subject: 9.  Why doesn't my widget get destroyed when I call XtDestroyWidget()?

See section 2.8 of the Xt specification.

It eventually does get destroyed, just not immediately.  The
Intrinsics destroy a widget in a two-phase process.  First it and all
of its children have a flag set that indicate it is being destroyed.
It is then put on a list of widgets to be destroyed.  This way any
pending X events or further references to that widget can be cleaned
up before the memory is actually freed.  The second phase is then
performed after all callbacks, event handlers, and actions have
completed, before checking for the next X event.  At this point the
list is traversed and each widget's memory is actually free()'d, among
other things.

As some further caveats/trivia, the widgets may be destroyed if the
Intrinsics determine that they have no further references to the
widgets on the list.  If so, then the phase 2 destruction occurs
immediately.  Also, if nested event loops are used, widgets placed on
the destroy list before entering the inner event loop are not
destroyed until returning to the outer event loop.

Subject: 10. How do I exit but still execute the DestroyCallbacks?

The problem is if a simple and entirely reasonable approach to exiting
an application is used, such as calling exit() directly, then a widget
may not have a chance to clean up any external state -- such as open
sockets, temporary files, allocated X resources, etc.  (this code for
simplicity reasons assumes only a single toplevel widget):

	ToplevelGet (gw)
		Widget		gw;		/* widget to find toplevel */
		Widget		top;

		for (top = gw; XtParent (top); top = XtParent (top))
			/* empty */;
		return (top);

	ExitCallback (gw, closure, call_data)
		Widget		gw;		/* widget */
		XtPointer	closure;	/* data the app specified */
		XtPointer	call_data;	/* widget specific data */
		Widget		toplevel;

		toplevel = ToplevelGet (gw);
		XtUnmapWidget (toplevel);	/* make it disappear quickly */
		XtDestroyWidget (toplevel);
		exit (0);

One can see that the above code exit's immediately after destroying
the toplevel widget.  The trouble is the phase 2 destruction may never

This works for most widgets and most applications but will not work
for those widgets that have any external state.  You might think that
since it works now it will always work but remember that part of the
reason an object oriented approach is used is so one can be ignorant
of the implementation details for each widget.  Which means that the
widget may change and someday require that some external state is
cleaned up by the Destroy callbacks.

One alternative is to modify ExitCallback() to set a global flag and
then test for that flag in a private event loop.
Or try the following code:


	extern Widget ToplevelGet (
	#if NeedFunctionPrototypes
		Widget		gw

	extern Boolean ExitWorkProc (
	#if NeedFunctionPrototypes
		XtPointer	closure

	extern void ExitCallback (
	#if NeedFunctionPrototypes
		Widget		gw,
		XtPointer	closure,
		XtPointer	call_data

	ToplevelGet (gw)
	Widget		gw;		/* widget to find toplevel */
		Widget		top;

		for (top = gw; XtParent (top); top = XtParent (top))
			/* empty */;
		return (top);

	ExitCallback (gw, closure, call_data)
	Widget		gw;		/* widget */
	XtPointer	closure;	/* data the app specified */
	XtPointer	call_data;	/* widget specific data */
		Widget		toplevel;

		toplevel = ToplevelGet (gw);
		XtUnmapWidget (toplevel);	/* make it disappear quickly */
		XtDestroyWidget (toplevel);
		XtAppAddWorkProc (XtWidgetToApplicationContext (gw),
				  ExitWorkProc, (XtPointer) NULL);

	ExitWorkProc (closure)
		XtPointer	closure;
		exit (0);

ExitCallback() adds a work procedure that will get called when the
application is next idle -- which happens after all the events are
processed and the destroy callbacks are executed.

Subject: 11. How do I resize a Shell widget?

After it is realized, one doesn't resize a Shell widget.  The proper
thing is to resize the currently managed child of the Shell widget
using XtSetValues().  The geometry change is then propagated to the
Shell which asks the window manager which may or may not allow the
request.  However, the Shell must have the resource
XtNallowShellResize set to True otherwise it will not even ask the
window manager to grant the request and the Shell will not resize.

To change the position of a Shell, use XtSetValues() on the Shell, not
the child, and within the limits of the window manager it should be granted.

Subject: 12. Why can't XtAppAddInput() handle files?

It does, however Unix semantics for when I/O is ready for a file does
not fit most peoples' intuitive model.  In Unix terms a file
descriptor is ready for reading whenever the read() call would not
block, ignoring the setting of optional flags that indicate not to
block.  This works as expected for terminals, sockets and pipes.  For
a file the read() will always return but the return indicates an EOF
-- i.e. no more data.  The result is the code in the Intrinsics always
calls the input handler because it always thinks something is about to
be read.  The culprit is the select() system call or on SYSV based
OS's it is the poll() system call.

How to get around this on a Unix system?  The best approach is to use
another process to check for available input on the file.  Use a pipe
to connect the application with this other process and pass the file
descriptor from the pipe to XtAppAddInput().  A suitable program on
BSD systems is "tail -f filename".

It's rumored that select() on some systems is not _completely_
reliable.  In particular:

	- IBM AIX 3.1: this is one where it would work for a while
	  (several thousand times) and then stop until some other
	  event woke it up. This seemed to be the result of a race
	  condition in the Kernel.  IBM claims to have a fix for this.

	- Pyramid, doesn't work at all.

	- Ultrix (and possibly others where pipes are implemented as
	  sockets), wasn't completely broken, but although the writing
	  side wrote in 512 byte blocks the reading side received it
	  all broken up as if it was being put into the pipe a byte at
	  a time.  You can waste a lot of time by reading small blocks
	  (get raound it by detecting the situation and having
	  select() ignore the pipe for 10 mseconds - by then it had
	  been given the whole block).

Note that all the above descriptions used Unix terminology such as
read(), file descriptor, pipes, etc.  This is an OS dependent area and
may not be identical on all systems.  However the Intrinsic designers
felt it was a common enough operation that it should be included with
part of the toolkit.  Why they didn't also deal with signals at this
point I don't know.

Subject: 13.!What good books and magazines are there on Xt?

I have a favorite that is the definitive reference.  To my perspective
it offers a reasonable introduction but also goes into the full
details of the Intrinsics.  When I started using it I was already
familiar with Xt and the concepts behind it, so newcomers may or may
not find it useful.  I've always found it accurate and complete, which
means it's 1000 pages.

Asente, Paul J., and Swick, Ralph R., "X Window System Toolkit, The
	Complete Programmer's Guide and Specification", Digital Press,
	1990, ISBN 1-55558-051-3, order number EY-E757E-DP; and by
	Prentice-Hall, ISBN 0-13-972191-6. Also available through DEC
	Direct at 1-800-DIGITAL.

The other book I commonly recomend to novices is:

Young, Doug. "The X Window System: Applications and Programming with
	Xt (Motif Version)," Prentice Hall, 1989 (ISBN 0-13-497074-8).
	(ISBN 0-13-972167-3)

And of course O'Reilly has an entire series of manuals on X and Xt.
O'Reilly ordering is 800-998-9938.  In particular, Volume 5 is an Xt
reference done in manual page style.  The 3rd edition is extensively
overhauled and goes far beyond the MIT manual pages.  I'm finding it
very useful.  In particular, the permutted index and references to
other manual pages help a great deal in chasing down related

I read two periodicals, "The X Resource" and the "The X Journal".
These are the only two dealing specifically with X.  "The X Resource"
is published quarterly, by O'Reilly, with one of the issues being the
MIT X Consortium Technical Conference Proceedings.  There is no
advertising.  I've found it informative with pretty good depth.  For
orders, call 1-800-998-9938, or email  For editorial
matters, email  Table of contents are posted at in ~ftp/pub/tex/bib in TeX form and on in
~ftp/published/oreilly/xresource in ASCII form.

"The X Journal" is a bimonthly trade rag with lots of advertising.
The articles are informative and oriented toward a less technical
audience.  I read it more to see what's going on then with an
expectation of learning a great deal (but remember, I represent a
fairly small percentage of people).  Also, they have a pretty good
collection of people on the advisory board and as columnists.  Call
(908) 563-9033.

For German readers try:

	Brede "Programmieren mit OSF/Motif"
	Addison-Wesley, Germany (ISBN 3-89319-211-5)

It is a book which introduces Xt technics with motif widgets from an
applications programmers point of view (no widget design stuff).

Subject: 14. What Widgets are available?

There are three popular widget sets:

Athena	- The set provided with X11.  This is sufficient for most
	  purposes but is on the ugly side.  Recently, a 3d look is
	  available for ftp on file://
Motif	- From OSF available for a license fee and commonly shipped on
	  many workstation vendors platforms (almost everyone but
	  Sun).  It looks good and works well but personally I think
	  it is poorly implemented.
OLIT	- The Open Look Intrinsics Toolkit is a set of widgets
	  implementing Sun's Open Look specification.  Developed by
	  AT&T.  I've never used it so can't comment on its quality.
	  I've heard rumours that it is a pain to actually get.

In addition the following collection of widgets are also available:

Xtra	- a library of widgets for sale from Graphical Software
	  Technology (310-328-9338).  It includes bar graph, stacked
	  bar graph, line graph, pie chart, xy plot, hypertext, help,
	  spreadsheet, and data entry form widgets.  I've never seen
	  them so I can't comment.
FWF	- The Free Widget Foundation is attempting to collect a set of
	  freely available widgets.  Included are a Pixmap editor,
	  FileDialog, and a few others.  The current set of widgets
	  can be obtained via anonymous ftp from the machine ( in the file pub/fwf.shar.Z.
Xcu	- The Cornell University widgets from Gene Dykes.  One of the
	  early widget sets released.  Provides a nice appearance for
	  buttons and has a mini command language.  Probably not so
	  widely used.
Xs	- The Sony widget set.  This was around during R3 days but
	  seemed to disappear.  It looked like it had promise.
Xw	- The HP widgets.  The precursor to Motif.  Originally written
	  for R3 there exists diffs to get it to work under R4 & R5.
	  Again, a pretty good widget set but has more or less died.
	  The precursor to this was the Xray toolkit which was
	  originally implemented for X10R4 and apparently provided
	  much experience for the designers of Xt.
Xo	- A widget set I'm working on.  It's still primitive but you
	  can give it a try in*

The following specialized widgets are also available:

Tbl	- Implements a tabular layout of widgets.  Supports Motif
	  widgets as children.  Part of Wcl.
Plots	- The Athena Plotting widgets (not the Athena widgets).
	  Contact or joe@Athena.MIT.EDU.

John L. Cwikla ( posts an FAQ list that contains freely
available widgets; it is in:


	A much more exciting version of this FAQ, complete with pictures,
links, and more complete documentation is available at

Subject: 15. What alternatives to the Intrinsics are there?

	Name		Language	Vendor
	Xview		C		Sun
	OI		C++		ParcPlace
	Interviews	C++		Stanford
	Tcl/tk		C

However much I like C and admire the skill in both designing and
implementing the Intrinsics, hopefully some alternative will develop
in the next 3-5 years that uses an object oriented language.  Keep

Section 1 of 4 - Prev - Next
All sections - 1 - 2 - 3 - 4

Back to category FAQ on different themes - Use Smart Search
Home - Smart Search - About the project - Feedback

© | Terms of use