int deck[ 4 ][ 13 ];
What makes you think this makes any sense?
int deck[ 4 ][ 13 ];
What makes you think this makes any sense?
You can surely run the program yourself and see whether the output is right.
Why are you using C++/CLI and not something like C#?
Well I mean, it's not very fun even if I assumed it wasn't homework. When you take a coke, just pull the next one to the front.
So I need to do this
textFile = textFile + "\n\n"; ?
Newline characters separate lines.
This game sucks; do your own homework.
This game sucks; do your own homework.
string.Empty is the empty string, not an empty line. "\n" is a string that contains a newline character. If you want an empty line, you need two newline characters.
You can't do it; the size of the array needs to be specified in the class declaration. If you want something variable-sized, use a vector.
With some simple representation of 'cell', your spreadsheet could just use a map<pair<int,int>, cell>. Or even (for usability) map<pair<char,int>, cell>.
On top of that, or as a modification of that, you might want some algorithm-specific information, like, maybe you want to store the indegree of each cell in the map, or inside a parallel map.
I see, thanks for the tips! I notice people use lists a lot. It has always seemed beneficial to me to have random access to elements instead of using Iterators to find the element I want, but the amount of people that use linked lists makes me think they all know something I don't. Are they superior performance wise?
The doubly linked list is one of the most useless data structures devised by mankind. Immutable, garbage-collected or reference-counted singly linked lists are very useful. Some of my opinion is based on years of not programming in C++, so maybe, in C++, doubly linked lists are more useful when dealing with memory management and avoiding unnecessary copying. There are some special purpose algorithms that can use doubly linked lists well.
pop_back() will call the destructor of whatever's contained in the vector. In this case, it calls the destructor of a pointer -- which does absolutely nothing! You need to explicitly destroy the objects pointed at by the elements of your vector, as you did in your first code sample. (However, a better way is to use some kind of 'smart' pointer type, to reduce the risk of programming errors that cause memory leaks.)
Well, I was being a bit inaccurate when I said you were being "extremely dumb". Everybody is dumb from time to time.
public void CalculateSize()
{
const int cMaxCol = 3;
const int cMaxRow = 3;
const int cGap = 9;
bool highColCount = ColumnCount > cMaxCol;
bool highRowCount = RowCount > cMaxRow;
int CC = highColCount ? cMaxCol : ColumnCount; // or Math.Min
int RC = highRowCount ? cMaxRow : RowCount;
int ColScr = highColCount && !highRowCount ? 0 : 16;
int RowScr = highRowCount && !highColCount ? 0 : 16;
this.AutoScroll = highRowCount || highColCount;
this.Size = new Size((cCellWidth + cGap) * CC + ColScr, (cCellHeigth + cGap) * RC + RowScr);
}
Sorry, I was just being a jerk :)
You will have to write the name of the enum's type in order to trigger autocomplete; that's life.
The sieve of eratosthenes is slower than trial division. It takes Omega(n log n) operations when implemented naively, and Omega(n) operations with the best algorithm, which is just as good as trial division-based factorization.
So Rashakil Fol please explain to us WHAT else you would do? you have said that I am dumb now back it up with a little maths/code.
Just use successive trial division. There's no need to explicitly skip all the non-prime numbers.
The following C# string should suffice:
"<a href=\"LINK\">([^<]+)</a><br>([^<]*) -- (\\d*)<br>([^<]*)<br>"
What the fuck are you naming your enum type "eFullWeekDays" for and not "FullWeekDays"? Unless you have actual evidence that prefixing your variables with the names of their types increases your productivity, you are just a superstitious nutjob.
Anyway to get it to pop up the weekday list without the prefix of GeneralDates.efullweekdays????
No, because you could also theoretically type in a variable of type GeneralDates.eFullWeekDays.
So does every other language.
Edit: That matters. Besides C++ and C, which fill their niches decently.
Suppose you have some function to get the maximum element of an array:
public static T Max<T>(T accum, T[] array)
{
foreach (T elem in array)
accum = accum.CompareTo(elem) < 0 ? elem : accum;
return accum;
}
This function won't compile. The reason is that there's no guarantee that the type T has a CompareTo method. We could write a function with the type public static IComparable Max(IComparable accum, IComparable[] array);
, but that would be no good for finding the maximum element of an array of ints, because an int[] cannot be converted to an IComparable[] (without copying all the elements). We need some way of saying that T is an IComparable (or better yet, an IComparable<T>). You do that using a where clause:
public static T Max<T>(T accum, T[] array) where T : IComparable<T>
{
foreach (T elem in array)
accum = accum.CompareTo(elem) < 0 ? elem : accum;
return accum;
}
Now here's an example with "T : class". Suppose we just want the maximum element of an array, without the accum parameter. If the array is empty we'll just return null. We might try to write something like this:
public static T Max<T>(T[] array) where T : IComparable<T>
{
T accum = null;
foreach (T elem in array)
accum = accum == null || accum.CompareTo(elem) < 0 ? elem : accum;
return accum;
}
This won't compile. The reason is, the type of the function implies that you could pass in an …
But thats improper use rather than the language fault.
No, Java is actually the worst, and it's the language's fault. It has null pointers and no closures. What other popular language his this combination?
Ah, moving on to the second-worst!
Why don't you look up the term "abstract class" in a search engine, like a non-moron.
That's what you get for using the worst programming language in popular use today :P
Imagine what the list should look like after you've deleted the element; and make it so.
try this ??? is easy way to find
Well this is about the dumbest reply I've read on this forum. Did you even read the question?
As you walk through the nodes, looking for the matching value, keep track of the previous node.
You know what time complexity means or can look it up, right? Why don't you use some reasoning to figure out why time complexity is useful?
If you want optimal balance, you'll need to think carefully about the case where the size of the segment you're working on is a power of two. You need to split that cleanly in half. Are you splitting it cleanly in half?
Also, what do you think the value of root->left is in:
root->left = toTreeHelper(data, low, mid, root->left);
any pointers?
I'll pardon the pun.
Do you want it for a singly linked list or a doubly linked list? I'll consider doubly linked.
Say you've got three nodes (which contain a value and left and right pointers), at locations W, X, and Y:
W={value:_; left: V; right: X}
X={value:_; left: W; right: Y}
Y={value:_; left: X; right: Z}
If you delete X, the list should look like:
W={value:_; left: V; right: Y}
X={who cares}
Y={value:_; left: W; right: Z}
Given the reference with value X, it's a simple matter of code to make stuff look like the version where X is removed. The only edge cases (maybe) are where the node you want to remove is at the beginning or end of the list. Sometimes those are edge cases, and sometimes not---it depends on your list representation.
It makes no sense to check if mid != 0. How could mid be 0? Well, in most cases, mid could not be 0, except at the very left edge of the tree. So your checks for the base case are bad.
Basically your hard job is to consider the cases where high - low is 0 (if possible), 1 (if possible), 2, 3, maybe 4, and in general, even or odd.
Also, you should look twice at your arrayToBSTree function: you might go past the end of the array.
Basically, this problem is designed to get you to practice thinking about off-by-one errors.
Realize that the regular expressions don't get evaluated against the input string until you call m.Count. This is because MatchCollection hopes that you'll enumerate through the MatchCollection with a foreach loop, so that it can perform one regex match at a time, possibly avoiding any unneeded computation.
Your regexes are experiencing catastrophic backtracking.
I still don't understand what you're saying. What do "dng" or "sm" mean?
Sorry, I can't understand what you are saying.
Use log4net or NLog or some other framework for your logging.
Well, what you need to know depends on what you're selling. My brother's in this field and he didn't enter with any particular kind of IT-specific knowledge, but he's definitely learned some things. That list looks very reasonable, the parts outside the parentheses, based on my conversations with him. I don't know anything about the brand names though.
This is a pretty easy assignment.
void main(int args) {
cout >> "xxxxxxx\nx x\nx xxx x\nx x x\nx xxxxx\nx \nxxxxxxx\n";
}
For something like this, you would probably have a swell time with Boost.Regex.
What's the problem? Seems pretty easy.
What logging framework are you using that's giving you these problems?
Your problem is that you use variables global to your class instead of passing them from function to function. The result is that it's easy for previous states of your program to leak all over the place.
First of all, it would be, at the very least, Scanner::Scanner(int NumPoints, RangeStep& Theta, RangeStep& Phi, Point Location, Transformation T, double PointSpeed)
, or even something more clumpy. I suspect I'd only have 2 or 3 parameters to the constructor, the rest part of helper classes.
Second, I'd probably pass some kind of reference-like type to the object that contains most of those parameters -- the ones that don't get copied over and over again.
Third, if there are serious performance worries, I would modify it in place. This isn't a religion I'm talking about, it's practical software engineering. If you're talking about low level numerical algorithms or stuff like simple loops that would require tail recursion to do without modifying anything, I would have no problem overwriting variables -- it makes sense then and it's worth it. There's virtually nothing wrong with modifying variables in place when the mutation is never seen outside a single function.
But if you're talking about some situation like "I have an airplane schedule" or "I have a text editor buffer data structure", those things are going to be immutable. Allowing mutable variables imposes limitations on what your design can be.
Oh, but you do have stack.Count. I hope.
Whoever suggested using the sieve of eratosthenes was being extremely dumb. You just need to factor your number; there's no reason to generate a long list of primes.
Why don't you try reasoning about what your code is doing and figure it out yourself.
I would construct a new Scanner with a different location.
You can't peek if you have an empty stack. (Can you? Oh god please tell me it doesn't return null.)
Since that's a terrible code example, I better put the good version or else some noob will come along and copy and paste the bad version.
public class Memo<T> {
T cached = default(T);
Func<T> memoizee;
public Memo<T>(Func<T> memoizee) {
this.memoizee = memoizee;
}
public T Get() {
if (memoizee != null {
cached = memoizee();
memoizee = null;
}
return cached;
}
}
I don't know of any such notion as "handle".
Now here's the rest of my reply to the original poster:
I think things are best made clear here by defining the relationships between things completely, so here are the definitions I follow:
A type can either be a reference type or a value type.
A class is a set of code that defines a reference type.
A struct is a set of code that defines a value type.
A reference is a memory address.
A constructor is a static function whose name is the same as the type of its return value. You need to use weird syntax to define and call this function.
A variable is a small piece of memory -- enough space to hold a value of the variable's type (which is known at compile time).
A value is, perhaps, something representable by a particular pattern of bits, or a number. A value is not some "thing" that can be modified. It has been stated that a variable is a piece of memory that can contain a value. This piece of memory can be overwritten, but a value itself is immutable. Again, you can overwrite variables, but you can never change values. For example, a variable of type int can contain the value 3, and then it can be overwritten with the value 5. A variable of type string can contain the value X, and then it can …