> some people are just too dumb to see the advantages that goto statement offers
Fair enough, but if you read the tone of my post I did not say goto never makes sense, just that I personally have never used it and that pretty much everyone seems to be taught goto is evil. Personally, I would be willing to entertain valid usages. I think it must exist in multiple languages for a reason.
if(status) goto done;
Which of them do you think is easier to read and maintain???
I have seen code like this before. I personally prefer nested if’s to facilitate cleanup lining up clearly through horizontal indentation. Both approaches I think are ugly. It’s a developer decision. C++ Exceptions would solve this elegantly however.
No, I’m not. Last thing I remember was the GDI drivers ( on the graphics side), and IIRC it has C++.
Where does it live in the stack ? Is it top level driver ?
If it can be executed in arbitrary context, can you use exception ? I guess not !
-Pro
On Jul 8, 2018, at 10:45 PM, xxxxx@probo.com wrote:
>
> On Jul 7, 2018, at 8:55 AM, xxxxx@gmail.com wrote:
>>
>> Once MS comes with c++ WDK, with examples, we will surely follow.
>
> Perhaps you are not aware that multimedia drivers (AVStream and Port-class audio drivers) have been written in C++ for 20 years, with full Microsoft support, including the samples.
> —
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>
> I don’t like hiding stuff when in kernel mode, so I spend as
less time as possible in kernel debugging
The problem is, one person’s “hiding” is another’s safety. Do RAII patterns “hide” things, in your view?
Take std::lock_guard as an example. Do you hate this?
I, for one, *love* this paradigm for locking… You’re not *hiding* the lock release, it’s just implicit as part of the acquisition. Take the time and write a few comments if clarity concerns you, for goodness sakes.
When using std::lock_guard, there’s no chance of confusion because “we all know” what lock_guard does.
The only potential problem I see with this pattern is if you create your own RAII patterned class “PGV_Acquire_Spinlock(PKSPIN_LOCK)” in your driver (this does work BTW), it *might* take somebody a few minutes to figure out how that works… But with judicious appropriate comments, all should be well, and your chances of leaving the function’s scope without releasing the lock are zero.
Peter
OSR
@OSRDrivers