[GH-ISSUE #18] Idiom Question #14

Closed
opened 2026-05-05 22:01:43 -06:00 by gitea-mirror · 3 comments
Owner

Originally created by @baconpaul on GitHub (Aug 25, 2020).
Original GitHub issue: https://github.com/airwindows/airwindows/issues/18

Hi!

I have airwindows working nicely in surge. It is great.

One question. I compile surge on lots of compilers with warning levels high. Throughout the code you have this idiom

    *in1++;
    *in2++;

to advance the pointer. Since ++ has precedence over * this does * ( in1++ ) then discards the result of the dereference.

This though generates an unused-value error in clang. You aren't giving the value of the * operator to anything.

Any reason for this pattern in the code vs in1++ or out1++ or similar?

Thank you!

Originally created by @baconpaul on GitHub (Aug 25, 2020). Original GitHub issue: https://github.com/airwindows/airwindows/issues/18 Hi! I have airwindows working nicely in surge. It is great. One question. I compile surge on lots of compilers with warning levels high. Throughout the code you have this idiom ``` *in1++; *in2++; ``` to advance the pointer. Since ++ has precedence over * this does `* ( in1++ )` then discards the result of the dereference. This though generates an unused-value error in clang. You aren't giving the value of the `*` operator to anything. Any reason for this pattern in the code vs `in1++` or `out1++` or similar? Thank you!
Author
Owner

@airwindows commented on GitHub (Aug 25, 2020):

On 8 25, 2020, at 10:12 AM, Paul notifications@github.com wrote:

Hi!

I have airwindows working nicely in surge. It is great.

One question. I compile surge on lots of compilers with warning levels high. Throughout the code you have this idiom

*in1++;
*in2++;

to advance the pointer. Since ++ has precedence over * this does * ( in1++ ) then discards the result of the dereference.

This though generates an unused-value error in clang. You aren't giving the value of the * operator to anything.

Any reason for this pattern in the code vs in1++ or out1++ or similar?

That’s not my code. That’s from the plugin templates: looks like how Steinberg wants it.

If the way Steinberg makes VSTs isn’t working on a new platform it wasn’t designed for, you’ll need to change it. Since that’s obviously stepping through the sample data by incrementing position, you’ll know if it’s not working another way: the plugin will cease to pass audio. If it’s passing audio and working, then it’s not doing the wrong thing you claim it’s doing.

Chris
<!-- gh-comment-id:680090953 --> @airwindows commented on GitHub (Aug 25, 2020): > On 8 25, 2020, at 10:12 AM, Paul <notifications@github.com> wrote: > > > Hi! > > I have airwindows working nicely in surge. It is great. > > One question. I compile surge on lots of compilers with warning levels high. Throughout the code you have this idiom > > *in1++; > *in2++; > > to advance the pointer. Since ++ has precedence over * this does * ( in1++ ) then discards the result of the dereference. > > This though generates an unused-value error in clang. You aren't giving the value of the * operator to anything. > > Any reason for this pattern in the code vs in1++ or out1++ or similar? That’s not my code. That’s from the plugin templates: looks like how Steinberg wants it. If the way Steinberg makes VSTs isn’t working on a new platform it wasn’t designed for, you’ll need to change it. Since that’s obviously stepping through the sample data by incrementing position, you’ll know if it’s not working another way: the plugin will cease to pass audio. If it’s passing audio and working, then it’s not doing the wrong thing you claim it’s doing. Chris
Author
Owner

@baconpaul commented on GitHub (Aug 25, 2020):

Yeah cool OK. It is easy for me to change (or disable the warning) just was curious if there was a reason. Thank you. Will close this. (I chose to integrate Airwindows by using the VST2 wrappers on them and stubbing out a fake VST2 adapter to the surge FX class).

Our nightly just dropped with Airwindows included by the way. About 50 of your FX are now available in the surge effect path and modulation architecture. Thanks again for making open source software.

<!-- gh-comment-id:680096873 --> @baconpaul commented on GitHub (Aug 25, 2020): Yeah cool OK. It is easy for me to change (or disable the warning) just was curious if there was a reason. Thank you. Will close this. (I chose to integrate Airwindows by using the VST2 wrappers on them and stubbing out a fake VST2 adapter to the surge FX class). Our nightly just dropped with Airwindows included by the way. About 50 of your FX are now available in the surge effect path and modulation architecture. Thanks again for making open source software.
Author
Owner

@baconpaul commented on GitHub (Aug 25, 2020):

Oh and just to follow up on this if you replace the *in1++; with the in1++; and so on everything works (of course) but you do avoid that extra dereference into the void - and the warning on modern mac and linux compilers.

I can't see why steinberg put such a clearly pointless bit of C++ code in their wrapper but glad to know I can just knock it out and remove my warning suppression!

Thanks!

<!-- gh-comment-id:680122752 --> @baconpaul commented on GitHub (Aug 25, 2020): Oh and just to follow up on this if you replace the `*in1++;` with the `in1++;` and so on everything works (of course) but you do avoid that extra dereference into the void - and the warning on modern mac and linux compilers. I can't see why steinberg put such a clearly pointless bit of C++ code in their wrapper but glad to know I can just knock it out and remove my warning suppression! Thanks!
Sign in to join this conversation.
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/airwindows#14
No description provided.