|
You know, you don't have to get smart about it. If that is your reply then you can keep it to yourself.
|
|
|
|
|
Listen dipsh*t, I wasn't getting "smart" about it.
My reply makes perfect sense in the context of the question you asked.
Is there something incorrect about what I said?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
It's obvious you have mental issues so I'm not going to waste my time replying to your childish comments. Have a good day.
|
|
|
|
|
He is not getting 'smart', he is giving you an explanation of what happens when you build and run your program. If you do not understand how Dev C++ converts C/C++ source code into executables then you should go and re-read the documentation.
|
|
|
|
|
See, for instance, The C++ compilation process[^]. The final product of the compilation process (The Dev C++
IDE makes it for you) is the executable.
|
|
|
|
|
Oh, I see now. I was just looking at the wrong file. Yeh, it worked. Thank you.
|
|
|
|
|
wrote: Oh, I see now. I was just looking at the wrong file. Yeh, it worked. Thank you.
Be a good sport and apologize to Richard Andrew x64 .
I'd rather be phishing!
|
|
|
|
|
Richard, I apologize about my comments earlier. Just caught me on a bad day. Sorry. I didn't mean to offend.
|
|
|
|
|
use codeblocks instead it does the same thing as dev c++ but the .exe shows up in the project folder you can just drag it out and reditribute that
|
|
|
|
|
I have two queues in my program,queue and waitingQueue . queue contains the workpackage instances that are created by user . After creating a workpackge by a user, if he decides to yield it, i want to change the status of created workpackage to waiting and add it to the waitingQueue . Creation of workpackage returns a unique id of the package that is added to the queue. This is what i want to acheive:
int packageId = creatpackage(Function, arguments);
wait(packageId);
void classname::yeild(int packageId){
set the state of workpackage to Waiting
add the package to WaitingQueue
if(there is another package in WaitingQueue)
Make a switch context to it
else
Go to normal queue and execute the package
}
My question is how can i access the workpackage state after which yeild function was called. I thought of accessing it based on id somehow(is it even possible??) Based on my full scenario, is there any better approach then what i am doing??
|
|
|
|
|
In theory yes, you can do it that way. But you need some mechanism to find the actual object from the id. When you call the creatpackage function, where does it keep all the data related to that package?
|
|
|
|
|
It got stored in an instance of class WorkPackage which in turn is added to packagequeue
WorkPackage.h
class WorkPackage {
private:
WorkPackageState wp_state;
void (*m_action)(void*);
void* m_arguments = nullptr;
protected:
static int id;
public:
WorkPackage(){};
WorkPackage(void (*action)(void*), void* arguments);
void destroystack();
void execute();
static void setState(WorkPackageState wp_state);
WorkPackageState getState();
Stack Wp_localstack;
fcontext_t m_context;
int packageId;
};
Workpackage.cpp
WorkPackage::WorkPackage(void (*action)(void*), void* arguments) {
Wp_localstack.local_stack= Stack::make_stack();
m_action = action;
m_arguments = arguments;
Wp_localstack.local_stack = static_cast <char *>(Wp_localstack.local_stack) + 1000;
m_context = make_fcontext(Wp_localstack.local_stack, 1000, m_action);
wp_state = running;
packageId=++id;
}
WorkPackageState WorkPackage::getState() {
return state;
}
void WorkPackage::execute(int thread_id) {
m_action(m_arguments);
destroystack();
}
void WorkPackage::setState(WorkPackageState state) {
WorkPackageState new_state = state;
}
|
|
|
|
|
So, I guess, packagequeue is the place to find it.
|
|
|
|
|
Was just wandering if c++ is worth learning or is it outdated?
|
|
|
|
|
It depends. What do you want to do with it?
|
|
|
|
|
I want to make software in the windows enviornment
|
|
|
|
|
|
Mainly database type software.
|
|
|
|
|
In that case you'd probably be best to focus on what other languages you know. If you don't know any fitting languages then C# would be a good bet. For Windows software it'll be comparable (not as fast, but you the difference will be tiny) to C++ in terms of performance, but easier to write because there's a lot of simple tooling for C# User Interfaces and Database programming.
If you want to write some really high performance software, or if you want to just improve your understanding of how languages work at a lower level, then it's still worth
learning C++ (or C). In fact I'd still recommend learning it for your own education, but to be pragmatic if you want results, or a job you'll probably get a lot further with newer managed languages like C# - or web technologies.
|
|
|
|
|
Thanks for your input. I have a lot of thinking to do.
|
|
|
|
|
I think C++ is very much worth learning. However, that doesn't mean it's the best solution for every problem. For database front ends in Windows, C# tends to be a better choice. OTOH, I vastly prefer C++ and Qt over C# and WinForms/Xaml/whatever.
|
|
|
|
|
It is math worth learning?
Yes, I guess.
C++ is not outdated. It is difficult, it is a bit Byzantine.
|
|
|
|
|
Hi
I want to connect a number of sockets (2 or 3) on a port seems like the underlying Object of CAsynSocket is m_hSocket. That would lead me to believe that on the Client Side for Every
Client m_hSocket I would have to instantiate a CAsnycSocket class via new (on the heap) and do a Create and later connect ? It seems after the Create m_hSocket would have a value am I correct on this ?
Thanks
|
|
|
|
|
It's not completely clear what you're asking, but I can say that m_hSocket is the underlying SOCKET handle that the CAsyncSocket object encapsulates.
You are able to create a new CAsyncSocket object and then attach an existing SOCKET handle by using the Attach() method.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Yes that's what I was looking for so if I want to use 2 Different sockets I have to have two instances of CAsynSocket
In Addition If a wrapping CasynSockets in CWinThread Class when getting the OnConnect Notifcation Its is in The Context of the Main Thread so I would have to take that (Main Threads) m_hScoket and Attach to the one used by my CwinThread ? correct As I believe all CasynSocket notification are in the Context of the Main Thread
Thanks
|
|
|
|