Search results for query: *

Honestly, I don't know. That's just how it works. I took a quick look in the standard to see if I could find an explanation or specific mention, but none could be found. For cases like these where there is a common usage, I would just use examples from reference material to identify the proper...

operator-> should specify T* as its return type, not T&.

You're welcome. The problem is just a result of the way Dev-C++ (and many other IDEs) run your program. It creates a console window and runs your program in it. But when your program completes, the window isn't needed anymore so it closes. Unfortunately, that means it closes before you can see...

Try adding the calls to cin.get() like I showed you. Does it work then?

You probably need code to stop the window from closing. Try adding cin.get(); to your code just before the end (before any return calls). You will actually probably need to do it twice.int main() { // ... all your code std::cin.get(); std::cin.get(); return 0; }

It means ownership of the object is passed to function, so when the function is completed the memory is destroyed. The calling function should not be using that AttributeHandleSet after calling the function.

In your header, jReplace is a member of JLib, but in your source file, it is not. It should be like this:string JLib::jReplace(string& s, string const& find, string const& replace)in your source file. Notice the extra JLib:: to indicate the jReplace function is a member of the JLib class.

Ahh... so it's a member function? If so, then you need to link to the static lib that has it's definition.

end() returns an iterator to one past the end of the list. Assuming you know the list is not empty, you could use *(--end()), but a more clear solution might be to use front() and back() which actually return references to the values in the list instead of iterators: cout<<L.front()<<L.back()<<endl;

Returning a local object is perfectly acceptable. The problem is when you return a reference to a local object, either by returning a reference or a pointer. In this case, you are not doing either, so you are fine. The shared_ptr object is an object, not a pointer. You are returning a copy of...

Assuming you're using a recent version of g++, then you can use exceptions just fine. g++ doesn't have a parent exception class, it is just a compiler. But C++ has one called std::exception. You don't have to use that, but it often makes sense to derive from it or other standard exception...

It's a trigraph: http://en.wikipedia.org/wiki/Digraphs_and_trigraphs Scroll down to Language Support > C to see why ??/ isn't allowed in C and C++ files.

First, sorry if I sounded rude with the "brilliant" comment. I was just trying to be silly. As for the virtual destructor, here's an example of what I'm talking about: int main() { Player* playerOne = 0; Player* playerTwo = 0; int playerType; std::cin >> playerType; if...

That's not regular C++. I believe it's Microsoft's Managed C++, although to be honest I'm not certain. If you want to do standard C++, you need to make a Win32 Console Application when you first create your project (and check the Empty Project option in the Application Settings page of the...

I wouldn't call it brilliant. A better idea is to actually model your hierarchy based on good design principles (and a Tic-Tac-Toe game is a great place to practice). In this case, I might have a Player base class (make sure to give it a virtual destructor). This class describes the interface...

If this is not a learning exercise specifically meant to learn about dynamic memory, you should definitely use the C++ string. You should be using the C++ string in all of your other projects of this level as well. I think cpjust agrees, as indicated by his first post. As for the copying, yes...

In the copy constructor and copy assignment operator. Declare them as private or implement them correctly, otherwise that String class will probably cause a crash if it is ever copied. I know it is just a quick example and that it is not intended to be perfect, but the incorrect copy behavior...

Note that cpjust's example has incorrect copying. This is part of the reason you should use C++ strings. If this is a learning exercise, you will want to learn about the rule of three and how to update that example to be safer.

Make sure to implement or disable copying for both classes. Lookup the Rule of Three for more information on why. In summary, if you don't, you might accidentally copy a Node or List and then your program will probably crash. (Note: This is one reason why people don't normally use C-style...

As Salem hinted, a vector is often faster than a list in practice. I'd consider starting with that, then optimizing if necessary after you've done some testing. If you design your code well, then the impact of switching from vector to list (or to other solutions) shouldn't be too difficult.