473,692 Members | 2,227 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Non-container Iterators

My area of programming is DSP. I write things like filters, oscillators,
envelopes, etc. I've been looking at STL iterators, and what's struck me is
that if I can find ways to model my code using STL's iterator conventions, I
could possibly make my code more economic while probably losing little to no
efficiency.

As an example, an oscillator will have a "phase accumulator." So typically
in a loop I will have something like this:
phaseAccumulato r += phaseIncrement;

if(phaseAccumul ator >= 1.0f)
{
phaseAccumulato r -= 1.0f;
}

output = waveform(phaseA ccumulator);
It occurred to me that I could have a phase accumulator iterator. My code
would turn into this:
phaseAccumulato r++;

output = waveform(*phase Accumulator);
Much more compact. Or even better:
std::transform( phaseFirst, phaseLast, outputBuffer, SineWaveform()) ;
Down to just one line of code. Ok, so far, so good. But there is a gray area
I'm concerned about.

I need to keep track of the phase. The phase is state that needs to persist
across iterations. This means that I need to give the iterator a pointer to
the phase variable when I create it so that as it's iterating, it's also
modifying the phase variable. Something like:

// Inside my Oscillator class somewhere:
it = PhaseIterator it(&phase, increment);

// Inside the PhaseIterator class:
PhaseIterator &operator++( )
{
*phase += increment;

if(phase >= 1.0f)
{
phase -= 1.0f;
}

return *this;
}
This works, but it means that I can only use one phase iterator at a time.
That's actually not a problem for me since the iterator is only being used
internally by the Oscillator class, but my question is whether this violates
the spirit of STL iterators. Is there a category of iterators (Input
Iterators, perhaps?) that restrict you to using only one iterator at a time
over a collection?

Advancing an iterator doesn't usually involve changing the collection the
iterator belongs to. However, in this case, the collection is the phase
values belonging to the oscillator; the iterator is actually generating the
phase values that drive oscillation. I like this approach, but was wanting
to get some thoughts on this from others.
Jul 24 '08 #1
7 1641
First, my apologies for the double post. Second, my apologies for replying
to my own post. :-)

After further thought, I don't think iterators are the way to model my phase
accumulator. Rather I think the concept of Generator, a nullary function
that returns a value, is a better model. So I came up with this:
class PhaseAccumulato r
{
public:
typedef float result_type;

private:
float *phase;
float increment;

public:
PhaseAccumulato r(float *phase, float increment)
{
this->phase = phase;
this->increment = increment;
}

result_type operator()()
{
*phase += increment;

if(*phase >= 1.0f)
{
*phase -= 1.0f;
}

return *phase;
}
};
I use unary functions for my waveforms; they argument is the phase. I need
to fed the output of my PhaseAccumulato r into a Waveform object. In looking
at the STL, I haven't found an adapter to do this; I could be missing
something. So I wrote my own:
template<typena me Generator, typename UnaryFunction>
class NullaryCompose
{
public:
typedef typename Generator::resu lt_type result_type;

private:
Generator myG;
UnaryFunction myF;

public:
NullaryCompose( Generator g, UnaryFunction f) :
myG(g),
myF(f)
{
}

result_type operator()()
{
return myF(myG());
}
};
Which allows me to do this:
PhaseAccumulato r phaseAccumulato r(&phase, increment);
NullaryCompose< PhaseAccumulato r, WaveShapes::Sin enc(phaseAccumu lator,
WaveShapes::Sin e());

std::generate(& buffer[0], &buffer[100], nc);
I think modeling these sorts of components as function objects makes more
sense than modeling them as iterators.
Jul 24 '08 #2
Good grief this is frustrating. Viewing this group through Google
Groups, I have apparently triple posted. The third post was *suppose*
to be 1) an apology for double posting, and 2) further thoughts on how
my phase accumulator would be better modeled using STL's idea of a
Generator instead of an Iterator. But I'm wary of reposting that at
this point.

Sorry folks.
Jul 24 '08 #3
"Leslie Sanford" <ja**********@b itemehotmail.co mwrote:
My area of programming is DSP. I write things like filters, oscillators,
envelopes, etc. I've been looking at STL iterators, and what's struck me is
that if I can find ways to model my code using STL's iterator conventions, I
could possibly make my code more economic while probably losing little to no
efficiency.
Then you might find this interesting:

class fibonacci: public std::iterator< std::forward_it erator_tag, int >
{
int prev_value, value, max;
public:
fibonacci(): prev_value(0), value(0), max(0) { }
explicit fibonacci(int m): prev_value(0), value(1), max(m) { }
const int operator*() const { return value; }
fibonacci& operator++() {
int tmp = value;
value += prev_value;
prev_value = tmp;
return *this;
}
fibonacci operator++(int) {
fibonacci tmp(*this);
++(*this);
return tmp;
}
friend bool operator==(cons t fibonacci& lhs, const fibonacci& rhs) {
bool result = false;
if ( lhs.value == 0 && rhs.value == 0 ) result = true;
else if ( rhs.value == 0 && !( lhs.value < lhs.max ) )
result = true;
else if ( lhs.value == 0 && !( rhs.value < rhs.max ) )
result = true;
else if ( lhs.prev_value == rhs.prev_value &&
lhs.value == rhs.value &&
lhs.max == rhs.max )
result = true;
return result;
}
};

bool operator!=(cons t fibonacci& lhs, const fibonacci& rhs) {
return !(lhs == rhs);
}
int main() {
copy( fibonacci( 20 ), fibonacci(),
ostream_iterato r<int>( cout, " " ) );
cout << '\n';
}
As an example, an oscillator will have a "phase accumulator." So typically
in a loop I will have something like this:
phaseAccumulato r += phaseIncrement;

if(phaseAccumul ator >= 1.0f)
{
phaseAccumulato r -= 1.0f;
}

output = waveform(phaseA ccumulator);
It occurred to me that I could have a phase accumulator iterator. My code
would turn into this:
phaseAccumulato r++;

output = waveform(*phase Accumulator);
Much more compact. Or even better:
std::transform( phaseFirst, phaseLast, outputBuffer, SineWaveform()) ;
Down to just one line of code. Ok, so far, so good. But there is a gray area
I'm concerned about.

I need to keep track of the phase. The phase is state that needs to persist
across iterations. This means that I need to give the iterator a pointer to
the phase variable when I create it so that as it's iterating, it's also
modifying the phase variable. Something like:

// Inside my Oscillator class somewhere:
it = PhaseIterator it(&phase, increment);

// Inside the PhaseIterator class:
PhaseIterator &operator++( )
{
*phase += increment;

if(phase >= 1.0f)
{
phase -= 1.0f;
}

return *this;
}
This works, but it means that I can only use one phase iterator at a time.
Not if you put 'phase' inside the iterator. Then you can give two
iterators the same phase and increment and advance each of them a
different amount, and they will each be at a different spot in the
"container" .

The key is to provide a sentinel iterator. In your case, the sentinel
can be a PhaseIterator that has an increment of 0.

class PhaseIterator : public std::iterator< std::forward_it erator_tag,
int >
{
float phase;
float increment;
int step;
int max;
public:
PhaseIterator() : phase(0), increment(0), step(0), max(0) { }
explicit PhaseIterator(f loat i, int m):
phase(0), increment(i), step(0), max(m) { }
const float operator*() const { return phase; }
PhaseIterator& operator++() {
phase += increment;
if ( phase >= 1.0f )
phase -= 1.0f;
++step;
return *this;
}
PhaseIterator operator++(int) {
PhaseIterator tmp(*this);
++(*this);
return tmp;
}
friend bool operator==(cons t PhaseIterator& lhs,
const PhaseIterator& rhs) {
bool result = false;
if ( lhs.phase == rhs.phase && lhs.increment == rhs.increment )
result = true;
else if ( rhs.increment == 0 && !( lhs.step < lhs.max ) )
result = true;
else if ( lhs.increment == 0 && !( rhs.step < rhs.max ) )
result = true;
return result;
}
};

bool operator!=(cons t PhaseIterator& lhs, const PhaseIterator& rhs) {
return !(lhs == rhs);
}
int main() {
copy( PhaseIterator( 0.07, 20 ), PhaseIterator() ,
ostream_iterato r<float>( cout, " " ) );
cout << '\n';
}
Jul 25 '08 #4

"Daniel T." wrote:
"Leslie Sanford" wrote:
>My area of programming is DSP. I write things like filters, oscillators,
envelopes, etc. I've been looking at STL iterators, and what's struck me
is that if I can find ways to model my code using STL's iterator
conventions, I could possibly make my code more economic while
probably losing little to no efficiency.

Then you might find this interesting:

class fibonacci: public std::iterator< std::forward_it erator_tag, int >
<snip>

Yes, indeed. That is very interesting.

<snip>
>I need to keep track of the phase. The phase is state that needs to
persist across iterations. This means that I need to give the iterator a
pointer to the phase variable when I create it so that as it's iterating,
it's also modifying the phase variable. Something like:

// Inside my Oscillator class somewhere:
it = PhaseIterator it(&phase, increment);

// Inside the PhaseIterator class:
PhaseIterato r &operator++( )
{
*phase += increment;

if(phase >= 1.0f)
{
phase -= 1.0f;
}

return *this;
}
This works, but it means that I can only use one phase iterator at a
time.

Not if you put 'phase' inside the iterator. Then you can give two
iterators the same phase and increment and advance each of them a
different amount, and they will each be at a different spot in the
"container" .
Understood.
The key is to provide a sentinel iterator. In your case, the sentinel
can be a PhaseIterator that has an increment of 0.
In this case, there is no sentinel iterator as an oscillator, which a phase
accumulator drives, can cycle indefinitely, a kind of circular buffer, I
suppose.

Is it acceptable for an iterator to never reach an "end"? I would have
another way for testing for the end of the loop, specifically the end of the
buffer that I'm filling. I should be able to increment the phase iterator
indefinitely.

while(first != last)
{
*first = *phase;

phase++;
first++;
}

Since (triple) posting, I've been giving this approach some thought, and I
was wondering if a Generator would be a more appropriate model than an
Iterator to represent a phase accumulator.

http://www.sgi.com/tech/stl/Generator.html

class PhaseAccumulato r
{
public:
typedef float result_type;

private:
float phase;
float increment;

public:
PhaseAccumulato r(float phase, float increment)
{
this->phase = phase;
this->increment = increment;
}

result_type operator()()
{
phase += increment;

if(phase >= 1.0f)
{
phase -= 1.0f;
}

return phase;
}
};

I can have a Square waveform represented as a unary function:

typedef std::unary_func tion<float, floatWaveShapeB ase;

struct Square : public WaveShapeBase
{
result_type operator()(argu ment_type phase) const
{
assert(phase >= 0.0f && phase < 1.0f);

return phase < 0.5f ? -1.0f : 1.0f;
}
};

And use both in a loop to fill a buffer:

class Oscillator
{
PhaseAccumulato r phase;
Square wave;

public:
// Stuff...

void Process(float *first, float *last)
{
while(first != last)
{
*first = wave(phase());

first++;
}
}
}

Maybe this is a more appropriate approach given the concepts involved?


Jul 25 '08 #5
On Jul 24, 11:18*pm, "Leslie Sanford" <jabberdab...@b itemehotmail.co m>
wrote:
In this case, there is no sentinel iterator as an oscillator, which a phase
accumulator drives, can cycle indefinitely, a kind of circular buffer, I
suppose.

Is it acceptable for an iterator to never reach an "end"? I would have
another way for testing for the end of the loop, specifically the end of the
buffer that I'm filling. I should be able to increment the phase iterator
indefinitely.

while(first != last)
{
* * *first = *phase;

* * phase++;
* * first++;

}

Since (triple) posting, I've been giving this approach some thought, and I
was wondering if a Generator would be a more appropriate model than an
Iterator to represent a phase accumulator.

http://www.sgi.com/tech/stl/Generator.html

class PhaseAccumulato r
{
public:
* * typedef float result_type;

private:
* * float phase;
* * float increment;

public:
* * PhaseAccumulato r(float phase, float increment)
* * {
* * * * this->phase = phase;
* * * * this->increment = increment;
* * }

* * result_type operator()()
* * {
* * * * phase += increment;

* * * * if(phase >= 1.0f)
* * * * {
* * * * * * phase -= 1.0f;
* * * * }

* * * * return phase;
* * }

};

I can have a Square waveform represented as a unary function:

typedef std::unary_func tion<float, floatWaveShapeB ase;

struct Square : public WaveShapeBase
{
* * result_type operator()(argu ment_type phase) const
* * {
* * * * assert(phase >= 0.0f && phase < 1.0f);

* * * * return phase < 0.5f ? -1.0f : 1.0f;
* * }

};

And use both in a loop to fill a buffer:

class Oscillator
{
* * PhaseAccumulato r phase;
* * Square wave;

* * public:
* * * * // Stuff...

* * void Process(float *first, float *last)
* * {
* * * * while(first != last)
* * * * {
* * * * * * *first = wave(phase());

* * * * * * first++;
* * * * }
* * }

}

Maybe this is a more appropriate approach given the concepts involved?
Since the phase can't "end" in any meaningful sense, a generator may
be a more appropriate design pattern. Pseudo-random number generators
(eventually) loop, too, and they're commonly used as generator
functors. That being said, there certainly are generator-style
iterators out there, e.g. boost::counting _iterator:

http://www.boost.org/doc/libs/1_35_0..._iterator.html

Using something like that approach, your oscillator class might look
like:

void Oscillator::Pro cess(float *begin, float *end)
{
// Generate
std::transform(
phase.begin(),
phase.end( std::distance(b egin,end) ),
begin,
Square );
}

I assume the phase has been given counting_iterat or-like support,
where the end() function takes a parameter telling it how many times
to increment. Note also that you could convert your square wave
functor to an ordinary function with the signature float Square(float)
since it doesn't take any constructor parameters or maintain mutable
state. The member variable for that functor is overkill.

The down-side to this approach is that the use of std::transform( )
with a generator-style iterator to generate is takes some thinking,
and one of our goals for code is (or, should be) to make it readable.
The names of the standard functions are intended to communicate your
meaning rather than obscure it (cf. http://www.ddj.com/cpp/184401446),
but generator-style iterators cut against the grain in a circumstance
like this.

A generator approach: Using functional composition [let's call ours
my_compose(f,g) = f(g())], whose implementation is relatively
straightforward and similar to the common extension to the STL (e.g.,
http://www.sgi.com/tech/stl/unary_compose.html), one can make this
clearer on first reading:

std::generate( begin, end, my_compose( Square, phase ) );

Now fewer tricks are being played, and its meaning should be clearer
to someone reading your code down the line (which could be you).

Cheers! --M
Jul 25 '08 #6
On Jul 24, 11:18*pm, "Leslie Sanford" <jabberdab...@b itemehotmail.co m>
wrote:
"Daniel T." wrote:
"Leslie Sanford" wrote:
My area of programming is DSP. I write things like filters, oscillators,
envelopes, etc. I've been looking at STL iterators, and what's struck me
is that if I can find ways to model my code using STL's iterator
conventions, I could possibly make my code more economic while
probably losing little to no efficiency.
Then you might find this interesting:
class fibonacci: public std::iterator< std::forward_it erator_tag, int >

<snip>

Yes, indeed. That is very interesting.

<snip>


I need to keep track of the phase. The phase is state that needs to
persist across iterations. This means that I need to give the iteratora
pointer to the phase variable when I create it so that as it's iterating,
it's also modifying the phase variable. Something like:
// Inside my Oscillator class somewhere:
it = PhaseIterator it(&phase, increment);
// Inside the PhaseIterator class:
PhaseIterator &operator++( )
{
* * *phase += increment;
* * *if(phase >= 1.0f)
* * {
* * * * phase -= 1.0f;
* * }
* * return *this;
}
This works, but it means that I can only use one phase iterator at a
time.
Not if you put 'phase' inside the iterator. Then you can give two
iterators the same phase and increment and advance each of them a
different amount, and they will each be at a different spot in the
"container" .

Understood.
The key is to provide a sentinel iterator. In your case, the sentinel
can be a PhaseIterator that has an increment of 0.

In this case, there is no sentinel iterator as an oscillator, which a phase
accumulator drives, can cycle indefinitely, a kind of circular buffer, I
suppose.

Is it acceptable for an iterator to never reach an "end"? I would have
another way for testing for the end of the loop, specifically the end of the
buffer that I'm filling. I should be able to increment the phase iterator
indefinitely.

while(first != last)
{
* * *first = *phase;

* * phase++;
* * first++;

}

Since (triple) posting, I've been giving this approach some thought, and I
was wondering if a Generator would be a more appropriate model than an
Iterator to represent a phase accumulator.

http://www.sgi.com/tech/stl/Generator.html

class PhaseAccumulato r
{
public:
* * typedef float result_type;

private:
* * float phase;
* * float increment;

public:
* * PhaseAccumulato r(float phase, float increment)
* * {
* * * * this->phase = phase;
* * * * this->increment = increment;
* * }

* * result_type operator()()
* * {
* * * * phase += increment;

* * * * if(phase >= 1.0f)
* * * * {
* * * * * * phase -= 1.0f;
* * * * }

* * * * return phase;
* * }

};

I can have a Square waveform represented as a unary function:

typedef std::unary_func tion<float, floatWaveShapeB ase;

struct Square : public WaveShapeBase
{
* * result_type operator()(argu ment_type phase) const
* * {
* * * * assert(phase >= 0.0f && phase < 1.0f);

* * * * return phase < 0.5f ? -1.0f : 1.0f;
* * }

};

And use both in a loop to fill a buffer:

class Oscillator
{
* * PhaseAccumulato r phase;
* * Square wave;

* * public:
* * * * // Stuff...

* * void Process(float *first, float *last)
* * {
* * * * while(first != last)
* * * * {
* * * * * * *first = wave(phase());

* * * * * * first++;
* * * * }
* * }

}

Maybe this is a more appropriate approach given the concepts involved?
That sounds like it would work. Then your process function can be
replaced by the generate algorithm.

float arr[20];
generate( arr, arr + 20, PhaseAccumulato r(0, 0.3) );

or better:

vector< float arr;
generate_n( back_inserter( arr ), 20, PhaseAccumulato r(0, 0.3) );

But if you make a powerful enough PhaseAccumulato r iterator, you won't
*need* to fill the array with values, you can use the iterator
directly over the calculated container.
Jul 25 '08 #7

"mlimber" wrote:
>
A generator approach: Using functional composition [let's call ours
my_compose(f,g) = f(g())], whose implementation is relatively
straightforward and similar to the common extension to the STL (e.g.,
http://www.sgi.com/tech/stl/unary_compose.html), one can make this
clearer on first reading:

std::generate( begin, end, my_compose( Square, phase ) );
I like this approach; the idea of function composition is appealing. The
problem is handling state. The waveform function object is stateless, a true
function. However, the phase accumulator has state, specifically the value
of its phase. Say I have the following:

void Oscillator::Pro cess(float *begin, float *end)
{
// Assumes a phase member variable.
std::generate(b egin, end, my_compose(Squa re(), phase);
}

Each time Process is called the phase needs to pick up from where it left
off with the previous call. However, 'phase' is passed in by value, so the
phase accumulator that's actually getting advanced by generate is a copy of
the original. The end result is that each time Process is called, phase
starts at the same place.

I see a couple of ways around this. Design the phase accumulator so that it
takes a pointer to the actual phase variable:

// Inside the Oscillator class..

// Member variable.
float phase;

//...

void Oscillator::Pro cess(float *begin, float *end)
{
std::generate(b egin, end, my_compose(Squa re(),
PhaseAccumulato r(&phase));
}

This ensures that the phase value that's getting incremented persists
between calls since the PhaseAccumulato r is incrementing the pointer
variable.

I suppose this solution is ok.

Another approach is to somehow update the phase accumulator after generate
has done its job:

void Oscillator::Pro cess(float *begin, float *end)
{
MyCompose<Squar e, PhaseAccumulato rmc(Square(), phase);

std::generate(b egin, end, mc);

// Assumes our custom compose template exposes the generator function
object.
phase = mc.generator;
}

This works as well. Another way is to explicitely tell the generate function
to treat the phase accumulator object as a reference, but then I'm pretty
sure I'd lose inlining in that case. Things would start to look ugly at that
point anyway.

Also, we can forego the convenience of using generate and simply write the
loop ourselves using the same member variables:

void Oscillator::Pro cess(float *first, float *last)
{
while(first != last)
{
// Assumes phase and wave are member variables.
*first = wave(phase());

first++;
}
}


Jul 25 '08 #8

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

5
3745
by: klaus triendl | last post by:
hi, recently i discovered a memory leak in our code; after some investigation i could reduce it to the following problem: return objects of functions are handled as temporary objects, hence their dtor is called immediately and not at the end of the function. to be able to use return objects (to avoid copying) i often assign them to a const reference. now, casting a const return object from a function to a non-const reference to this...
3
12238
by: Mario | last post by:
Hello, I couldn't find a solution to the following problem (tried google and dejanews), maybe I'm using the wrong keywords? Is there a way to open a file (a linux fifo pipe actually) in nonblocking mode in c++? I did something ugly like --- c/c++ mixture --- mkfifo( "testpipe", 777);
25
7621
by: Yves Glodt | last post by:
Hello, if I do this: for row in sqlsth: ________pkcolumns.append(row.strip()) ________etc without a prior:
32
4511
by: Adrian Herscu | last post by:
Hi all, In which circumstances it is appropriate to declare methods as non-virtual? Thanx, Adrian.
8
3503
by: Bern McCarty | last post by:
Is it at all possible to leverage mixed-mode assemblies from AppDomains other than the default AppDomain? Is there any means at all of doing this? Mixed-mode is incredibly convenient, but if I cannot load/unload/reload extensions into my large and slow-to-load application during development without restarting the process then the disadvantages may outweigh the advantages. I've got a mixed-mode program in which I create a new AppDomain...
14
8437
by: Patrick Kowalzick | last post by:
Dear all, I have an existing piece of code with a struct with some PODs. struct A { int x; int y; };
11
3428
by: ypjofficial | last post by:
Hello All, So far I have been reading that in case of a polymorphic class ( having at least one virtual function in it), the virtual function call get resolved at run time and during that the vtable pointer is made use of.. eg. class one {
2
6108
by: Ian825 | last post by:
I need help writing a function for a program that is based upon the various operations of a matrix and I keep getting a "non-aggregate type" error. My guess is that I need to dereference my pointers, but I'm not sure. Please help. The code: void equate(matrix *A, matrix *B) { int i, j; assert(A.row_dim == B.col_dim && A.col_dim == B.col_dim); for(i=0; i < A.row_dim; i++) for(j=0; j < A.col_dim; j++)
399
12812
by: =?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?= | last post by:
PEP 1 specifies that PEP authors need to collect feedback from the community. As the author of PEP 3131, I'd like to encourage comments to the PEP included below, either here (comp.lang.python), or to python-3000@python.org In summary, this PEP proposes to allow non-ASCII letters as identifiers in Python. If the PEP is accepted, the following identifiers would also become valid as class, function, or variable names: Löffelstiel,...
12
29874
by: puzzlecracker | last post by:
is it even possible or/and there is a better alternative to accept input in a nonblocking manner?
0
8604
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
9083
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
8961
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
8800
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
5819
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
4557
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
2974
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
2
2238
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
1957
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.