|
Explicit and volatile you need to know, if you are seen using mutable in C++ we put you up against the wall and shoot 
There are a couple of places you need volatile the two main ones are in multitasking code and interfacing to physical hardware. What volatile tells the compiler the result at that address can change between uses of it ... so it stops the optimizer assuming the value hasn't changed between uses of that address.
Imagine the situation you have code that reads the port of a timer at an address. Then you do some other stuff not touching the port address and then you go an read the port again. Now if you are dealing with memory the two reads will have the same value as the code between the two reads didn't touch the port. So an optimizer might well conclude it can remove the second read and just hold the first read value. Only in reality the timer values ticks because it's hardware and so we need the second read to occur it can't be optimized. The same situation occurs in multitasking, memory that our own code didn't touch can change. So volatile is about making sure the optimizer doesn't shortcut stuff assuming just because the code hasn't touched it, that it hasn't changed. So any variable marked with volatile will have any action on that variable not subject to optimization.
Explicit is when you want the compiler to stop being smart and convert types for you and pretending it's GWBASIC
It used to happen mostly on class/object code that a constructor for example would take a string as a parameter. If you gave it an integer it would automatically know to convert the integer to a string, which is pretty cool sometimes. Other times it leads to a complete and utter bug because you didn't allow for it. So if you tell the compiler you want explicit it turns off the GWBASIC parser and stops the conversion it will throw an error instead.
Mutable is one you will rarely if ever need and if you do need it most of us will argue your code is badly organized or you are super lazy and dangerous. The better name for it would be cached or stencil playtime. So you have a constant or someone passes you in a constant, but you just want to change it I mean string "Drive A" is so close to "Drive B". You declare it mutable you can now play around with the constant it wont change the real constant just your local play copy. It's not something to encourage in that usage. The only real valid use of the directive is when you really are dealing with a real cache such as synchronization objects like mutexes & semaphores. It really exist solely for those unique situations and really shouldn't be abused.
Now I am being flippant so you actually take time to go read up on them properly but that is the basics.
In vino veritas
|
|
|
|
|
i have game application .exe and if someone target my .exe got crash (ddos attack)
i need to create dll file or application to can block or stop high traffic for port
any suggestion ?!
|
|
|
|
|
|
It's not something you deal with at your point as your internet provider will still attempt to deliver the messages to your single IP. So eventually your feed gets overloaded even if you are just reading the packet from the network card and disposing of them because you realize they are junk.
The easiest solution is sign up to a Content Delivery Network, they stop the data ever getting to your server. If you search that term plus your country I am sure you will find some companies to talk to and look at pricing for.
The other option you may want to consider if this is commercial is hiring virtual servers from a VM server farm. They can configure the Virtual server to whatever O/S you need and you run your program on their server. They usually do all the DDOS prevention stuff as part of the deal as they have that stuff already because they have hundreds if not thousands of servers.
In vino veritas
modified 6-Nov-16 11:08am.
|
|
|
|
|
thanks a lot bro .. i think that will be so expensive for me .. because i am Arabian .. with dollars will be higher per month ... i will try software can control traffic and filtering as i can .. if you have suggestion for software that will be awesome ... thanks again
|
|
|
|
|
I just started to learn C++, coming from a C# and Java background.
I like to use interfaces in my code. In C++ though they do not exist so instead I make structs with pure virtual methods. I'm interested in opinions on different conventions used.
My questions are:
1) From what I understand there is no difference between struct and class besides the default accessor, but it is common place to see struct being used when the class is of a smaller size. Therefore I decided as a convention to use struct when writing interfaces since the way struct is viewed by programmers more closely resembles an interface. Are there any other conventions on this issue or is my convention bad or could cause confusion in any way?
2) Since an interface only has pure virtual and provides no implementation (most of the times, default methods are now a thing in Java) I thought it would be logical to only make a header file for it, instead of making both a .cpp and a .h file. Since a .cpp file is supposed to have the implementation and the .h file is supposed to have the method prototypes. Again, are there any other conventions on this issue or is my convention bad or could cause confusion in any way?
Example:
ISayHello.h
struct IRender
{
virtual void render() = 0;
}
ImplementationExample.cpp
class Sprite : public IRender
{
public:
void render() override
{
}
}
What I have tried:
NOTE: My intention is to get the opinion of those with more experience on how my pattern works, if it has problems, and if there is any other convention on issue that my convention is addressing. If you think the question is off topic I would appreciate if you could redirect me to a better place to ask my question. This question for example was marked as off topic on the Code Review Stack Exchange, though in my opinion asking for review on a pattern you in your code is not off topic.
|
|
|
|
|
1. it's legal for a class to inherit from a struct, but it's unusual (i've never seen it done).
in my experience, structs are generally used in C++, like you said, for smaller objects - if they're used at all.
using a class for the interface is standard. having to type "public" isn't that big of a deal, and it avoids someone having to Google "can a class inherit from a struct".
2. your method is fine. personally, i would give the implementation it's own .h file.
FYI, what you're doing here is known as "PIMPL" in C++. there's a lot of info on it out there.
|
|
|
|
|
I tend to do exactly the same mainly because if I need I can transfer my C++ code easily to pure C, C# and into VHDL if working with FPGA's. Some will find our coding quirky because they have not come from that interface background but at the end of the day your code is tight and usually more portable to other languages when you need. Personally I think it's a good trait but those who only write in C++ will argue we aren't using the language to it's full ability.
Do you go the whole hog 
I import multiple interfaces into things I never do C++ multiple inheritance at all. I also run my own form of delegates, mine is closer to C# that the standard C++ setup.
The final thing I do is probably very quirky to my embedded background, in that all my interfaces have an abstract event drive message function call set on them. Generally it will be unimplemented but the number of times it has saved my butt when I need complicated exchanges across the interfaces to synchronize them or often I use it for live debugging. Saves hours of time if you can connect to a locked program and actually look at the interface states. To do that you simply setup the event drive message pump in it's own thread and so you can actually push messages to get the interface states even though the program thread may be deadlocked.
The only downside is in team developments some will struggle to understand your code because it isn't the purest standard C++ form. On the couple of times I ever had that happen I just hide the interfaces inside a wrapper class, sort of where your sample is going. I normally don't hide the interfaces they just sit as exposed public on a class because they are an designed as a proper interface after all.
So like Chris said I am a PIMPL guy as well
In vino veritas
modified 4-Nov-16 14:57pm.
|
|
|
|
|
1. I generally use a struct if it's only going to have variables. All access has to public anyway since there are no accessor methods.
2. I also have only a .h file for interfaces. Sometimes I have multiple interfaces defined in one .h file.
|
|
|
|
|
One issue: I would define a virtual destructor for each interface. This allows you to delete an instance given a pointer to its interface.
If you are using c++ interfaces to implement something like COM, you may wish to disregard this advice.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
If I launch a non modal dialog from a CFormView, how can I know if the mouse leave the surface of the CNonModalDlg ? Preferable I should know inside of CNonModalDialog ... I override
OnMouseMove(UINT nFlags, CPoint point)
void CNonMOdalDlg::OnMouseMove(UINT nFlags, CPoint point)
{
CPoint pt(point);
CRect rectDialog;
GetWindowRect(&rectDialog);
ScreenToClient(&rectDialog);
if(! rectDialog.PtInRect(pt))
TRACE("################################ooouttt\n");
CDialog::OnMouseMove(nFlags, point);
}
but when I leave the dialog surface, the TRACE are not signal me ...
|
|
|
|
|
|
Flaviu2 wrote: ...the TRACE are not signal me ...
Does the if() condition evaluate to true?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
As long I get out with mouse from CNonModalDlg surface, the handler are not fire at all anymore.
|
|
|
|
|
And that is correct behaviour, unless you have captured the mouse as described in leon's answer above.
|
|
|
|
|
You wont ever get the mouse move messages while the mouse is out of the client area unless you set the capture. Richard and I aren't joking there is nothing wrong.
Read the detail it is very clear
WM_MOUSEMOVE message (Windows)[^]
WM_MOUSEMOVE message
Posted to a window when the cursor moves. If the mouse is not captured, the message is posted to the window that contains the cursor. Otherwise, the message is posted to the window that has captured the mouse.
You need to set capture on the mouse if you want the message outside the area. You can grab it when your dialog takes focus or sometimes it is when you select something like select a piece of text to draw. I can't mind read what you are trying to do but you need to set capture on the mouse to get that message outside the client area of the window.
So perhaps start with the simple what starts the fact you want to track the mouse is there an event, a selection process? You want to track the mouse for some reason and whatever starts that process is where you set the capture. When it completes you release the capture. The set capture just needs your window handle and the release call requires no parameters it's a really simple thing and you just need to put the two lines of code in the right place.
The only native window that behaves like that with default behaviour are menu boxes which start the capture when you left mouse click down. They release mouse capture on left mouse click up. That is how you can click an move along menu trees. Perhaps do the same on your dialog so you get the idea. On you dialog handler set capture to start on the left mouse click down and release capture on left mouse click up and you will suddenly see the track outside your window so long as you hold the left button mouse down just like on a menu.
In vino veritas
modified 4-Nov-16 4:25am.
|
|
|
|
|
Kindly thank you all of you, I solved my problem. It is always a pleasure to talk here ! I am trying to create a graphic menu, a menu that is in fact a CDialog, created in non modal way.
|
|
|
|
|
I was doing a job for a company and they don't allow memory allocations to be used you have to request a static block at program start from the memory management unit and then recycle that in your code. You want more there is a whole song and dance you must do. It was a complete pain and then they made the mistake of telling me I could use threads and you could request space for the thread ... so I did apply for 1 thread and got given it.
I offer perhaps the funniest use of a thread ever ... in windows the code would look like this
static BOOL ReleaseThread = FALSE;
DWORD WINAPI MyThread (LPVOID lpParam){
char buffer[4096];
*(void**)lpParam = &buffer[0];
do {} while (!ReleaseThread);
return (0);
}
If you haven't worked it out here would be the equivalent windows use of the thread.
char* buf = NULL;
HANDLE myThread = CreateThread(0, 0, MyThread, &buf, 0, NULL);
while (!buf) {};
strcpy_s(buf, 4096, "Hello there stack buffer\r\n");
printf("%s", buf);
ReleaseThread = TRUE;
But the best bit was it passed thru without anyone noticing.
In vino veritas
|
|
|
|
|
leon de boer wrote: But the best bit was it passed thru without anyone noticing.
Sounds like you are a program managers worse nightmare. 
Best Wishes,
-David Delaune
P.S.
Wasn't me that downvoted you.
modified 3-Nov-16 0:04am.
|
|
|
|
|
Haha yeah I would downvote myself
I figured I would get everything working before dealing with the buffer recycling. It takes a fair bit of work to track what buffers in use and where. What I laughed at was with all the rigor around memory handling I could do it and no-one raised an eyebrow. I mean that is a truely horrible idea.
I will probably recycle one of my memory stream objects and donate it to them because I think the whole manual tracking of buffers is a bit naft and I think just as likely to create program errors as running out of memory.
In vino veritas
|
|
|
|
|
leon de boer wrote: they don't allow memory allocations to be used you have to request a static block at program start from the memory management unit and then recycle that in your code.
There are good reasons for that:
1. In many cases, it is better to discover that you don't have enough memory at program start than to discover it later.
2. In real-time systems, heap management time can be unpredictable. This makes achieving the time guarantees much more difficult.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
Sorry that is not correct ... running out of memory can be fatal no matter if you allocated it before hand or ran out of it on the heap. In my case I abused the stack which is just as bad.
I am an embedded programmer and I live with low ram implementations in real time systems for a living, and that was the point of my joke at those who think you can frame protection in a standard or a formula. You can't, you need to frame intent and guidelines not specific implementations. You can not create a "safe" or "perfect" specification because you haven't written the code and you don't know the problems.
That whole approach is like 1960's military code specifications and nightmare movie which failed dismally and nobody really codes that way anymore we all use block based approach.
The first public discussion on the new military standards in software I know of was when Boeing allowed hackers to try and hack a "little bird" unmanned helicopter. If you don't know about this stuff that would be a good start point.
Hacker-Proof Code Confirmed[^]
As they said you can't hack it and is guaranteed to perform error-free, that isn't a claim it's a provable fact. There are links in the article to the research language F* (F-STAR) and the Project Everest which is Microsofts play in the area of trying to develop better hack free products.
Most new high reliability stuff will follow down those paths for obvious reasons, they can offer guarantees something every other technique can't do.
In vino veritas
modified 3-Nov-16 9:34am.
|
|
|
|
|
I stand corrected.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
You are party right any system is better than none ... I understood your intent
Our human systems are always flawed but yeah the new HDL synthesis tool stuff is scary good. Worth playing around with if you have the time and it's fun but quite different way of programming and probably not on Visual Studio until 2050 !!!!
In vino veritas
|
|
|
|
|
Hi,
I waited until the thread went beyond the first page to further engage with you.
I can tell you why your employer has this requirement. This is common on mission-critical software.
Exceptions and Stack Unwinding in C++[^]
If you allocate memory on the stack... and a recoverable exception occurs in your thread... the memory is correctly released during stack unwinding.
If you allocate memory on the heap and a recoverable exception occurs in your thread... the memory is not released and now your application potentially has a resource leak.
leon de boer wrote: As they said you can't hack it and is guaranteed to perform error-free, that isn't a claim it's a provable fact.
This is not correct. I have met both Bryan Parno[^] and Jeannette Wing[^] and I was present at the 2014 presentation on campus at Redmond.
Yes, small sections of logic can be statistically proven to be secure. It would not be correct to make the claim of "guaranteed to perform error-free, that isn't a claim it's a provable fact"
If I were to assign a confidence level to what they have achieved I would say "High Confidence".
Best Wishes,
-David Delaune
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
