To prevent rendering you'll need a null renderer To capture images from the graph you'll need ISampleGrabber (or a variant) Source Filter -> ISample Grabber -> Null Renderer If you're looking for a simple way to do this, have a look at OpenCV (Intel's Open Computer Vision Library) hosted on sourceforge - you should be able to borrow or modify enough of their code to get started.

Use a C++ type which is dynamically expandable,std::string s; std::cin >> s;
Which will be fine unless you have whitespace in the name, and then you would need something like (this would have been a problem with the exising code as well):std::string s; std::getline(cin,s);
If you wanted to get really fancy you could also use an istream_iterator, but for examples this simple I don't think it really buys you anything.

No, because TCP is a streaming protocol. Because TCP is reliable (in-order and reliable), you can however wait until you have read a certain number of bytes and then assume that is one 'packet'. For fixed size packets this means you end up with something like read( packet, sizeof(Packet) ) read( packet, sizeof(Packet) ) And for variable size packets: read( packetsize, sizeof(long) ) read( packet, packetsize) read( packetsize, sizeof(long) ) read( packet, packetsize) As an aside, ::send() and ::sendto() are generally used for UDP, whilst TCP normally only uses ::send()

It depends... Ryan gave a good answer, in ideal [single threaded] circumstances you should choose to use the single threaded crt libraries. rules of thumb * If there is any chance that in the future any part of the project may be multithreaded I recommend setting the options for the project to use the multi-threaded libraries. From past experience, it's easier to tell everyone else on the team what the setting should be rather than trying to let them figure it out (or change it) on their own. * If any of your dependancies are distributed as binaries linked against a particular crt, you MUST link against the same type. * If you don't want to distribute any .dll's with you product, statically link to the crt.

You really don't want to be doing this - it's asking for trouble. You'd be much better using something like boost::shared_ptr in the vector rather than raw pointers - then, if required you can pass custom deleters into the function. Below is an example of a template function which does what you requested. Depending on usage the call to clear() may be redundant, or may not do what you expected.template<class T> void cleaner(std::vector<T>& v) { typedef typename std::vector<T>::iterator iter; iter cur(v.begin()); iter end(v.end()); for(; cur != end; ++cur) { delete (*cur); } v.clear(); }

EDIT: fixed typo

LiamD wrote: I don't have a Clean option. Any suggestions? 'Clean Solution' is the third item in the build menu in a default install of Visual Studio 2003. If it isn't in the right place try customising your menus / toolbars

Add only to your repository files that you can't recreate. To check, do a 'clean solution' before you start adding files. For more information on what each file extension signifies check msdn. If you are unsure whether a file type is binary, try opening it in a text editor - however wincvs is pretty smart and most of the time it will autodetect the correct settings. As a starting point, you should consider adding the following types as text: *.sln *.vcproj *.cpp *.cxx *.c *.h *.hpp *.hxx *.rc *.rc2 And the following types as binaries: *.ico *.bmp (and other image types) You can safely ignore: *.obj *.exe *.dll *.lib *.pch *.ncb *.suo *.idb *.pdb *.bsc *.ilk

How about using a serialization library? Boost::Serialization supports text, binary and xml as output targets, and is pretty simple to use. TinyXml Is a nice small library that has picked up a fair ammount of popularity. Xerces To my way of thinking was pretty bloated, but if you need your output to support almost everything in the XML standard (especially different encoding schemes) this is the way to go.

Beej's Guide to Network Programming is the standard reference for *nix programmers learning sockets, but it is still very relevant for windows programmers as well - not to mention being far better laid out than the winsock faq

Anonymous wrote: Is there a MFC equivalent in .Net? Yes and No. MFC is still distributed with VC.NET2003 (depending on which edition you get), so MFC is an option, even if all it does is give you access to an improved compiler. As for the alternatives to MFC - Windows Forms is the .NET equivalent. To take a guess, you looked at the code and it looked to simple compared to what MFC provided. Doc/View SDI/MDI are now so simple to achieve that Microsoft don't worry about them in the fashion that they used to - no more wizards, no more chunks of code that are labelled 'DO NOT EDIT'. If you do need to emulate the MFC styles of interface it's not hard at all. If you need large GUI's are you sure that you need to be writing them in C++? Microsoft now recommend that C# is an acceptable alternative in many cases and it simplifies the coding even further. If you need to access legacy code previously written in C++ you can wrap it in managed extensions or COM objects.

ahz wrote: The way to call one constructor from another is to use "placement new". This is incorrect. Herb Sutter - the current chairman of the C++ standards committee described this 'anti-idiom' as 'an abomination' and 'abhorrent' in the article 'delegating constructors' C/C++ Users Journal May 2003. For any data members that are not POD, this approach will fail, because the destructor of that data members will run only once, while the constructors will have run twice To the initial poster. The only way to solve this problem is with an initialization function, but you must also ensure that that function is not virtual.

DirectShow supersedes Video For Windows, with a very few exceptions - a very small number of the AVI functions from memory. If you need help on issues this specific to DirectShow it may be better to contact a more specific forum. I've found DirectXAV to be very helpful in the past. Microsoft have also announced that DirectShow support will be deprecated in the near future and a new improved multi-media API will be made available. From what I can remember it's on a similar timescale to avalon, I'm not sure what will happen to VfW support when this happens.

Easy, add an extra level of redirection to manage the lifetime. This issue is described as Stateful Predicates in the book Exceptional C++

#include <algorithm>
#include <vector>
#include <iostream>

using namespace std;

class ProcessVector
{
public:
	ProcessVector()
	{
		cout << "ctor" << endl;
	}
	~ProcessVector()
	{
		cout << "dtor" << endl;
	}
	void operator ()(int i)
	{
		cout << i << endl;
	}

    ProcessVector(const ProcessVector &rhs)
	{
		cout << "copy ctor" << endl;
	}
};

class ProcessVectorIndirect
{
public:
    ProcessVectorIndirect(ProcessVector* process)
        : pProcess(process)
    {
    }

	void operator ()(int i)
	{
		(*pProcess)(i);
	}

private:
    ProcessVector* pProcess;
};

int main(int argc, char* argv[])
{
	std::vector <int> test;
	for (int i = 0 ; i< 5; i++)
		test.push_back(i);
	
        ProcessVector vect;
	for_each(test.begin(), test.end() , ProcessVectorIndirect(&vect) );

	return 0;
}

They all have slightly different performance specifications and operations which make them suitable for different tasks. std::vector is a dynamic array std::list is a doubly linked list std::deque is a hybrid container which is like a list of vectors (from memory) By default, use a vector. If you need to add to the front and the back, use a deque. If you need to be able to insert/remove efficiently from the middle of a container, and never need random access use a list.

As far as I know, this isn't possible. Static linking implies that all code be known and identified at link-time, static linking is effectivly dynamic linking with hidden 'glue' that uses staticly bound stubs to dispatch to the dll. This is possible and very simple to do with dynamic linking provided your class heirarchy supports it.

There are some great free controls on codeproject for this, much simpler than doing your own. NTGraph 2D NTGraph 3D

You've got lots of choices, but it depends on what dependancies you can afford to introduce into your software. If you already have the reports in access how about using access via the COM automation interfaces. Alternatively word automation is probably easier to get started with, especially if you want to construct temporary html files and then load them in word, or use ShellExecute api to print. If clients can't be guaranteed to have office you could also use IWebBrowser2 and related interfaces (perhaps IHTMLWindow3) to provide a low dependancy (only the standard internet explorer control) printing method - I haven't used this approach but I don't see it being too hard. Another report generation idea is to convert the results of queries to xml and then use xslt as a flexible and extensible formatting system. Alternatively MFC has extensive documentation on printing.

If you can keep you head when all about you Are losing theirs and blaming it on you; If you can dream - and not make dreams your master; If you can think - and not make thoughts your aim; Yours is the Earth and everything that's in it. Rudyard Kipling

std::ifstream isn't designed to allow the reading of the entire filesize. The function _filelength in <io.h> will give you the length of a file. Be warned that this function is limited to the size of a long, so for very large files you'll need to use a platform dependant API (See MSDN). The following function taken from the boost::regex sample code (regex_grep_example1.cpp) is one example of how to efficiently and safely allocate space using std::string. This is not the simplest solution, it is flexible. However without profiling this is micro-optimisation that probably isn't going to help. Note the use of reserve and capacity to ensure appropriate growth system for you buffers. You may be able to tweak initial size and growth rates if you know roughly what size the file will be.void load_file(std::string& s, std::istream& is) { s.erase(); if(is.bad()) return; s.reserve(is.rdbuf()->in_avail()); char c; while(is.get(c)) { if(s.capacity() == s.size()) s.reserve(s.capacity() * 3); s.append(1, c); } }

If you can keep you head when all about you Are losing theirs and blaming it on you; If you can dream - and not make dreams your master; If you can think - and not make thoughts your aim; Yours is the Earth and everything that's in it. Rudyard Kipling

Angel1058 wrote: 1) Can anybody give me an example of why they ever made a member mutable? I know what mutable is but couldn't give a real life reason for using one (I am not one for finding a problem to meet a solution!). In general this occurs when a const object (object A) needs to call a non-const method of the mutable member variable (object B), specifically in a way that doesn't change the const-ness of the object A (did you get all that? ;) ). Generally this occurs if pretty ugly situations - one example is: http://www.boost.org/doc/html/threads/faq.html#id635597[^] From what I can remember reference counts are another example of this, the reference count still needs to be modified, even if the object is a const copy. Angel1058 wrote: 2) const_cast - allows you to, for example, remove the constness from a pointer, but if that pointer points to a const item, you can't change the value of the item. So all you can do is change what the pointer is pointing to. Same question as above - can anybody tell my why they have ever const_casted a const pointer and pointed it elsewhere!?! I can't think of a good example, but I would imagine something like the conversion of the pointer to something that allows read-only iteration through an array might be a possible answer. If someone has gone to the effort of enforcing all that const-ness I'd think three times before performing the cast. In general const_cast should be avoided in the real world.

If you can keep you head when all about you Are losing theirs and blaming it on you; If you can dream - and not make dreams your master; If you can think - and not make thoughts your aim; Yours is the Earth and everything that's in it. Rudyard Kipling