Derefrencing memory through varable

[Solar]

Look at him going ballistic.

-I said 4 years, not 8;

Means, at the point you started learning C, stdint.h was already part of the language for 4 years.

-I dont even have stdint in my MSVC++ 2005 compilier IDE;

I doubt that, but don't have MSVC++ 2005 at hand.

-...Nor my GCC compilier;

Bzzzzzzzzzzzzt.

(That's the bullshit alarm going off. Check /usr/include. I didn't check my Linux system, but my Cygwin GCC 3.4.4 here has it.)

-I personally never seen anyone use stdint

q.e.d. - you might want to take note that I was ranting about how many people hop around chanting "I know the language" when they don't. I wouldn't expect people to know every function, but I do expect them to know what headers there are and what they are about.

Lastly: Just because one doesnt know a specific file (as they have never used it) doesnt mean they dont know how to use the library. Your
argument is akin to saying "If you dont know this specific include
file, you dont know the Win32 API"

Your argument is akin to saying, "I know how to #include, hence I know the library."

I'll stop now.

[neon]

Look at him going ballistic.

...? For everyones sake, I am not going to comment on this statement.

Means, at the point you started learning C, stdint.h was already part of the language for 4 years.

Probably, and I really dont care too look.

(That's the bullshit alarm going off. Check /usr/include. I didn't check my Linux system, but my Cygwin GCC 3.4.4 here has it.)

I should note im using DJGPP's GCC compilier. I dont use cygwin
(anymore). [My] copy of GCC *doesnt* have the file.

q.e.d. - you might want to take note that I was ranting about how many people hop around chanting "I know the language" when they don't. I wouldn't expect people to know every function, but I do expect them to know what headers there are and what they are about.

I know; your argument was clear the first time.

However, yet again, you are still comparing a language with
a library.

Your argument is akin to saying, "I know how to #include, hence I know the library."

Um... did I mention anything related to that? #include is part of
the preprocessor, and has nothing to do in *using* a libraries methods.

To repeat, again, your argument states:

Lastly: Just because one doesnt know a specific file (as they have never used it) doesnt mean they dont know how to use the library. Your
argument is akin to saying "If you dont know this specific include
file, you dont know the Win32 API"

To add on to this: Your argument is akin to saying "If you dont
know a specific include file, you dont know the language".
You fail to destinguish the relationship between a library and
a language, which is why your entire argument doesnt hold up.

(It is okay if you say "I dont know the entire ANSI standard library".
but do not say I dont know the language)

I'll stop now.

If you are done, then I am done. This entire argument is
simply pointless.

I will, however, take a look at stdint.h.

[Kevin McGuire]

@neon:
Show me a example of a double linked list with add and remove functions for each entry in as few lines of code as possible, and if you can then add the functionality to allow the developer to externally define a object each entry will hold in what ever way you can that does not involve the developer changing you're implementation such that:


neon_dll.cc - You're implementation.
neon_dll.h - You're implementation.

myuse.cc - My code to use you're implementation with out modification to it.


And just to help you out it needs to support something like this (at least) and the actual details are up to you since we can understand what you are trying to mean if you do it differently:


dlinkedlist_create(..);
dlinkedlist_add(..);
dlinkedlist_remove(..);



If you know the language well enough this should be a 101 class in programming, in my opinion - and my opinion could be wrong so if you think what I am asking not correct then just let me know.

[neon]

std::list<>, std::vector<> or without?

That doesnt sound hard at all.

Assuming I am hearing you right:

You want a double linked list using an abstract class in a base DLL.
From there, export the symbols from the DLL, and use it in the
main source file.

Is this what you want?

[Alboin]

@neon:
Show me a example of a double linked list with add and remove functions for each entry in as few lines of code as possible, and if you can then add the functionality to allow the developer to externally define a object each entry will hold in what ever way you can that does not involve the developer changing you're implementation such that:


neon_dll.cc - You're implementation.
neon_dll.h - You're implementation.

myuse.cc - My code to use you're implementation with out modification to it.


And just to help you out it needs to support something like this (at least) and the actual details are up to you since we can understand what you are trying to mean if you do it differently:


dlinkedlist_create(..);
dlinkedlist_add(..);
dlinkedlist_remove(..);

You're = You are.
your = Something belonging to you.

If you know the language well enough this should be a 101 class in programming, in my opinion - and my opinion could be wrong so if you think what I am asking not correct then just let me know.

Your opinion is correct. It should be easy for anyone with a decent understand of programming.

Edit: Oh, put this above neon's post. Apparently, I type slow...

[Kevin McGuire]

Using only the Standard C Library even if done in C++.

[edit]

You can just write and post it. You really do not have to build or split it into a header and implementation file just a single file would be fine.

If I were to use you're linked list implemented I would do so as:
compiler neon_linked_list.c myfile.c -o executable_file

I want it as simple as possible just so posting it in this thread does not take up much room as it should not.

[Kevin McGuire]

And I will also consider how long it takes you to actually submit it. I am not being difficult, but just trying to make it as honest as possible. You should be able to complete it with-in twenty-four hours.

I can do it with in one hour. But, I have done it many many times.

And if you do it which I have very little doubt you can not do it. I will honestly cut you as much slack as I could ever give someone just because you made a effort. I think it might also help some people who also like to read the General Programming section learn more, if they do not already know about linked lists in C.

[neon]

Its done (supports DLL linkage and custom nodes for the list);
Im cleaning it up a little then Ill post the code.

It also supports custom data types through templates.

[neon]

Code:

main.cpp - Test program

Code: Select all

#pragma comment (lib, "list.lib")

#include <iostream>
#include "neon_dll.h"

class MyNode : public Node<float> {

public:
	float data;
	MyNode () : data(4.0f) {}
};

int main () {

	static MyNode	list;

	// create node; add it to list
	MyNode* pNode = (MyNode*) list.Insert (&list, 32.0f);

	// create 2 more nodes
	list.Insert (pNode, 33.0f);
	list.Insert (pNode, 34.0f);

	// find the node with value 34 and print it out
	MyNode* node = (MyNode*) list.Find (&list, 34.0f);
	std::cout << node->GetData() << std::endl;

	return 0;
}

neon_dll.h: - List header file

Code: Select all

#ifndef DLL_H
# define DLL_H

#ifdef EXPORTS
#define DLL_SPEC __declspec (dllexport)
#else
#define DLL_SPEC
#endif

DLL_SPEC template <class T> class Node {

	T			m_data;
	Node*		m_pNext;
	Node*		m_pPrev;

public:
	Node () : m_pNext (0), m_pPrev (0) {}
	virtual ~Node ();

	inline virtual T&	GetData () {return m_data;}

	Node* Find (Node* pNode, T data);
	Node* Insert (Node* pNode, T data);
	Node* Delete (Node* pNode, T data);
};

#include "ListPimp.h"

#endif

ListPimp.h - Template class implimentation:

Code: Select all

#ifndef DLL_H_PIMPL
# define DLL_H_PIMPL

#include "neon_dll.h"

template <class T> Node <T>* Node<T>::Find (Node* pNode, T data) {

	Node*	node=pNode;
	Node*	pAfter = pNode;

	// search nodes after node
	while (pAfter) {
		if (pAfter->GetData()==data)
			return pAfter;
		pAfter=pAfter->m_pNext;
	}

	// search nodes before node
	Node*	pPrev = pNode->m_pPrev;
	while (pPrev) {
		if (pPrev->GetData()==data)
			return pPrev;
		pPrev=pPrev->m_pPrev;
	}
	return 0;
}


template <class T> Node <T>* Node<T>::Insert (Node* pNode, T data) {

	// insert node at end of list
	Node*	tmp = new Node;
	tmp->m_data = data;

	if (!pNode) {
		tmp->m_pNext = 0;
		tmp->m_pPrev = 0;
		return tmp;
	}

	tmp->m_pPrev = pNode;
	tmp->m_pNext = pNode->m_pNext;
	if (pNode->m_pNext)
		pNode->m_pNext->m_pPrev=tmp;

		pNode->m_pNext = tmp;
		return tmp;
}

template <class T> Node <T>* Node<T>::Delete (Node* pNode, T data) {

	Node* tmp = pNode->m_pNext;
	pNode->m_pNext = tmp->m_pNext;
	if (tmp->m_pNext)
		tmp->m_pNext->m_pPrev=pNode;

	delete tmp;
	return pNode->m_pNext;
}

template <class T> Node <T>::~Node () {

	// delete all nodes before and after us

	Node*	tmp;
	Node*	pNext = m_pNext;
	Node*	pPrev = m_pPrev;

	// delete nodes after us
	while (pNext) {

		tmp = pNext->m_pNext;
		delete pNext;
		pNext = tmp;
	}

	// delete nodes before us
	while (pPrev) {

		tmp = pPrev->m_pPrev;
		delete pPrev;
		pPrev=tmp;
	}

	 delete this;
}

#endif

neon_dll.cpp - Compilation file for list:

Code: Select all

#include "neon_dll.h"

There probably are portability issues with some compiliers,
but this should work on any Win32 compilent compilier. (I hope)

There might be some bugs in it; please tell me if you see any problems

After this thread, I dont think I would want to make any more silly
mistakes anymore (Serously now, this thread is getting ridiculus)

[Alboin]

After this thread, I dont think I would want to make any more silly mistakes anymore (Serously now, this thread is getting ridiculus)

Nothing personal, or anything, but you made two mistakes in your 'no mistakes anymore sentence'. You misspelled 'seriously' and 'ridiculous' wrong. Kind of ironic...

[neon]

Nothing personal, or anything, but you made two mistakes in your 'no mistakes anymore sentence'. You misspelled 'seriously' and 'ridiculous' wrong. Kind of ironic...

lol - ironic indeed; sorry about that

[Kevin McGuire]

It looked really great except for the deconstructor which is:

Code: Select all

template <class T> Node <T>::~Node () {

   // delete all nodes before and after us

   Node*   tmp;
   Node*   pNext = m_pNext;
   Node*   pPrev = m_pPrev;

   // delete nodes after us
   while (pNext) {

      tmp = pNext->m_pNext;
      delete pNext;
      pNext = tmp;
   }

   // delete nodes before us
   while (pPrev) {

      tmp = pPrev->m_pPrev;
      delete pPrev;
      pPrev=tmp;
   }

    delete this;
}

Where you will double delete list items by delete calling the deconstructor for the linked list item which deletes the next and so on when finally control returns and the previous deconstructor in the call stacks attempts a double delete.

Calling delete on a de-constructing object is not a really good idea, since it has for a reason started a deconstruction phase.

Code: Select all

template <class T> Node <T>::~Node () {
   // delete all nodes before and after us
   Node*   tmp;
   Node*   pNext = m_pNext;
   Node*   pPrev = m_pPrev;

   // delete nodes after us
   while (pNext) {

      tmp = pNext->m_pNext;
      pNext->m_pNext = 0;    /// prevents double delete.
      pNext->m_pPrev = 0;    /// prevents double delete.
      delete pNext;
      pNext = tmp;
   }

   // delete nodes before us
   while (pPrev) {

      tmp = pPrev->m_pPrev;
      pPrev->m_pNext = 0;     /// prevents double delete.
      pPrev->m_pPrev = 0;     /// prevents double delete.
      delete pPrev;
      pPrev=tmp;
   }

    //delete this;                   /// The deconstructor was called because of
                                         /// a delete call to this object already.
}

Other than that it satisfied me. Nice work too. I do not think I could have done much better.

...(Serously now, this thread is getting ridiculus)..

No way dude. We are teaching you to remember to not try to deconstruct a already deconstructing object in C++.

[neon]

I didnt see that error; thanks for pointing it out!

Other than that it satisfied me. Nice work too. I do not think I could have done much better.

Thanks!

No way dude. We are teaching you to remember to not try to deconstruct a already deconstructing object in C++.

Deleting the this ptr in the destructor wasnt the best idea I see