| Forum Index > General Forum |
Thread Rules 1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution. 2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20) 3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible. 4. Use [code] tags to format code blocks. | ||
|
Blitzkrieg0
United States13132 Posts
On April 28 2016 05:22 Khalum wrote:
brrrrrr......
What will this return? Same question for the goto implementation. But you should be calling fail with a null pointer and whatever value was in memory when err was initialized. | ||
|
Khalum
Austria831 Posts
| ||
|
Blitzkrieg0
United States13132 Posts
On April 28 2016 05:46 Khalum wrote: Why try to write fail-safe code and then not even initialize 'err'? I think that was an oversight by the quick code writing. In the second function you're passing the int err to the fail function, but you don't do anything with it so it might as well not be a parameter and just have void return. The real argument is whether or not goto is more valuable than not having the overhead of an additional function call. When you're talking about low level kernel code written 30 years ago the additional overhead would be a problem. | ||
|
Khalum
Austria831 Posts
| ||
|
Deleted User 101379
4849 Posts
On April 28 2016 04:39 Acrofales wrote: Can do that just fine without gotos.
And the advantage of this is that your code will never ever enter the fail code by mistake because you forgot a corner case in which there is no return statement above your label. Yup, pretty much. In 99.9% of the situations gotos can be completely removed by wrapping the code in a function and returning from it. If you define it as inline, it probably even ends up as exactly the same assembly code. It's my observation though that many C programmers hate having extra functions for some reason. Probably has something to do with having to actually think of a proper function name instead of being able to use b2, b5, x or such as a function name. | ||
|
Artesimo
Germany565 Posts
Server.cpp:12:6: error: redefinition of ‘void Server::session(socket_ptr)’ In file included from Server.cpp:1:0:[pointing to session in Server.cpp] Server.h:30:10: error: ‘void Server::session(socket_ptr)’ previously defined here[pointing to the session-definition in Server.h] I am not sure what the problem is since I don't redefine session. After building, Netbeans also marks "#Include "Server.h"" in Server.cpp as an error, while also stating "In file included from --- (Alt-Enter shows hints)". If I press alt enter, nothing happens. Here is my code so far: Server.h
Server.cpp:
| ||
|
SMaD
Spain137 Posts
| ||
|
Artesimo
Germany565 Posts
| ||
tofucake
Hyrule19188 Posts
| ||
|
Blisse
Canada3710 Posts
Also, use CMake :3 | ||
|
Artesimo
Germany565 Posts
On April 29 2016 03:09 Blisse wrote: Isn't that a standard error? Also, use CMake :3 I am too stupid to properly set up a makefile and cant install anything on the lab-pcs unfortunately. | ||
|
Djagulingu
Germany3605 Posts
On April 27 2016 23:42 WarSame wrote: The other computer is a work computer which disables copying files :/ Yup, my internet is pretty stable here. I've run the command like 5 times in a row and I've deleted and reinited the app ~5 times too, so that shouldn't be it. My package.json is simply the default mean.io package, so it should be fine. I know it's a dumb question but... Does your package.json have async and mongoose in dependencies section? The only other thing I can think about is async and mongoose getting deleted from central npm repo. I don't think internet connection creates major issues because I might be having one of the shittiest internet connections in the entire thread and still didn't have any issues with npm claiming success but not downloading dependencies. Regardless, you can run: npm install --save async mongoose and solve your problem that way. | ||
|
Artesimo
Germany565 Posts
Without having session() as a function of a class, I can use:
In a class I thought I had to do this:
Needless to say, it doesn't work. | ||
|
Cyx.
Canada806 Posts
On April 29 2016 19:47 Artesimo wrote:
Needless to say, it doesn't work. I don't think you need the 'ref(this)' call - the Boost docs seem to imply that you can call that as just boost::thread t(boost::bind(&Server::session, this, _1)(sock)); Although this raises the question, why bother binding it at all if you immediately call it with 'sock' as an argument? EDIT: read this again and I'm pretty sure your problem is actually that you're passing the bound function to boost::thread() in the first case, but in the second case you're *calling* the bound function and passing the result. These things are not equivalent: boost::thread t(boost::bind(&Server::session, this, _1)(sock)); I think you want the second one, not the first. | ||
|
Manit0u
Poland17587 Posts
On April 29 2016 06:04 Artesimo wrote: I am too stupid to properly set up a makefile and cant install anything on the lab-pcs unfortunately. You can get away even with simple makefiles for the most part. | ||
|
Shield
Bulgaria4824 Posts
| ||
|
Mr. Wiggles
Canada5894 Posts
On April 30 2016 07:23 Shield wrote: Has anyone tried C++11/14 yet? What do you like and what don't you like? I haven't used it too heavily yet outside of some of the quality of life improvements. I enjoy using the new type inference stuff. For example, auto is very nice and helps with not having to always type out full type names, especially when the type doesn't exactly help with readability. Range-based iteration is also nice. Compare: for (std::vector<SomeObj>::iterator it = vec.begin(); it != vec.end(); ++it) {for (auto &elem : vec) {I like using lambda functions (closures) as well. When used effectively, they can simplify some code and make it easier to read. The changes to initialization are a welcome addition also. There's also been some changes introduced that allow you to lean on the compiler a little more, which is nice. For example: constexpr, strongly typed enumerations, etc. Like I said, I haven't used too many of the more advanced features, but just these ones and a few others result in much cleaner and readable code than before when they're leveraged effectively. Overall, I like the introduced changes. I'd recommend this book if you'd like to learn more: https://www.amazon.ca/Effective-Modern-Specific-Ways-Improve/dp/1491903996 | ||
|
Shield
Bulgaria4824 Posts
On April 30 2016 07:58 Mr. Wiggles wrote: I haven't used it too heavily yet outside of some of the quality of life improvements. I enjoy using the new type inference stuff. For example, auto is very nice and helps with not having to always type out full type names, especially when the type doesn't exactly help with readability. Range-based iteration is also nice. Compare: for (std::vector<SomeObj>::iterator it = vec.begin(); it != vec.end(); ++it) {for (auto &elem : vec) {I like using lambda functions (closures) as well. When used effectively, they can simplify some code and make it easier to read. The changes to initialization are a welcome addition also. There's also been some changes introduced that allow you to lean on the compiler a little more, which is nice. For example: constexpr, strongly typed enumerations, etc. Like I said, I haven't used too many of the more advanced features, but just these ones and a few others result in much cleaner and readable code than before when they're leveraged effectively. Overall, I like the introduced changes. I'd recommend this book if you'd like to learn more: https://www.amazon.ca/Effective-Modern-Specific-Ways-Improve/dp/1491903996 Thanks, I know what you mean. I'm also reading that book. However, my colleagues are usually against auto outside ranged for loops. To be honest, I can't say it helps there too much either.
I'd say the latter is far from unreadable and you don't use iterator's long syntax. | ||
|
Mr. Wiggles
Canada5894 Posts
On April 30 2016 08:05 Shield wrote: Thanks, I know what you mean. I'm also reading that book. However, my colleagues are usually against auto outside ranged for loops. To be honest, I can't say it helps there too much either.
I'd say the latter is far from unreadable and you don't use iterator's long syntax. I'd say it depends somewhat on the code you're working with. It also helps when you're working with stuff that makes heavy use of templating, where the type names by themselves might be gargantuan, and then it definitely improves readability if having the type explicitly typed out isn't required. Another advantage of using auto is that it makes the code somewhat more maintainable as well, since type changes don't require additional code changes except where it's declared. For example, if I changed some type in a class to something with the same interface, I now don't need to go through the code and fix up anywhere it's being used. This can also be gotten around with sufficient tooling, on the other hand. All in all, the best thing to do is to stay consistent with what your colleagues are doing, I'd say. If the benefits in your case are only marginal, it makes more sense to keep the code style consistent than to make changes that don't have full agreement across the team. | ||
|
Nesserev
Belgium2760 Posts
| ||
| ||
|
|
WardiTV Invitational
ByuN vs Percival
Percival vs Rogue
Percival vs Classic
ByuN vs Classic
ByuN vs Rogue
Classic vs Rogue
IPSL
DragOn vs Sziky
Replay Cast
Wardi Open
Monday Night Weeklies
WardiTV Invitational
WardiTV Invitational
The PondCast
All Star Teams
INnoVation vs soO
sOs vs Scarlett
uThermal 2v2 Circuit
[ Show More ] |
|
|
EPT
Among the worst sins you can commit as a programmer is breaking things for the sake of pretty code.
