For$
<!-- begin site header -->
<div id=

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - louisdx

Pages: [1]
1
Support / Re: Unable to debug under windows; Suggestions?
« on: April 19, 2011, 02:13:55 pm »
Please attach a backtrace once you get the program to crash inside your debugger. Then we'll be able to see where the problem originates.

2
If i am not mistaken ++i is an rvalue as well.

Every lvalue can also be used as an rvalue.

Quote
It's just about whether i is incremented before setting j or afterwards, isn't it?

The post-increment has to - at least in principle - keep a copy of the original value, then update the variable, and then return the original copy. If copying is expensive, this had better be avoided, but it's just good practice to use the best expression that represents what you mean, rather than just any old expression that happens to work. Sure, in the for-loop case the compiler probably knows how to optimise this away (compare the assembly if you're not sure), but why not just use the right thing from the start...

3
A little offtopic:
Is there a difference between ++i and i++ except for when the incrementation is done?
Yes! Think about the return value -- "i++" is an rvalue, and theoretically there needs to be a copy, involving a constructor and all that. Perhaps if you're lucky the compiler will realise that the return value isn't needed in something like a for loop, but you might as well write it explicitly and demonstrate that your code is fully intentional. (The same applies to iterators.)

4
Cheers, I discovered that too and it's all working now. I've started a fork in which I'm working on some mild but satisfying stylistic improvements while getting to know the code -- most importantly, I've set the gcc compiler flags to "-W -Wall -Wno-unused -pedantic" and compile without warnings now.

Would anyone like to test if my fork builds on MSVS and MacOSX? :-)

There are some general issues I would like to suggest which don't require deep understanding of the code; what's the best way of discussing those? (E.g. using "++i" rather than "i++", and the state of the current coding style and enforcing it.)

A tempting question is whether we could switch to C++0x to use variadic templates, which would clean up "hook.h"  a lot :-) But that's not at all urgent.

5
I changed the compiler flags to "-W -Wall -pedantic", and was immediately inundated in warnings. I believe that serious, robust server design should try to be as clean and correct as possible at all levels, so I am hoping that you will forgive my pedantry.

I would like to propose a change, mainly to "hook.h" (but also "plugin_api.*") which will entail many changed lines, but just one conceptual modification, so kindly bear with me:

I would like to replace the void* which is used to store function pointers the m_callbacks vector by a genuine void function pointer:

Code: [Select]
typedef void (voidF*)();
typedef std::pair<void*, voidF> callbackType

Every instance of "void* function" has to be replaced by "voidF function", but the change is straight-forward. It works like a charm in my fork.

Rationale: The C++ standard prohibits using object pointers to store function pointers. With this change the code will be more standard conforming and thus more portable. Also, it is philosophically The Right Thing ;-)

Slightly unrelatedly, "hook.h" is HUGE -- how is your position on switching to C++0x, so we could use variadic templates?

6
As for compatibility with 1.4 it should be enough to change the Protocol version from 9 to 10. No new client side packets have been added as far as i can tell.

My thoughts exactly, which is why I wanted to find out how the protocol works and where the networking code is. I hope to get this working soon!

7
Development / Re: Basic questions about the development process
« on: April 01, 2011, 02:45:58 pm »
I think most (all?) contributions are done via pull requests on Github.

Thank you! I've never used git before (svn user myself), but now I have a reason to learn it :-) I just set up an account, made a custom key pair and forked off.

8
The most comprehensive documentation of the protocol that I know of is located here:
http://mc.kev009.com/Protocol

If i am not mistaken, Mineserver was developed with that description in mind.

Thank you very much, that's a fine website! I didn't know it existed, it seems to make a good hub for all Minecraft-related third-party development!


So, who is the main developer of the mineserver project? It's a shame that this is getting disjointed, perhaps one of the original founders could create a reference branch for future development?

9
The question is, are you good enough to even make Mineserver compile? ;)

I just downloaded the latest git snapshot and it compiled out of the box (Linux, cmake), no problem. It doesn't work with the 1.4 client, though, so I didn't get very far. If you could point me to the networking code and the protocol description, I'd be very grateful.

10
Development / Basic questions about the development process
« on: April 01, 2011, 12:47:41 am »
Hi - I just had a quick browse through your source, and I was wondering how one could contribute. Do you accept patch submissions, or would it be at all useful if I post small comments?

A quick question to begin: How complete is your knowledge of the network protocol, and where is it documented?

OK. Just looking at src/mineserver.h/cpp I have some very minor suggestions:

  • mineserver.h doesn't seem to use the <set> and <iostream> headers; those can go.
  • mineserver.cpp: in main(), you could move the declaration of "arg" inside the loop: "std::string arg(argv)". On the other hand, using getopt.h would probably be an even better approach (one could include a portable version for non-POSIX targets).
  • mineserver.cpp: With std::tr1 you have access to a few very good standardized random number generators, might be worth checking out.
  • Across other header files, there's a mix between deprecated and modern C headers, <string.h> vs. <cstring> etc. Might be nice to make that uniform.

It'd be great to see this project succeed!

11
Development / Re: Coding Style
« on: March 31, 2011, 11:39:58 pm »
Regarding getters and setters, how about using a single function with a const overload to return both lvalues and rvalues?

12
I just noticed this project after someone mentioned the idea of server clones on the official forums. Good plan! I'm pretty decent with C++ and I can solve integrals, even those elliptic ones; is there a suggested path for helping with the development?

Pages: [1]