Yes it is possible.
In fact the only justification for the continued existence of C++/CLI is that you can integrate standard C++.
[EDIT] This is just my humble opinion. Why? If you want to use managed code then you are better off using C#, because it's syntactially simpler and spares you some of the problems that standard C++ poses...

Visual Studio 6 is not a very good choice of compiler. It is not standard compliant and has many weird snags. A better choice would be VS2005 if you have it. If your source code is from a pre VS6 aera I would expect major problems with MFC API. A lot has changed since. Depending how well the code was written you should be able to migrate the "pure C++2 parts of the DLL/Program, but it's still some feat. As to what kinds of DLL there are? Strictly speaking one, but depending on your compiler/linker options you can change how the DLL is used. MFC (GUI) components, COM-component, ... If you unsure what your current DLL's settings are then you might want open the project with the original compiler and copy the settings and then replicate them when you create the new DLL.

Microsoft has not the best record on backwards compatibility, but you should be able to compile an older project with a newer compiler without too much problem.
Depending on the version of Visual Studio you should have a migration wizard. You should use that to migrate your project file to the new version.
Then you should do a re-compile of all sources in your project. Just a compile won't do. Switching off the pre-compiled headers was a smart move. You cannot use pch of a 16bit version with a 32bit version. The errors you get should give you a clue as to what went wrong. It might be, that you have not set the proper include paths in your project? That's an easy fix. Also there are some headers that have a changed name, like "xyz.h" was changed to "xyz32.h" or so. Make sure your project paths exclude paths of your original installation and only include paths of your current version of VS. Once you've done that you'll see more meaningful errors because now the symbols,definitions etc from the old version are no longer available for your project, so anything that has changed name/parameters/was deprecrated will now flag as such. Then you gotta look for headers/libraries in your new installation directory to include and link the right files. If you need more help then you need to post the errors you are getting.
Hope that kicks you off.

What I said in my previous still needs sorting out in your code, but there is also another problem.
[CODE]
t = new node;
t->str = new char[20]; // 1.
t->item = s->item;
t->str = "Priya"; // 2.
t->next = NULL;
p = t;
[/CODE]

This is NOT what you actually want. You create an array of 20 new characters and assign them to your pointer str in line 1. In line 2. you re-assign the pointer to have the address of the constant character array "Priya". You lost all reference to the newly created 20 characters effectively creating a memory leak. Worse yet: Had you created a proper destructor for your node class then you would eventually try to delete this constant string, which would make your program crash.
What you want to do here is to use [B]strcpy()[/B] function to copy the string "Priya" into your allocated 20 characters.
[CODE]strcpy(r->str,"Priya");[/CODE] or sth like that.
But you should also not forget to create the 4 methods as stated in my previous post.

The first error comes from you having SavedClass as a parameter of
[code]
void LoadState(SavedClass &Save, long SavedLength, bool type);
[/code]
You might be able to get rid of this error by forward declaring class SavedClass.
Add:
[code]
class SavedClass;
[/code]
before the definition of class InputClass and this error will probably disappear.
The third Error is likely to be a typo: Saved instead of SavedClass.

Mind you: In general it is not a good idea to force everything into classes. There are many instances where this leads to bad code. It's ok as a homework-project to force you to think about encapsulation, but in real-life applications you should use the whole spectrum of tools that C++ offers you:

  • templates
  • metaprogramming
  • preprocessor instructions (use VERY sparingly!!! There usually is a much better alternative to #defines!! But for certain things like debug/build instructions they are useful)
  • members and non-members/operators of a class
    ...
commented: Helpful +0

In a way that's the only way to read from disk. If you are interested in how to do file I/O manually then I suggest you get familiar with the C++ functions fput, fget, fseek, etc. If you are asking whether sth like double* pDbl can be made to point to a location on the hard-drive then normally no. Pointers point to the programs memory space, but I'm pretty sure with some hackery you could force it to point to storage. Why would you want to do that, though? a pointer is normally a 4-byte word on 32-bit-machines and a 8-byte word on 64-bit-machines. the addressable storage with those pointers would be rather too small for todays hard-drives of a terra-byte size or so.
with a pointer you could only access a fraction of that.

You can do exactly the same in C++:
in test.h
[code]
class Test
{
public:
static int myArray[10];
}
[/code]

in test.cpp
[code]
int Test::myArray[10] = {0}; // the = {0} is not neccessary, but good practice as it initialises the array with zeros
[/code]

You declare the array in your class declaration but you have to define int once outside the class.