Re: General tree assignment in C



On Feb 1, 9:27 pm, kwikius <a...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
On Feb 1, 6:32 pm, Ed Prochak <edproc...@xxxxxxxxx> wrote:

On Feb 1, 2:53 am, kwikius <a...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

<...>

The above path is a relative path. An absolute path requires a node
that the relative path is applied to.

implementation detail.

You lost me. Which part is an implementation detail ?

Pathnames. Perhaps the UI is a GUI and you browse a directory
graphically. Never used the Expolre option in MS Windows? and the
equivalent in some other GUIs? Pathnames are an implementation of the
user interface.

<...>

There is no absolute need for polymorphic structures here. A leave is
merely a node with no children.

A directory can be empty
I hope you dont want "change_to_working_directory(file) to succeed?

Functionally you do have to treat them
differently.

They have some things in common too... "Polymorphic" :-)

True, but this is a imperative programming assignment (in C which does
not support poly morphic functions)

OOP is not the only programming model in existance.

<...>

Finally some means to represent a path. For simplicity a list of
strings works well

No it does not for this assignment.

List of strings seems relatively trivial in C...

Assuming you use a pathname you don't need a LIST of strings, you just
need ONE string and a simple parser.


#include "stdio.h"

struct path{
char ** path_list;
int num_elements;

};

int main()
{
char * path_list[] ={"my","projects","hello.cpp"};

struct path my_path;
my_path.path_list = path_list;
my_path.num_elements = 3;

All of this information has to be obtained programmatically. A little
parser will do just fine on a single string.


<...>

... Whatever...

what you should have shown is how to create that list of strings from
the pathname. But the list is unnecessary. a directory stack will
work.

In C the vast proportion of your time will be spent implementing what
other languages provide as standard rather than solving the actual
problem.

<...>

This is a school assignment. the OP must use C so your > tooting the horn of C++ is not helpful.

Toot! Toot ! ... compiler may be a C++ compiler also.

:-)

Get it thru your head that C is NOT C++, even if you happen to use a
command name that looks on the surface to be the same.

The Pathname is only an artifact of the user interface, NOT an
inherent properety of file systems.

Users can always migrate to rival system with a nice UI I guess...

(Have you ever worked on a flat
file system?)

The spec describes a hierarchical file-system.

The point was to determine what range of experience you have. The idea
was to point out not all File systems use directories. The implication
is that pathnames are not always used.


regards
Andy Little

Have a good day.
Ed
.



Relevant Pages

  • Re: portable pathname construction tools anywhere?
    ... > I was unable to find a set of tools that handles dealing with ... > filenames and pathnames correctly. ... You could try to first convert the strings into pathnames, ...
    (comp.lang.lisp)
  • Re: portable pathname construction tools anywhere?
    ... >> I was unable to find a set of tools that handles dealing with ... >> filenames and pathnames correctly. ... > You could try to first convert the strings into pathnames, ...
    (comp.lang.lisp)
  • Re: Checking to see if a name is in use
    ... |> it is best to eschew the use of strings and to use pathname objects. ... you'd want:ABSOLUTE or:RELATIVE in specifying the:DIRECTORY argument ... "getting pathnames", after grappling a bit with an idiosyncratic ...
    (comp.lang.lisp)
  • Re: DIRECTORY behavior with /= implementations
    ... mapping between ext2/ext3 file systems and CL pathnames, ... I think that might be a nice CDR proposal, ... und ganz sicher sind *SIE* hinter uns her und wollen uns Qt und KDE ...
    (comp.lang.lisp)
  • Re: DIRECTORY behavior with /= implementations
    ... mapping between ext2/ext3 file systems and CL pathnames, ... clisp do write its binary files always in little ...
    (comp.lang.lisp)