Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Advice on an approach to a problem

Reply
Thread Tools

Advice on an approach to a problem

 
 
Pinnerite
Guest
Posts: n/a
 
      05-16-2013
I make great use of a 'C' program written by someone else. It works
invisibly but creates files named by itself. I would like to grant the user
the option to create their own filenames and the paths for the created
files.

My question is in which environment to tackle this: C or C++?
I have not programmed for some time but keep up to date as best I can. I
have a limited experience in using OO languages but I do not want to devote
myself into becoming an expert in either language just getting to grips with
the bits that I need for this exercise.

I should add that this is a Linux exercise.

Any suggestions? TIA

--
__________________________________________________ _

Mageia 2 for x86_64, Kernel: 3.4.34-desktop-1.mga2
KDE version 4.8.5 Running on an AMD 4-core processor

 
Reply With Quote
 
 
 
 
Jorgen Grahn
Guest
Posts: n/a
 
      05-16-2013
On Thu, 2013-05-16, Pinnerite wrote:
> I make great use of a 'C' program written by someone else. It works
> invisibly but creates files named by itself. I would like to grant the user
> the option to create their own filenames and the paths for the created
> files.


Careful with the terminology. "path" and "filename" are almost
synonyms.

Programs (in Unix) which hardcode the output paths do indeed suck.
There are a few better design choices, assuming the program needs to
generate more than one file:

% foo # creates files in current directory
% foo --src bar.c --hdr bar.h
# the number of files is small and known
% foo --dest /tmp/bar/
# create /tmp/bar/ if needed and leave any files there
% foo --prefix /tmp/bar
# files are called bar.01, bar.02, ...

And others. You don't say what the program does, and it's hard to guess.

> My question is in which environment to tackle this: C or C++?


C, of course. Why would you add an extra work load by porting it to
C++? It's not as if C cannot write to files.

Followup set.

> I have not programmed for some time but keep up to date as best I can. I
> have a limited experience in using OO languages but I do not want to devote
> myself into becoming an expert in either language just getting to grips with
> the bits that I need for this exercise.


You don't need to learn OO for this.

> I should add that this is a Linux exercise.


/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
 
 
 
Jens Thoms Toerring
Guest
Posts: n/a
 
      05-16-2013
In comp.lang.c Pinnerite <(E-Mail Removed)> wrote:
> I make great use of a 'C' program written by someone else. It works
> invisibly but creates files named by itself. I would like to grant the user
> the option to create their own filenames and the paths for the created
> files.


> My question is in which environment to tackle this: C or C++?
> I have not programmed for some time but keep up to date as best I can. I
> have a limited experience in using OO languages but I do not want to devote
> myself into becoming an expert in either language just getting to grips with
> the bits that I need for this exercise.


If the program is already written in C and you just want to
modify it a bit then it would seem to me that using C for that
would make most sense - why add another language to the mix?

On the other hand, if all you want is to allow the user to
specify some file name(s) to be used instead of the one(s)
used by the program per default for its output a much simpler
solution might be to write a small wrapper script that accepts
the user defined file name(s), runs the original program and
then renames the file(s) produced by the program to what the
user prefers. While that could be done using C or C++ a simple
scripting language would be perfectly suitable to get such a
rather trivial job done with a few lines of code.

Regards, Jens
--
\ Jens Thoms Toerring ___ http://www.velocityreviews.com/forums/(E-Mail Removed)
\__________________________ http://toerring.de
 
Reply With Quote
 
Pinnerite
Guest
Posts: n/a
 
      05-16-2013
Pinnerite wrote:

It appears that I was not clear as to what I want to do.

At the point where the output file is prepared, I want both a data entry box
for the user to enter or even edit a prototype filename and a dropdown
directory listbox enabling the user to browse it in order to select their
desired destination. I cannot remember the correct terminology for the
widgets, sorry.

Accepting that 'C' is appropriate, I guess it boils down to which library
and IDE would serve me best.

Regards


>

--
__________________________________________________ _

Mageia 2 for x86_64, Kernel: 3.4.34-desktop-1.mga2
KDE version 4.8.5 Running on an AMD 4-core processor

 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      05-16-2013
On Thu, 2013-05-16, Pinnerite wrote:
> Pinnerite wrote:
>
> It appears that I was not clear as to what I want to do.
>
> At the point where the output file is prepared, I want both a data entry box
> for the user to enter or even edit a prototype filename and a dropdown
> directory listbox enabling the user to browse it in order to select their
> desired destination. I cannot remember the correct terminology for the
> widgets, sorry.


Be careful to check that the users actually want this. You're on Unix
and you want to convert a non-interactive tool to be interactive (and
presumably have a GUI). Lots of Unix users (but not all) would
dislike such a change, e.g. if they don't use a GUI or if they need
the tool to run attended.

Today I lost half my working day to such a needlessly-interactive
tool, so I'm in that camp.

> Accepting that 'C' is appropriate, I guess it boils down to which library
> and IDE would serve me best.


The wrapper script approach someone else mentioned suddenly sounds
even better. Tcl/Tk is a decent choice -- or perhaps simply a shell
script which calls some prompt-the-user-for-a-filename utility.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
Pinnerite
Guest
Posts: n/a
 
      05-16-2013
Jorgen Grahn wrote:

> On Thu, 2013-05-16, Pinnerite wrote:
>> Pinnerite wrote:
>>
>> It appears that I was not clear as to what I want to do.
>>
>> At the point where the output file is prepared, I want both a data entry
>> box for the user to enter or even edit a prototype filename and a
>> dropdown directory listbox enabling the user to browse it in order to
>> select their desired destination. I cannot remember the correct
>> terminology for the widgets, sorry.

>
> Be careful to check that the users actually want this. You're on Unix
> and you want to convert a non-interactive tool to be interactive (and
> presumably have a GUI). Lots of Unix users (but not all) would
> dislike such a change, e.g. if they don't use a GUI or if they need
> the tool to run attended.


I am not intending to force the result on anyone else, although if it proved
successful I would of course make it available.

>
> Today I lost half my working day to such a needlessly-interactive
> tool, so I'm in that camp.


I get the point but the utility only runs each time it is called and
virtually impossible for anyone but the user to do so.
>
>> Accepting that 'C' is appropriate, I guess it boils down to which library
>> and IDE would serve me best.

>
> The wrapper script approach someone else mentioned suddenly sounds
> even better. Tcl/Tk is a decent choice -- or perhaps simply a shell
> script which calls some prompt-the-user-for-a-filename utility.


I may be shallow but if a shell script is invoked, the output would be fed
back to original utility anyway. Hardly more secure. I have to draw the line
between security and paranoia. Still I could insist on a warning message on
the packaging <G>.



>
> /Jorgen
>

--
__________________________________________________ _

Mageia 2 for x86_64, Kernel: 3.4.34-desktop-1.mga2
KDE version 4.8.5 Running on an AMD 4-core processor

 
Reply With Quote
 
Jens Thoms Toerring
Guest
Posts: n/a
 
      05-16-2013
Jorgen Grahn <(E-Mail Removed)> wrote:
> On Thu, 2013-05-16, Pinnerite wrote:
> > Pinnerite wrote:
> >
> > It appears that I was not clear as to what I want to do.
> >
> > At the point where the output file is prepared, I want both a data entry box
> > for the user to enter or even edit a prototype filename and a dropdown
> > directory listbox enabling the user to browse it in order to select their
> > desired destination. I cannot remember the correct terminology for the
> > widgets, sorry.


> Be careful to check that the users actually want this. You're on Unix
> and you want to convert a non-interactive tool to be interactive (and
> presumably have a GUI). Lots of Unix users (but not all) would
> dislike such a change, e.g. if they don't use a GUI or if they need
> the tool to run attended.


s/attended/unattended/

> Today I lost half my working day to such a needlessly-interactive
> tool, so I'm in that camp.


I'd completely support this advice - there's hardly anything more
annoying than a program insisting on using a GUI which isn't strict-
ly needed! You can't run it on a fast machine that has no X-server
running, you can't reasonably run it from a script or another pro-
gram etc.

> > Accepting that 'C' is appropriate, I guess it boils down to which library
> > and IDE would serve me best.


> The wrapper script approach someone else mentioned suddenly sounds
> even better. Tcl/Tk is a decent choice -- or perhaps simply a shell
> script which calls some prompt-the-user-for-a-filename utility.


You actually could have two wrappers - one that does the job
without a GUI and another one that has a GUI for selecting
file names with a graphical interface and then calls the non-
GUI wrapper script with those file names. For the GUI-wrapper
besides Tcl/Tk you could use e.g. Python with PyQt/PySide or
Perl with perlTk and probably many others (but which I don't
have experience with). If you use C your choices of a graphics
toolkit may prove to be rather limited, to my knowledge you
can only use either GTK or XForms with C. All others I'm aware
of are C++.
Regards, Jens
--
\ Jens Thoms Toerring ___ (E-Mail Removed)
\__________________________ http://toerring.de
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      05-17-2013
On Thu, 2013-05-16, Pinnerite wrote:
> Jorgen Grahn wrote:


>> The wrapper script approach someone else mentioned suddenly sounds
>> even better. Tcl/Tk is a decent choice -- or perhaps simply a shell
>> script which calls some prompt-the-user-for-a-filename utility.

>
> I may be shallow but if a shell script is invoked, the output would be fed
> back to original utility anyway. Hardly more secure.


I don't know what you're referring to but yes, there are problems with
leaving the original utility as it is and trying to patch it up bny
wrapping. If the original e.g. leaves its files in /tmp:

- you can't be sure noone has replaced them maliciously
- you can't be sure noone has replaced them by simply running the
utility at the same time
- the utility may have failed, and your script copies old, outdated
files
- you may have problems finding the right files to move

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Advice on an approach to a problem Pinnerite C Programming 1 05-16-2013 12:00 PM
Need design advice. What's my best approach for storing this data? Mudcat Python 9 03-21-2006 06:26 AM
Advice on best approach =?Utf-8?B?TWFubnk=?= ASP .Net 2 12-23-2004 04:03 AM
advice needed - what approach for sql access KavvY ASP .Net 1 07-17-2004 08:17 AM
Advice on design approach and principles Mr Gordonz ASP .Net 1 08-04-2003 10:08 PM



Advertisments