C++ Programming

It all depends on what you are making, if you want your own specific AI or some types of events or you simply want to make your game more diverse coding is highly recommended. Entities provided by cryengine are helpful but make for a bland game (usually). Take a look at the coding and give it a try

An operand is the value that is being operated upon by an operator. For instance, the C++ increment operator (++) is a unary operator, which means it has only one operand, the variable that we wish to increment. This in the expression x++, x is the operand. The addition operator (+) is a binary operator and therefore has two operands. Thus in the expression x + y, x and y are the operands.

Yes. Without prototypes you must ensure all definitions are declared forward of their usage. This isn't always possible. Separating the prototypes from the definitions means you can #include the prototypes forward of their usage, and place the actual definitions anywhere you like.

There are two methods of casting one type to another: static casting and dynamic casting (both of which apply to pointers and references to objects). Statically casting a derived class to a base class is typesafe as the base class is guaranteed to exist if the derived class exists. However, static casting from a base class to a derived class is always considered dangerous as the conversion is not typesafe. Dynamic casting exists to cater for this scenario, however it is only possible when the base class is polymorphic (thus ensuring the required runtime information is available). If the conversion is not possible, the return value is NULL. However, it is considered bad programming practice to dynamically cast from a base class to a derived class. If the base class is polymorphic (which it must be), there is NEVER any need to dynamically cast between types. Virtual methods ensure correct behaviour. Whenever you are forced to dynamically cast from a base class to a derived class, consider redesigning the base class interface instead, as it is a clear sign of bad design. It is not dangerous, however; only static casting from a base class to a derived class is considered dangerous.

Primitive Plus was created on 2002-03-19.

42 + 65 = 107

int sum(int list[], int arraySize) {

int sum=0;

for(int i=0; i<arraySize; ++i )

sum+=list[i];

return(sum);

}

Declaring member variables (data) private ensure only the class and friends of the class have access to an object's data.

Declaring member methods (functions) public is required to provide an interface to the private data.

Usually accessor and mutator methods (get/set methods) are declared public to allow user-interaction with the data. However the data itself must remain hidden by the accessors (returned by value) otherwise there's no point in hiding the data -- there is no control. Similarly, the mutators should allow the data to be modified through a controlled interface, thus ensuring the data remains in a valid state at all times. Again, allowing a public mutator to modify the data without validation defeats the purpose of hiding the data in the first place.

Protected access is another option. This is similar to private access, but also permits access to derived classes.

A well-designed class interface should only expose as much as it needs to, and no more. If an object cannot assure its own data integrity at all times, then it is no better than a structure, which is always public by default.

Note that the general rules on class interface design are intended to help not hinder you. Many new programmers find them too restrictive, often making members public when they should really be private. They have entirely missed the point of using a class rather than a structure. That is, a well-designed interface that fully encapsulates an object automatically enlists the help of the compiler to reduce the chances of you or a third party coder from attempting an illegal operation upon the data within the object. If the data integrity can be assured at all times, then the chance of error is greatly reduced. The more complex the data, the more important this becomes.

The only advantage is that it is free. But it is disadvantaged by the fact it only supports Windows 95, 98, NT and 2000. Thus it is not compliant with the current C++ standard, and is only useful for legacy development upon these Windows platforms.

If you mean an array where each element is a list, then the STL is your friend. To create an array of lists of any type T, use the following declaration:

std::vector<std::list<T>> my_array_of_lists;

All Intel processors can be used for C++ programming. All you need is a suitable compiler/linker.

With regards performance, the N450 does not perform well compared to modern netbook processors. Given its age this is hardly surprising.

A standardised language means that code becomes completely portable between any compiler, so long as the compiler supports the standard and the code itself does not contain compiler-specifics. In terms of game development, this makes it much easier to port games between platforms.

Of course, C++ code is usually far from standard because the standard does not include platform-specifics (in terms of hardware and operating system). Thus each platform requires it own set of libraries. Generic libraries are available to make things easier (such as OpenGL and OpenAL for graphics and audio), but Windows API calls vary greatly from Linux API calls, and each needs its own set of libraries. However, with prudent use of preprocessor definitions (macros) and helper functions, it is possible to write generic cross-platform code.

You can't overload the insertion operator (<<) from inside a class because the l-value must be an ostream object, but operator overloads implemented within classes always implicate the class instance itself as being the l-value.

You must overload the insertion operator from outside of the class, like so:

ostream& operator<<(ostream& lhs, const MyObject& rhs)

{

lhs << rhs.get_data();

return( lhs );

}

Yes, passing an array name to a pointer assigns the first memory location of the array to the pointer variable. An array name is the same as a pointer to the first location of the array, with the exception that an array name is a r-value, while a pointer is an l-value.

44.72 + 21.15 = 65.87

The simple argument for case-sensitivity is that character 'A' (#65) and character 'a' (#97) are not the same character. To us humans they are clearly the same letter, but computers are less forgiving. Back in the good old days when RAM and CPU time were expensive, it simply wasn't worth the effort or expense to have the computer treat them as being the same. In those days, the onus was largely upon the programmer to ensure they identified variables correctly. Programmers were far more concerned with speed of compilation and, having been brought up within the case-sensitive world of Unix, they were intelligent enough to know that MAX and max are not the same identifier as far as the computer was concerned.

As the cost of computing fell and more and more people wanted to program them, the unforgiving nature of case-sensitive programming became a greater concern, thus languages such as BASIC were developed to address the problem and make life easier for newcomers. The same can be said of DOS, from which MS-DOS evolved. But while these languages and operating systems are more forgiving, they lack the flexibility and speed of a case-sensitive environment.

In C, for instance, the inherent case-sensitivity makes it possible to use programming conventions such as all uppercase for macro identifiers and lowercase for C identifiers. Macros are not actually part of the C language -- they are used by the preprocessor to prepare the C source code for compilation -- but it is helpful to be able to differentiate a macro from an actual identifier in your code, even when they have the exact same name.

MAX and max are not the same, but then neither is Max or mAx. Normally you wouldn't use mixed-case like this in C, as it makes your code hard to read, but the language is flexible enough to permit it should you wish to do so. And that is the main advantage: flexibility. The main disadvantage is the lack of forgiveness. But if you want forgiveness, you wouldn't be programming in C to begin with, you'd use something far more abstract instead, like Visual Basic.

See if flowchart is made then good reason is drawn for it. So, flow chart is essential for our cultural and social life.hence ,flowchart is important.

In linked queue we're dynamically allocating the memory and there's no fixed memory limit in Linked Queue. That's why there's no operation for overflow.

I guess It's the correct reason

Use an associative container such as std::set and enumerate in reverse order, or supply a predicate that sorts in descending order such as std::greater<T> (default is std::less<T>).

A basic shell program should essentially emulate a command prompt with a very limited set of commands, such as exit to close the shell and possibly cd to change the current directory. Shell's are typically used to spawn other processes, but a basic shell will typically limit which processes may be allowed to run.

There is no requirement for any statement in a C++ function, let alone three sets of statements. For instance, the following is a perfectly valid function:

void foo(){}

Clearly this does nothing as it has no statements in the function body, but it is nevertheless a valid function.

Perhaps you mean something else by "statements". The only requirement of a function is that it have a return type, a valid name, an argument list and a function body. The return type may be void, of course, and the argument list may be empty, but it must include the ellipses. The function declaration need not include the function body, and the argument list need only specify the type of argument (the argument names are optional and need not match those declared in the actual definition).

The function name and the arguments define the function signature (the prototype), thus the three required "components" of a function are the return type, the signature and the function body.

An alias is a reference, an alternate name for a variable or constant. You can assign the address of any variable or constant to a reference of the same type. A reference is a bit like a constant pointer to the type but, unlike a pointer, a reference has no address of its own thus you cannot store references. More importantly, references can never be NULL. They are simply an alternative name by which you can refer to an existing variable or constant. When you assign a value to an existing reference to a variable, you are assigning the value to the variable itself. When you pass a reference to a function, you are passing the address of the value being referred to, and that address is assigned to the function's reference argument and is local to the function. This is not unlike passing a pointer, but pointers may be NULL, references are guaranteed to be non-NULL (a NULL reference invalidates your program).

Note that C++ references are not the same as C reference variables or constants. In C, a reference variable is simply a non-const pointer, while a reference constant is a constant pointer. Hence pointers can be dereferenced (both in C and C++). But in C++, a reference is neither a variable nor a pointer, but is constant (it always refers to the same object and cannot be reassigned once assigned).

It's always much quicker (on average) to search a sorted array than it is to search an unsorted array. This is because you can start in the middle of the array. If the value you seek is there then you're done. If it is not there, but the value you seek is less than the value you found, then you immediately know it must be in the left half of the array, otherwise it must be in the right half. In other words you've reduced the number of items to be searched by 50%. If you repeat the process with this smaller subset you'll reduce the search to 25% of the original array, then 12.5%, and so on. Eventually you'll find the value you're looking for. The worst case for any search is when the value does not exist. But you'll know that as soon as the reduced subset has no elements.

We often use Big-O notation to determine how long we expect an operation to take. We know that we can access any element in an array in constant time, which is denoted O(1). We also know that we can compare values in constant time. So we're really only interested in the cumulative time it takes to search the array. For an array of n elements, the worst case involves inspecting every element, which is denoted O(n), which means O(1)*n, or n constant-time operations. For a large array of say, 1,000,000 elements, that's a lot of constant-time operations.

If we imagine an unsorted array, it will always take O(n) time to determine that a value does not exist. But if we sort the array and inspect each element in turn, it will only take O(n/2) time on average because we can stop searching as soon as we find a value that is greater than the one being sought. However, the worst case is still O(n) if the value being sought happens to be greater than any in the array. But if we start in the middle of a sorted array, the average and worst cases both drop to just O(log n).

Note that there will be some overhead in recalculating the subset boundaries, which is itself a constant-time operation, but this is only of concern when dealing with small arrays. It would, in fact, be much quicker to search small arrays one item at a time. For larger arrays, reducing the problem by 50% on each iteration means the overhead quickly becomes irrelevant, but it only works when the array is sorted. Hence new programmers tend to spend an inordinate amount of time studying sorting algorithms to ensure their programs operate as efficiently as possible.

Some algorithms are better than others, but there is no single algorithm that is suitable in every situation. For instance, insert sort is the ideal sorting algorithm for small subsets, but when dealing with a subset of more than a few hundred items it is woefully inadequate. And while quicksort performs extremely well when dealing with large amounts of data, it is unstable (equal items may not be in the same order they were input) and it doesn't work at all when the amount of data is so enormous that it simply will not fit into working memory. For that you need merge sort which uses multiple tape drives or separately controlled disks to sort the data. With slow-to-access media such as this, efficiency is far more important than raw speed alone.

You cannot actually call any constructor, you can only invoke construction, either by instantiating a static instance of a class or by dynamically creating one with the new operator. In the case of base class construction via a derived class, the base class constructor is invoked by the derived class' initialisation list.

Every class constructor has an initialisation list whether you define one or not (the compiler will generate one automatically if you don't). When you derive one class from another, the derived class initialisation list invokes a call to the base class default constructor. The only exception is the compiler-generated copy constructor which automatically calls the base class copy constructor.

If you define your own initialisation list, then you can explicitly invoke any base class constructor overload, thus making your construction code all the more efficient. However, copy constructors should always invoke the base class copy constructor, so if you define a copy constructor, you must explicitly invoke the base class copy constructor -- the compiler will not invoke it implicitly from a user-defined copy constructor.

While many programmer's use the constructor's body to initialise a class, this is highly inefficient. Even if you don't specify an initialisation list, one is created for you, resulting in every base class and every member variable being initialised twice, which can quickly add up to a substantial cost in performance.

The constructor's body should only really be used for initialisation when it would be difficult or impossible to do so from the initialisation list. Remember that your object doesn't physically exist until initialisation is complete, so you may not have access to some members, particularly base class members, at certain points in the initialisation process.

Initialisation must be done from the ground up, starting with the base classes and ending with the actual class members, and all in the order they were declared. Note that only direct base classes (or virtual base classes) should be invoked from the initialisation list. The base classes themselves should invoke their own base class constructors, if they have any. Thus no matter which derivative you construct, the least-derived class is always constructed first.