A Collection of Useful C++ Classes for Signal Processing

[earlevel]

Stuff of the form "*x++ = x;" is not all that hare-brained,

Let me just stop you there. Yes it is.

btw; I did read your entire post and yes, this sort of thing is rarely used because it's unnecessary, doesn't provide any real advantage to anyone and in fact limits the compiler's ability to optimize on top of the fact it is simply bad code which creates undefined behavior and will almost inevitably lead to some sort of bug.

I just don't see the point in observing that, the issue in this thread is whether it is in fact a bug. Yes, it is a bug.

Oh, thank you so much for clearing that up. And, no, your example code line (*x++, etc.) was hare-brained—stuff that no one would dream of writing except to show insane code.

I was just pointing out that it exists—I gave examples (are the authors hare-brained? Or did they have a reasonable, if misguided, expectation in their mistakes?). I don't use it. Obviously, I did in one line of code in 1989—just being honest, not demanding that every compiler honor the intention (obviously, the compiler I used for the product did). I can't recall the last time I used pointers to step through data, many years. I use indexing. I don't see the point of the mess of manipulating pointers with today's compilers and processors.

Again, and for the last time I hope, I'm just surprised that a compiler won't do it. The reason I'm surprised, again, is that I can't fathom the resulting object code not being slower and more convoluted as a result. It's my point, and it doesn't matter that it's not what you think is "the issue in this thread".

Peace—not meaning to argue, just feeling misunderstood. Clearly, if you think I should find a standards committee to bitch to, you misunderstand me.

[aciddose]

Yes I still don't understand what your point is?

stuff that no one would dream of writing except to show insane code.

So what is your point? I see "*x++ = x;" as exactly the same. They're both buggy, poorly thought out code which are at best written by mistake and more likely written due to misunderstanding of the language.

"modify(x) oper x" is simply something you do not do, ever, regardless of the format.

"function(x++, x);" is identical in this respect just as "function(x++, x--)" or any other combination of operators applied to x while x is used more than once in a statement.

Going into all this detail regarding what is harebrained or not harebrained is itself harebrained. All of these are harebrained of equal magnitude for the same reason: they disobey the rule "any statement in which the outcome depends upon the order of operations will result in unspecified/undefined behavior".

You simply can not ever write code which depends upon the order of operations, it is defined as bad by the standard itself!

[earlevel]

Yes I still don't understand what your point is?

stuff that no one would dream of writing except to show insane code.

So what is your point? I see "*x++ = x;" as exactly the same. They're both buggy, poorly thought out code which are at best written by mistake and more likely written due to misunderstanding of the language.

"modify(x) oper x" is simply something you do not do, ever, regardless of the format.

"function(x++, x);" is identical in this respect just as "function(x++, x--)" or any other combination of operators applied to x while x is used more than once in a statement.

Going into all this detail regarding what is harebrained or not harebrained is itself harebrained. All of these are harebrained of equal magnitude for the same reason: they disobey the rule "any statement in which the outcome depends upon the order of operations will result in unspecified/undefined behavior".

You simply can not ever write code which depends upon the order of operations, it is defined as bad by the standard itself!

To be clear, of course "*x++ = x;" is exactly the same—that's why I gave it as an example. By "hare-brained" I mean insane, not wrong. If I saw this in someone's code, I would not assume that they had lost all control of their mental faculties. If I saw "*y++ = (*x++ = (*y++ = *x++) * *x++) * *y++;", I would think that.

I accept that you don't understand my point, even though I've said it several times. Now, please understand that you are not telling me anything new by stating, over and over, that the behavior is undefined and should not be used. Thanks.

[aciddose]

So you're talking about your subjective interpretation of two technically identical (as far as qualifications are concerned) statements and how they reflect upon the author's ability to "control their mental faculties" ?

I still don't see your point.

My point was that you should view both as identical, because they are identical. The statement you give as an example is no different from my example, both are equally insane. They have both crossed the threshold of "valid" to "invalid" statements.

[aciddose]

Modifying a variable of a built-in type and using that variable in the same expression is undefined behavior.

So, the OP was correct. I was wrong and this is a bug. You just might get lucky as I did depending on the compiler used. The source should be fixed. The code is in at least 2 places.

I think you're still referring to this?

Code: Select all

*dest++ = state.process (*dest, *this);

"Expression" is what's on the right side of the "=". This is the type of statement that your bolded test is warning against:

Code: Select all

x = *source + *source++;  // this is undefined

Apologies if I'm misreading you, but it seems like you are saying that the former ("*dest++ =...") behavior is not defined. But it is. Assignment doesn't occur until after the expression is resolved.

This post was the one at issue, what you say in it is incorrect.

[ChocoBilly]

Basically, don't "*foo++" and use "*foo" on the same line and expect consistent results across compilers.
http://stackoverflow.com/questions/2733 ... mpiler-why

[earlevel]

...Apologies if I'm misreading you, but it seems like you are saying that the former ("*dest++ =...") behavior is not defined. But it is. Assignment doesn't occur until after the expression is resolved.

This post was the one at issue, what you say in it is incorrect.

Yes, I was incorrect in my first look at it. As was ChocoBilly, whom I was replying to, and as were you—we all got caught on the hare-brained statement:

If you read the actual spec you will see that the precedence is very strictly specified. There are no variations like this in critical areas like this, do you think the spec is designed by a group of fools?

*x++ = value;
...
So, this is equivalent to:

data = (value);
reference = (*x);
reference = data;
x = (x + 1);

In all compilers, all the time, everywhere. (Unless they're broken.)

[aciddose]

Yes the operator precedence, but my post was totally idiotic, I didn't even realize what the issue was at first.

Operator precedence wasn't the issue, the issue is when you have multiple operators that occur as far as precedence is concerned in parallel the compiler must decide to use left-to-right or right-to-left or any random variation it chooses.

So ultimately, code must not depend upon order of operations when they are parallel.

*x++ = x; is an example of this, while *x++ = value; has nothing to do with it. My statement was only with regard to the fact the value is read and stored, then x is incremented, then the stored value is dereferenced, then the assignment occurs. This is certain because it is according to strictly defined operator precedence.

What is undefined behavior is whether the left or right side of the assignment operator is evaluated first.

[earlevel]

Well, I can tell you that when I wrote that line in 1989, the compilers didn't warn of a potential problem. Now they do, so there shouldn't be an excuse, if the programmer ignores it.

PS—I don't think there was a definition of what was defined or not in this regard till C89 anyway. But my point is that I'd expect any compiler to warn if you try to do that these days.

[Miles1981]

No, the arguments weren't 16-bit ints. I wouldn't be using it as an example of idiotic compiler behavior if that were the case. It had to do with the spec saying that intermediate results would assume int—but this was written with the assumption that ints were the natural size of the processor ALU, and assumed that that any promotion would be upward, whereas Think C defined int as 16-bit for the 32-bit 68k family, and the "promotion" would be downward. I think there might have been another nuance, like one of the values being a constant. The thing is that they knew it would break an otherwise natural-looking computation, but they thought they were causing it to fail with the same results as other compliant compilers. Anyway, it was 25 years ago or so, and the compiler went from being the darling of Mac programmers to unused pretty quickly.

Thans for the explanation, because this wasn't clear

[earlevel]

Thans for the explanation, because this wasn't clear

Yeah, I know that I left out that important detail, sorry about that.

[Android123]

AUTO-ADMIN: Non-MP3, WAV, OGG, SoundCloud, YouTube, Vimeo, Twitter and Facebook links in this post have been protected automatically. Once the member reaches 5 posts the links will function as normal.

I have tried to implement a Filter for a telephone effect.
An existing .wav File shall be altered.

The best result I get with a ChebyshevI BandPass filter. However the result ist not good enough.
After applying the filter there is much noise in the background and the voice is not clear anymore.

Do you have any suggestions how to improve this or how to implement a telephone effect at all?

Here is my code:

Code: Select all (#)

int numSamples = 512;
float* audioData[1];
audioData[0] = new float[numSamples];
	
Dsp::Filter* f = new Dsp::FilterDesign
<Dsp::ChebyshevI::Design::BandPass <5>, 1>;
Dsp::Params params;
params[0] = 48100; // sample rate
params[1] = 5; // order
params[2] = 1400; // center frequency
params[3] = 1100; // band width
params[4] = 0.01; //rippleDB
f->setParams (params);

short int buff16[numSamples];// short int used for 16 bit as input data format is 16 bit PCM audio

while (!feof(infile)) {
			nb = fread(buff16, 1, numSamples, infile);
         int i;
			for(i=0;i<numSamples;i++){
				audioData[0][i] = (float) buff16[i];
			}

         f->process(numSamples, audioData);

         for(i=0;i<numSamples;i++){
				buff16[i] = (int)audioData[0][i];
	      }
			
			fwrite(buff16, 1, nb, outfile);
}

I get the input data in an int array. Therefore I have to convert it for the filter.

[Miles1981]

And did you check if the output was outside [-1,1]?

[ChocoBilly]

Don't cast as float. If you're going to convert to floats, convert your +32767 to -32768 to +1.0/-1.0 work as floats then convert back to shorts to save back as 16 bit wave.

[julijannikolic]

Hi guys, I am having trouble to build DSP filters DEMO app. Does someone have exe file to post here, or can someone help me to buil it? Here is what I get in VS2010:

1>------ Build started: Project: DSPFiltersDemo, Configuration: Debug Win32 ------
1>Build started 31.5.2015 12:49:48.
1>InitializeBuildStatus:
1> Touching "Debug\DSPFiltersDemo.unsuccessfulbuild".
1>ClCompile:
1> All outputs are up-to-date.
1> demo_core.cpp
1> demo_gui.cpp
1> dsp_filters.cpp
1> juce_audio_basics_amalgam.cpp
1> juce_audio_devices_amalgam.cpp
1> juce_audio_formats_amalgam.cpp
1> juce_audio_processors_amalgam.cpp
1> juce_audio_utils_amalgam.cpp
1> juce_core_amalgam.cpp
1> juce_data_structures_amalgam.cpp
1> juce_events_amalgam.cpp
1> juce_graphics_amalgam.cpp
1> juce_gui_basics_amalgam.cpp
1> juce_gui_extra_amalgam.cpp
1>ResourceCompile:
1> All outputs are up-to-date.
1>LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt
1>
1>Build FAILED.
1>
1>Time Elapsed 00:00:06.87
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========