Posts by sepp2k

How to change the end of std::string?

You mean remove the last part of the string? Use erase for that.

One way that I could think of is to assign '\0' to all the trailing characters of the string but it would be inefficient to do so if length of string is large.

std::strings are not 0-terminated. Setting their characters to \0 does not make them shorter.

I do agree with Tokamak that the c++ example he mentioned is closer to how my intuition expects the code to work than Java.

You and Tokamak are certainly not the only people whose intuition goes that way (mostly, I think, because a lot of people mis-explain x++ as "do something with x and then increment x afterwards") and I do agree that some people's reactions here were needlessly arrogant for something that really a lot of people do get wrong. That said it's still wrong and based on a misunderstanding of how x++ works.

If ++ was a method, and num an object, the num = num++; would have behaved the way Tokamak and I would expect it to.

Definitely not. Consider this class:

class MyInt {
    private int value;
    public MyInt(int value) {
        this.value = value;
    }

    public MyInt postInc() {
        int oldValue = value;
        value = value + 1;
        return new MyInt(oldValue);
    }
}

This definition of postInc will behave exactly like ++ behaves for primitive ints. More importantly: there is no way to change the defintion of postInc so that it would behave the way you expect/want it to.

---

Another thing: I know I'm repeating myself, but several people in this thread have now referred to "the way that it works in C++" and I just want to reiterate that there is no way in which it works in C++. A C++ application in which you use this construct …

I'm afraid I do not understand your question. None of the code posted in this thread contains any sums.

The command 'echo ${0}' returns the command name that executed - in this case, 'bash' - the shell command that I am running.

Since the code was almost certainly part of a shell script, not typed directly into the shell, $0 would be the name (and path) of the script file, not the name of the shell.

That is piped into the command "grep '/transforms/'" - which due to the path specified, must exist in the / (root) directory of your system - unlikely...

What? grep 'transform' runs the executable grep with the argument /transform/. grep must be located somehwere in your $PATH (most likely /bin) and, unless you have a completely non-standard system, it will.

The output of that is piped to the 'wc -l' command which would return the number of lines from the '/transforms/' command. Since that (/transforms/) doesn't exist, the output is '0'.

It produces the number of lines in the output of the grep command. And as masijade already pointed out, grep will produce one line of output if $0 contained the substring /transform/ (which will be the case if the script is placed inside of a directory named transform or anywhere below (i.e. in a sub-directory, sub-sub-directorc etc. of) it. Otherwise it will produce no output.

So if it is undefined behavior how can C++ be wrong?

Well, obviously it's legal behavior, but it's not consistent with the definition of ++. That is the UB is unrelated to the fact that you're using ++ and due to the UB it behaves in a way that does not follow the definition of ++ (and of course it might very well act differently on other implementations). Without the UB, it would have to produce 0 because that's what the definition of ++ mandates.

should be defined to return 1. I say this because it is consistant with the definition of postfix notation.

No, it is not. x++, as it is defined in both Java and C++, evaluates to the value of x before the increment. So if x is 0, x++ evaluates to 0. Now, barring UB in C++, foo = bar will evaluate the expression bar before the result is assigned to foo (which makes sense since obviously you can't assign the result of bar to foo without evaluating foo first). This means that if you do x = x++, first x++ is evaluated (causing x to become 1) and then the result of the expression (0) is assigned to x. Thus x ends up being 0.

Any other result you might get in C++ is incosistent behavior due to UB. The above behavior is the only one that's consistent with the definition of ++.

A variable can be referred to as either $VARNAME or ${VARNAME}. The latter form is useful if the variable name is followed by something that's not supposed to be part of the variable name. For example say you have a variable FOO and you want to print the contents of the variable followed by the string "_BAR". If you write echo $FOO_BAR it will look for a variable named FOO_BAR. So you write echo ${FOO}_BAR instead.

In this case there's a space directly after the ${0} so the braces aren't actually necessary. So in this case there is no difference between the two.

Answer rephrased: You can use the same va_list twice.

If you mean why can't you use the same va_list twice without resetting it with va_end and va_start: How would that work? You have to rewind it somehow - otherwise how could it possibly know that you want to start from the beginning and not just read more arguments?

It works correctly in C++ but not in Java.

I said this already, but I'll say it again: The C++ code you posted invoked UB. If it had not invoked UB (i.e. if = introduced a sequence point), the behavior would be the same as in Java. Java's behavior is correct (i.e. completely in line with ++'s definition). The C++ behavior was the one that's "wrong" (i.e. incosistent with the definition of ++) because UB programs can behave anyway they want and in this case it decided to act in a way that's not consistent with ++'s definition.

Note that Java's definition of ++ and C++'s definition of ++ are the same. The only difference is that in C++ modifying the same variable twice without a sequence point in between invokes UB. Otherwise the definition of ++ in C++ would mandate that your C++ code should print 0 just like your Java code.

To illustate this, consider this code:

#include <iostream>

void assign(int& target, int value) {
  target = value;
}

int main() {
  int y = 0;
  assign(y, y++);
  std::cout << y << std::endl;  
}

The only difference between that code and yours is that I used an assign function to introduce a sequence point rather than using = directly. And this program will always output 0.

Quoting from man stdarg:

Multiple traversals of the list, each bracketed by va_start() and va_end() are possible.

So yes, you can use a va_list twice.

The as keyword is practically the same as a cast.

The difference being that if the given object doesn't have the right type, a cast will throw an exception while as will just return null instead.

In this case however, there's no need to cast at all since A is a supertype of B. So the line in question should really just be A a = b;.

As you noticed, feeding a string that doesn't represent an integer (like "done") to int will cause an exception. So you should only call int on the user input if it is not "done". You can achieve this by putting the if above the call to int and put the call to int in the else part of the if.

PS: Instead of str("done") you can just write "done".

PPS: Note that writing "done" will currently only cause the sum to be printed -- it will not stop the loop from further asking for input.

data[1:2][0]

Why would one possibly write that rather than data[1]?

data[1:2] is a list splice. It returns the sublist of data that goes from index 1 (inclusive) to index 2 (exclusive). So basically it returns a list that contains the element at index 1 and nothing else. If all you want is the element at index 1 without a list wrapped around it, just use normal indexing:

withdrawal = data[1]

It also seems strange to me that you use a list comprehension on a 1-element list to get the balance. I would just do balance = int(data[0]) if I were you. If there's a good reason why balance should be a 1-element list, you could also do balance = [ int(data[0]) ], but I don't see what that reason could be.

Make alert virtual and override it in class b.

Instead of defining a new variable with the same name, you could just assign a different value to the same variable, like this:

public class a
{
    protected string text = "class a";
    public void alert()
    {
        MessageBox.Show(text);
    }
}

public class b : a
{
    public b() {
        text = "class b";
    }
}

This way a b object will only have one variable named text, which will be the one inherited from a (and thus also the one accessed by a methods). And the value of that variable will be "class b" for b objects and "class a" for a objects.

If num starts at 0, then the assignment should be num = 0 then num should increment during the postfix incrementation of num!?

The increment happens before the assignment. Postfix increment does not mean that the increment happens after the current statement. It only means that the result of the expression will be the value of the variable before incrementing (as you can see in the quote of the specification posted by James).

Basically if you have foo(x++) that's equivalent to oldX = x; x += 1; foo(oldX), not foo(x); x += 1;. So x = x++; is the same as oldX = x; x += 1; x = oldX, not x = x; x += 1.

I still feel like, you may have just copied someone elses work, posed as a professor, and want us to explain their code.

He already knows that replacing num = num++ with just num++ will fix the problem, so how would explaining why num = num++ doesn't work, help him take advantage of someone else's work?

When I write this in C++ I get 1

The C++ code invokes undefined behaviour. You might very well get different results on other implementations. If the behaviour were defined (i.e. if = introduced a sequence point), you'd get 0 just like in Java.

Copy elision

The program, as written, will invoke undefined behavior and most likely not depend on endianness at all.

num+1 produces a pointer that points to the address that num points to plus sizeof(int). You then cast that pointer to char* and dereference it. Since num+1 points outside of the bounds of the object that num points to, this is undefined behavior. In practical terms this will most likely give you the byte that is stored in memory after a. What that byte is will not really depend on endianness.

I assume what you meant to do is *(((char *)num)+1). That is cast num to char* first and then add 1 to it, producing a pointer to the second byte of a.

They do, but vowel([a], 1) is shorter.

Count is Count in your clause in line 8 does not make sense for me

Actually it's saying Count is Count + Counter (the lines are broken funnily), but that doesn't make sense either. Once a variable has been given a value, you can't just give it a new value. It will keep that value as long as it lives (or until Prolog backtracks back to a point before the variable has been given a value).

Something like X is X+Y will always be false unless Y is 0, in which case it will be true. Either way it will never change the value of X.

PS: This has also been asked and partially answered here: http://www.dreamincode.net/forums/topic/323595-count-vowels-in-a-list-prolog/

The compiler may handle function arguments either of the ways described in the article no matter what the called function looks like.

There is no direct equivalent for delegate in Java, that is you can't pass methods as arguments to other methods in Java. What you do instead is to create a one-method interface and then implement it and pass an instance of it as a parameter to the given method.

So for example sorting methods take a Comparator<T> object as an argument. Comparator<T> is an interface containing the single method int compare(T,T)). The sorting methods in C# either take an IComparer<T> (which is a one-method interface just like Comparator<T>) or a Comparisson<T> (which is a delegate) as an argument. In Java the delegate option is just not available.

You set ehealth to 15 on line 26, which is inside the loop. Then you subtract a random amount of damage between 5 and 9. So ehealth is now somewehere between 6 and 10. That's still above zero, so the loop repeats, jumping back to line 23. So line 26 will execute again, and ehealth becomes 15 again. So the loop will continue forever without ehealth ever becoming zero (or less) because you always set it back to 15 before subtracting damage.

To avoid this problem, you should set ehealth to 15 once before the loop and then never again. Same thing with thealth.

The only way to make println not call the default toString method is to define your own toString method. If you want the contents of the variables to be printed, you'll need to define a toString method that returns a string containing the contents of those variables.

If you're using a boolean variable as your while condition and that while loop never exits, that means that either the variable is never set to False (because the part that's supposed to set it to False is never reached for some reason) or the body of the while loop contains an infinite loop itself.

Either way we won't be able to tell you what the problem is without seeing the code.

PS: Without having seen the code, it seems to me that using a boolean variable as the condition for the while loop is not the most straight-forward way to solve your problem. Something like while enemy.health > 0: should be perfectly sufficient.

AND you need to implement all of the methods specified in the Serializable class.

Yes, all zero of them.

while enemy.hp > 0:
  attack = raw_input("Which kind of attack do you want to perform against the enemy")
  enemy.hp -= damage_for(attack)

print "The enemy is dead!"

You can't write code directly into the class body like that. It needs to be inside a method.

Let's think about what the result should look like for a non-empty list. You want a list that contains two lists, right? So the basic structure should be (list something something-else). Now what do we want something and something-else to be? something should be a list that contains the first element of every sublist in l and something-else should be the list that contains the second element of every sublist. You can define both of these just by using the functions you used in your code: map, car and cdr. But instead of using list as the function for map, you should call map twice -- once with car as the function and once with a combination of car and cdr as the function -- and then wrap the two calls to map in list.

Let's say you pass in a list with one element. Then Count will be 0 (because the length of T will be 0). Therefore Count > 1 will be false and since there are no alternatives, the whole thing will be false. The same thing will be true if you pass in two elements (because 1 > 1 is still false) or even if you pass in more elements than that (because eventually you'll recurse down to a list that has less than 2 elements).

You need to move Count1 is Count + 1 after the recursive call to countvowels. Otherwise Count doesn't have a value yet at that point.

After making all the changes I mentioned, the code works fine for me. Can you post your current version of the code?

Oh, yes, you also need to move that part after the recursive call. Otherwise Count doesn't have a value at that point either.

Lastly you need to remove the Count1 > 1 bit. Otherwise it would produce False when given a list with only one element and thus, due to the recursion, when given any non-empty list.

Count is Count1 + 1

I think you meant Count1 is Count + 1 here.

PS: As your code is currently written, it counts any item in te given list - not just vowels.

It doesn't. The accessibility of a class's constructors and destructor only affects whether and under what conditions you can create instances of the class (specifically you can only directly create instances of the class if at least one of the constructors is accessible to you and you can only create instances on the stack (or delete instances on the heap) if the destructor is accessible). It does not affect whether or under what conditions you can refer to the class at all (e.g. changing the constructors' or destructor's accessibility won't ever change whether or not you're allowed to access a static member of a class or whether you're allowed to use the class name as an argument to sizeof).

Prolog lists are linked lists - not arrays. However like arrays they are used to store an arbitrary amounts of data, so they're used for many of the situations where you'd use arrays in imperative langauges. Does that answer your question?

Anyone familiar with this programming language?

I am.

If so, anyone use it on the job?

I do. My current project at work (at a university) is to write a translator from C to an intermediate language, which we use to perform model checking on the program (so basically I'm writing a C front-end). That project's written in F#.

germantoenglish([S|H],[G|Ta]):-trans(S,Ta),trans(H,Ta).

Calling trans with S as the first argument is a step in the right direction, but by using Ta as the output, you're making Ta a symbol - it's supposed to be a list though. And you're still calling trans with H as the argument in the second call. As I said, you can't call trans with a list as the first argument (or the second argument for that matter). You need to call germantoenglish recursively to translate the rest of the list. And, as I said, you also need to handle the case where the list is empty.

[S|H] is a pattern that says "this argument must be a list with at least one element. The first element shall be called S and H shall be a list containing all the other elements". You use [e, t, th] for this argument, so S becomes e and H becomes the list [t, th]. Then you call trans(H, Ta). So now prolog searches through the rules of trans to find one that matches the first argument [t, th]. However there is no rule for trans that accepts any kind of list, so no rule is found. Therefore you get false.

So there are basically two things wrong with your rule: 1. You call trans with a list as its first argument when it should be a symbol. 2. You never do anything with S.

trans should be called once for each symbol in the list with that symbol as its first argument. To accomplish that you'd either maplist or recursion. Note that when implementing recursion, you should add a rule for the case where the list you're trying to translate is empty.

Predicate or procedure is what Prolog calls its "functions". So fib/2 is a predicate.

You can't write fib(N-1, AF), you have to write something like NM1 is N-1, fib(NM1, AF).

But the loop still needs to be implemented to scan the entire array correct?

Right, you still need the loop. What you need to change is that return true should happen after the loop, not during, so that it actually makes sure that all the elements are the same before it returns true.

I messed around with the code and now it's returning value 32

The only way that your function could possibly return a value other than true (1) or false (0) would be if the end of the function was reached without executing any return statement. In that case the behavior would be undefined and you'd basically get a random return value.

Your function returns true if the first elemenet of the first array is equal to the first element of the second array and false otherwise. That is, it always stops after the first iteration of the loop returns a result based just on that one iteration (because when a return is executed, the execution of the function is aborted).

That's not right. If you see that an item in the first list is different from the corresponding item in the other list, it's actually okay to return false right away: if one item is different, that's enough to say that the lists are different - so not looking at the rest of the list is okay in that case. But in case of returning true it's not okay. You can't just say that the two lists are equal because some of their items are equal - all their items (that is all items in the same position) need to be equal. So you definitely need to go through the whole list before you can return true. This means that the return true must be outside the loop.

You can't use arithmetic expressions directly as arguments to predicates in Prolog - you need to asssign them to a variable using is and then use that as the argument:

N >= 0, NM1 is N - 1, NM2 is N - 2, fib(NM1, AF), fib(NM2, BF), NF is AF + BF.

The way that compare works is that it returns a negative number if the first argument is less than the second, a positive number if the first argument is greater than the second and 0 if they're equal. So return -1 means "o1 is less than o2", return 0 means "o1 is equal to o2" and return 1 means "o1 is greater than o2".

[you] first need to convert Array into an ArrayList<Student>

No, he doesn't. Arrays can be sorted using Arrays.sort, which works just like Collections.sort, but for arrays.

I meant that if, for example, you're looking at the field with the coordinates (MAXX-1, MAXY-1) (i.e. (77,21) you should consider its neighbours to be:

(76, 20), (77, 20), ( 0, 20)
(76, 21),           ( 0, 21)
(76,  0), (77,  0), ( 0, 0)

And similarly the neighbours of (0, 0) should be:

(77, 21), ( 0, 21), ( 1, 21)
(77,  0),           ( 1,  0)
(77,  1), ( 0,  1), ( 1,  1)

And likewise for every coordinate that's on the edge (i.e. every coordinate where x is 0 or 77 or y is 0 or 21). That way any shape that walks off on one edge will re-appear on the opposite edge, which is what you want.

You can not change the behaviour of < being used with two doubles. The only thing you could do is to make at return a custom type instead of E, like a Proxy<E>. Then you could define static bool operator<(E, Proxy<E>) and that one will be called when you do 4.5 < s1.at("a").

First of all you're accessing your array out of bounds when x is MAXX - 1 (and thus x + 1 is MAXX) or y is MAXY - 1 (and thus y + 1 is MAXY), so your program is invoking undefined behaviour.

I think you started your loop at 1 instead of 0 because you wanted to avoid issues with x - 1 and y - 1 being -1 and thus out of bounds by simply considering the fields on the border as dead space. If so, you should apply the same logic to MAXX - 1 and MAXY - 1 and thus adjust your loop bounds to exclude those values, too.

Except don't because the way to make the board wrap-around like you want is to not exclude the fields on the border, but rather consider the opposite border fields as their neighbours. I.e. if x is 0 then you should consider fields with MAXX - 1 instead of x-1 as the top neighbours and if x is MAXX - 1, you should consider fields with 0 as its bottom neighbours. Same with y and the left/right neighbours.

I think I've answered this in my first post in this thread (for C99 at least):

In C99 sizeof is not a compile-time operator when used on variable-length arrays. It's still a compile-time operator when used on anything else though.

If we're talking about C89, the same thing as for C++ applies: Barring compiler-specific extensions that allow non-standard code to compile, sizeof is always a compile-time operator in C89.

If we're talking about C11, it's basically the same as for C99, but with the caveat that variable-length array are an optional feature in C11. So: in C11, if __STDC_NO_VLA__ is set, sizeof is always a compile-time operator - otherwise it is only a compile-time operator when not used with variable-length arrays.

If you have that code in C++ and you're not using any extensions, it will simply not compile. So if you were asked in a test about standard C++, what the output of that code is, the answer would be "Nothing - it does not compile". And if that's not one of the options the test is either not about standard C++ or it's simply wrong.

In C99 sizeof is not a compile-time operator when used on variable-length arrays. It's still a compile-time operator when used on anything else though.

In C++ your code is not legal. If your compiler accepts it, that means it supports variable-length arrays for C++ as a non-standard extension. gcc will accept VLAs in C++ when in GNU mode (-std=gnu++03 or -std=gnu++11), but will reject them when in standard-compliant mode (-std=c++03 or std=c++11). In C++ as it is defined by the standards, sizeof is purely a compile-time operator. In C++ extended with VLAs it is not a compile time operator when used on VLAs - just like in C99.