By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,605 Members | 1,473 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,605 IT Pros & Developers. It's quick & easy.

Implementing an I/O wrapper and Parser (console project)

P: n/a
Hello everyone,

I'm wanting to start implementation of a pet project game IO mechanism.

The game is console based. A cross between MUD and Rogue types. For I/O
operations I'll be using ncurses (PDCurses to be accurate). Mainly
taking advantage of colors in the console and wanting to minimize any
work in porting it to Linux and Mac.

What I'm thinking doing is designing two singletons CPrompt, CParse.

CPrompt - responsible for I/O operations. It wraps ncurses
functionality, accepts input from the user, sends to CParse. Receives
input from various objects and formats to screen.

CParse - Parses commands, returns error or sends to correct objects for

Various objects (the game engine) - Receive processing requests from
CParse and send results back to CPrompt for output.

However, I'm not sure of this design on a few points:

1. CPrompt is supposed to wrap ncurses functionality, but by having
the various object communicate directly to it, I'll be forced to provide
ncurses functionality on the objects themselves. Or probably complicate
my code by sending to CPrompt also the output format requirements. What
do you suggest?

2. CParse seems to be doing too much; parsing the input and deciding
on which objects to call. Is it better to provide some form of messaging
system between CParse and the objects? And how would this be
implemented. Links to reading material (books or web) would be enough if
you don't want to spend much time discussing this point.

3. By making CPrompt and Cparse singletons I'm thinking on the need
of having these two object in memory at all times. There is of course
only one prompt. But CParse is less obvious as a good candidate for a
singleton class. It's the fact that it will be staying in memory at all
times that moves me into making it a singleton. However, should it be
ever-present? Is it more logical to have it be destroyed after each
I would appreciate your help on this. Understanding the programming
language is becoming less of a challenge as time moves on, but applying
this knowledge is the real challenge.

Best regards.
Nov 10 '06 #1
Share this question for a faster answer!
Share on Google+

This discussion thread is closed

Replies have been disabled for this discussion.