|
We both read the same sentence, which is pretty clear IMO. I took it as is, you chose to read something that wasn't really there... Hanging is not an option, this ain't 19th century Texas.
|
|
|
|
|
Yes, indeed it was pretty clear and I really chose to read it that way (I've updated my previous reply).
Hanging threads is an everyday option for many 'senior developers' around... 
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
|
|
rp_suman wrote: Mutex Objects
Critical section at the time of accessing of the variable! not mutex if we talking about thread! mutex is more beneficial in case of limiting access across different process
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
The first response is to gently chide the interviewer telling him (or her) that they're mad for using global variables in a multi-threaded program.
Once they've made some excuse for using global data (legacy code, have to make change immediately otherwise the four horsemen ride, Jormangand wakes or even worse the company's stock price falls) the second thing to do is turn the question around and ask whether they mean from one thread at a time or only from one thread? If they say from only one thread EVER then say you'd use thread local storage (TLS) or refactor the code to pass the parameter down the call stack from the function the thread started in. If they "from one thread at a time" say you'd use the appropriate type of lock - usually a type of mutex.
The final thing before the interviewer moves on is to ask whether programmers use a lot of globals at this company... If they do consider asking for more money as you'll need it for the extra hours spent debugging gash code (and yes, this is from recent personal experience...)
Cheers,
Ash
|
|
|
|
|
Thanks guys,
Synchronization is what i replied, But as Aescleal get it right the interviewer was asking that the variable must be accessed only and only by one thread.. So i guess the TLS is the answer he wants, I need to see these thing in deep  Nevertheless i got the job
|
|
|
|
|
Normally if we have
class A{};
class B : public A{};
int f(A* x){};
B* y;
f(y).
works. However, if B is derived using protected from A, the code doesn't work anymore. Is there any way to get around this without changing protected back to public?
|
|
|
|
|
Since the base class is protected, none of the members of the base class can be accessed using its object or pointer.
All access will only be possible withing the class itself.
So you will not be able to access any members of the class using the x pointer.
|
|
|
|
|
I know, but that doesn't really answer my question. I'm not looking to access any members (except the constructor, which i'm guessing is called when the compiler tries to solve the cast). The question was whether I can change this without changing the protected to public (i.e. make ONLY the constructor public).
|
|
|
|
|
If you do not want to access any members, you really don't need an object.
|
|
|
|
|
We're only accessing members of the sub-class that are overwritten and declared public in the super-class, so it does work. For the implicit cast, the constructor of the base class has to be public. Can this be changed?
|
|
|
|
|
Not really. The protected keyword is doing what it's supposed to do by disallowing the cast.
Steve
|
|
|
|
|
Try it with explicit conversion, like:
...
B* y;
f((A *)y);
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Computers don't kill programs, users kill programs <
> "It doesn't work, fix it" does not qualify as a bug report. <
|
|
|
|
|
This does work but it's exactly the thing i'm trying to avoid.
|
|
|
|
|
An ugly solution but you could write "wrapper" methods that do the explicit conversations and call the originals, so if you have:
int f(A *pA) {}
then you could create
int f(B *pB) { return f((A *)pB); }
Of course i do not know what exactly you are trying to achieve so this might or might not solve your problem. And even if it does, you'd have to do this kind of crap for every method you want to use so i supose it's not a comfortable solution at all...
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Computers don't kill programs, users kill programs <
> "It doesn't work, fix it" does not qualify as a bug report. <
|
|
|
|
|
No, no way without an explicit cast or maybe a using statement in the derived class. What you're saying is that B is a class that can use A's public members but no one else can. There's no safe reason why you'd want to convert a B * to an A* - the two aren't type compatible.
I'm not trying to be (too) judgemental here, but have you ever considered you're programming in the wrong language? In both your recent posts you've wanted a duck-typed language, one that really doesn't give two hoots what you do with objects - they'll make up their minds at run time whether they want to play or not. If that's the case then use something like Smalltalk or Python that explicitly allows what you want to do - C++ is always going to frustrate you with its stronger typing and lack of emphasis on allowing programmers to use arbitrary runtime type conversions.
Cheers,
Ash
PS: I've think I've finally grokked what your problem is - have a look at the post I've just made in the other thread on this subject.
modified on Thursday, June 17, 2010 4:37 AM
|
|
|
|
|
Yet you are being judgemental. I'm merely trying to take code that is already written for quite some time and adapt it. It wasn't me who wrote it, just trying to make it easier to use. If it were up to me I would have also taken a totally different approach. But it's not.
|
|
|
|
|
You're not actually trying to make it easier to use, what you're trying to do is subvert the type system and turn off all the alarm bells. That's fairly unfriendly for the poor mug that comes after you - the poor sod who finds that things aren't behaving the way any sane and experienced C++ programmer expected it to.
So if you don't want to change any existing code (e.g. to convert it to use template functions) then keep the casts. It signals to future maintainers that there's something a bit weird here and they should watch their nuts.
|
|
|
|
|
Basically, you want to break the rules of C++ and then complain about having to use an explicit cast to inform the compiler you really do want to break the rules and you don't care about the consequences. Why are you so resistive to the casts? And if this is a production environment, you need to inform future maintainers that you at least thought about the consequences of breaking the rules.
Once you agree to clans, tribes, governments...you've opted for socialism. The rest is just details.
|
|
|
|
|
Does anyone know if it's possible to print graphics using Direct2D together with a printer-based HDC (i.e. CPrintInfo, DoPreparePrinting(), etc)?
Using the ID2D1DCRenderTarget interface and the BindDC method works just fine when drawing to a screen-based DC (or to a bitmap, which is blitted to screen later), but when the DC represents a printer the BindDC method returns E_INVALIDARG.
D2D1_RENDER_TARGET_PROPERTIES props = D2D1::RenderTargetProperties(
D2D1_RENDER_TARGET_TYPE_HARDWARE,
D2D1::PixelFormat(DXGI_FORMAT_B8G8R8A8_UNORM, D2D1_ALPHA_MODE_IGNORE),
0,
0,
D2D1_RENDER_TARGET_USAGE_NONE,
D2D1_FEATURE_LEVEL_DEFAULT);
ID2D1DCRenderTargetPtr pRT;
Globals::g_D2DFactory->CreateDCRenderTarget(&props, &pRT);
int sizeX=pDC->GetDeviceCaps(HORZSIZE);
int sizeY=pDC->GetDeviceCaps(VERTSIZE);
CRect rect(0, 0, sizeX, sizeY);
hr = pRT->BindDC(pDC->m_hDC, rect);
if (FAILED(hr))
{
const char* szErr = DXGetErrorStringA(hr);
const char* szDesc = DXGetErrorDescriptionA(hr);
ATLTRACE("BindDC: %s - %s\n", szErr, szDesc);
}
pDC->MoveTo(10,10);
pDC->LineTo(200,200);
The same thing happens if the DC is a CMetaFileDC.
The DC seems to be OK, because it works just fine to draw GDI onto that DC.
Is the ID2D1RenderTarget created with incompatible parameters? Should I pass a different pixel format?
Please help.
Thanks.
|
|
|
|
|
D2D does not support rendering to a printer DC. You can render to a WIC bitmat target and then bitblit to the printer DC.
Salvador Patuel
MSFT
|
|
|
|
|
Hi,
Anyone know how to write text to a pdf file using vc++?
Thanks,
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
