473,407 Members | 2,314 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,407 software developers and data experts.

iterator error

windows xp, visual studio 2005
----------------------------------------------------------------------------------------------------------------------------------
#include <iostream>
#include <map>
using namespace std;

int main()
{
map<int, int>::iterator it = 0;
if( it != 0 ) //break point,
this is an run time error?
cout<<"ok!";
}
----------------------------------------------------------------------------------------------------------------------------------
why it can be assign "0", but can't compare with "0"?

Apr 6 '07 #1
22 1545
ÀÖÀÖ´óÌìʦ wrote:
windows xp, visual studio 2005
----------------------------------------------------------------------------------------------------------------------------------
#include <iostream>
#include <map>
using namespace std;

int main()
{
map<int, int>::iterator it = 0;
if( it != 0 ) //break point,
this is an run time error?
cout<<"ok!";
}
----------------------------------------------------------------------------------------------------------------------------------
why it can be assign "0", but can't compare with "0"?
The iterator type in 'map' is implementation-defined. What
it means to initialise it with (int)0 is implementation-defined.
Why operator != (int)0 doesn't work is (you guessed it!)
implementation-defined. You need to either look at the code
in the debugger to see what's going on or ask in the newsgroup
dedicated to your implementation (microsoft.public.vc.* family
of newsgroups come to mind).

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Apr 6 '07 #2
ÀÖÀÖ´óÌìʦ wrote:
windows xp, visual studio 2005
----------------------------------------------------------------------------------------------------------------------------------
#include <iostream>
#include <map>
using namespace std;

int main()
{
map<int, int>::iterator it = 0;
if( it != 0 ) //break point,
this is an run time error?
cout<<"ok!";
}
----------------------------------------------------------------------------------------------------------------------------------
why it can be assign "0", but can't compare with "0"?
That all depends on what the type of a std::map<int, int>::iterator is
and whether it cam be initialised by or compared to an int. If it lacks
a public constructor, the assignment is illegal and if it lacks an
operator==(int), the comparison is illegal.

--
Ian Collins.
Apr 6 '07 #3
Ian Collins wrote:
ÀÖÀÖ´óÌìʦ wrote:
>windows xp, visual studio 2005
----------------------------------------------------------------------------------------------------------------------------------
#include <iostream>
#include <map>
using namespace std;

int main()
{
map<int, int>::iterator it = 0;
if( it != 0 ) //break point,
this is an run time error?
cout<<"ok!";
}
----------------------------------------------------------------------------------------------------------------------------------
why it can be assign "0", but can't compare with "0"?
That all depends on what the type of a std::map<int, int>::iterator is
and whether it cam be initialised by or compared to an int. If it
lacks a public constructor, the assignment is illegal and if it lacks
an operator==(int), the comparison is illegal.
It's actually operator!=(int) we're discussing here... Unless you think
they are related somehow...

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Apr 6 '07 #4
Victor Bazarov wrote:
Ian Collins wrote:
>>
That all depends on what the type of a std::map<int, int>::iterator is
and whether it cam be initialised by or compared to an int. If it
lacks a public constructor, the assignment is illegal and if it lacks
an operator==(int), the comparison is illegal.


It's actually operator!=(int) we're discussing here... Unless you think
they are related somehow...
Typo.

--
Ian Collins.
Apr 6 '07 #5
"ÀÖÀÖ´óÌìʦ" <ch*********@gmail.comwrote in message
news:11*********************@b75g2000hsg.googlegro ups.com...
windows xp, visual studio 2005
----------------------------------------------------------------------------------------------------------------------------------
#include <iostream>
#include <map>
using namespace std;

int main()
{
map<int, int>::iterator it = 0;
if( it != 0 ) //break point,
this is an run time error?
cout<<"ok!";
}
----------------------------------------------------------------------------------------------------------------------------------
why it can be assign "0", but can't compare with "0"?
Read the other's comments. You are trying to compare an iterator and an
integer. On some (most?) implementations it = 0 would probably be invalid
also. The correct usage is to initialize them with .begin() or .rbegin() or
some iterator value. For example:

int main()
{
std::map<int, intMyMap;
std::map<int, int>::iterator it = MyMap.begin();
// code
}

persontally, I normally use iterators mostly in for loops to iterate through
a container (vector or map) or to get a pointer to a newly inserted member.
Such as:

typedef std::map<int, intIntMap;
IntMap MyMap;
// fill MyMap
for ( IntMap::iterator it = MyMap.begin(); it != MyMap.end(); ++it )
std::cout << it->first << "-" << it->second << "\n";
Apr 6 '07 #6
ÀÖÀÖ´óÌìʦ wrote:
windows xp, visual studio 2005
----------------------------------------------------------------------------------------------------------------------------------
#include <iostream>
#include <map>
using namespace std;

int main()
{
map<int, int>::iterator it = 0;
if( it != 0 ) //break point,
this is an run time error?
cout<<"ok!";
}
----------------------------------------------------------------------------------------------------------------------------------
why it can be assign "0", but can't compare with "0"?
Repeat after me. Iterators are NOT POINTERS. Again. Iterators are NOT
POINTERS.

There is no such thing as a "0" or NULL iterator. Any valid iterator
must refer to a container.

Apr 6 '07 #7
On Apr 6, 3:02 am, "Victor Bazarov" <v.Abaza...@comAcast.netwrote:
ÀÖÀÖ´óÌìʦ wrote:
windows xp, visual studio 2005
----------------------------------------------------------------------------------------------------------------------------------
#include <iostream>
#include <map>
using namespace std;
int main()
{
map<int, int>::iterator it = 0;
if( it != 0 ) //break point,
this is an run time error?
cout<<"ok!";
}
----------------------------------------------------------------------------------------------------------------------------------
why it can be assign "0", but can't compare with "0"?
The iterator type in 'map' is implementation-defined. What
it means to initialise it with (int)0 is implementation-defined.
Why operator != (int)0 doesn't work is (you guessed it!)
implementation-defined.
It's not even implementation-defined, it's undefined.

Most good implementations will not compile either of the above
lines.
You need to either look at the code
in the debugger to see what's going on or ask in the newsgroup
dedicated to your implementation (microsoft.public.vc.* family
of newsgroups come to mind).
Actually, he needs to change his code. It might help if he
explained what he is trying to accomplish.

--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Apr 6 '07 #8
James Kanze wrote:
On Apr 6, 3:02 am, "Victor Bazarov" <v.Abaza...@comAcast.netwrote:
>ÀÖÀÖ´óÌìʦ wrote:
>>windows xp, visual studio 2005
----------------------------------------------------------------------------------------------------------------------------------
#include <iostream>
#include <map>
using namespace std;
int main()
{
map<int, int>::iterator it = 0;
if( it != 0 ) //break point,
this is an run time error?
cout<<"ok!";
}
----------------------------------------------------------------------------------------------------------------------------------
why it can be assign "0", but can't compare with "0"?
>The iterator type in 'map' is implementation-defined. What
it means to initialise it with (int)0 is implementation-defined.
Why operator != (int)0 doesn't work is (you guessed it!)
implementation-defined.

It's not even implementation-defined, it's undefined.
Strictly speaking without an implementation it wouldn't even exist and
therefore would not compile
>
Most good implementations will not compile either of the above
lines.
>You need to either look at the code
in the debugger to see what's going on or ask in the newsgroup
dedicated to your implementation (microsoft.public.vc.* family
of newsgroups come to mind).

Actually, he needs to change his code. It might help if he
explained what he is trying to accomplish.

--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
I agree the code is somewhat dodgy and probably not portable

JB
Apr 6 '07 #9
red floyd wrote:
ÀÖÀÖ´óÌìʦ wrote:
>windows xp, visual studio 2005
----------------------------------------------------------------------------------------------------------------------------------
#include <iostream>
#include <map>
using namespace std;

int main()
{
map<int, int>::iterator it = 0;
if( it != 0 ) //break point,
this is an run time error?
cout<<"ok!";
}
----------------------------------------------------------------------------------------------------------------------------------
why it can be assign "0", but can't compare with "0"?
Repeat after me. Iterators are NOT POINTERS. Again. Iterators are NOT
POINTERS.

There is no such thing as a "0" or NULL iterator. Any valid iterator
must refer to a container.
So what does the default constructor for an iterator refer to? Just
curious as a valid container may not yet exist

JB
Apr 6 '07 #10
James Kanze wrote:
On Apr 6, 3:02 am, "Victor Bazarov" <v.Abaza...@comAcast.netwrote:
>ÀÖÀÖ´óÌìʦ wrote:
>>windows xp, visual studio 2005
----------------------------------------------------------------------------------------------------------------------------------
#include <iostream>
#include <map>
using namespace std;
>>int main()
{
map<int, int>::iterator it = 0;
if( it != 0 ) //break point,
this is an run time error?
cout<<"ok!";
}
----------------------------------------------------------------------------------------------------------------------------------
why it can be assign "0", but can't compare with "0"?
>The iterator type in 'map' is implementation-defined. What
it means to initialise it with (int)0 is implementation-defined.
Why operator != (int)0 doesn't work is (you guessed it!)
implementation-defined.

It's not even implementation-defined, it's undefined.
Is it explicitly undefined (as in dereferencing a null pointer)?
All I can see in the standard is that 'iterator' type in 'std::map'
is implementation-defined. Is it not conceivable that the type
might actually define comparison with 0?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Apr 6 '07 #11
bnonaj wrote:
James Kanze wrote:
>On Apr 6, 3:02 am, "Victor Bazarov" <v.Abaza...@comAcast.netwrote:
>>ÀÖÀÖ´óÌìʦ wrote:
windows xp, visual studio 2005
----------------------------------------------------------------------------------------------------------------------------------

#include <iostream>
#include <map>
using namespace std;
int main()
{
map<int, int>::iterator it = 0;
if( it != 0 ) //break point,
this is an run time error?
cout<<"ok!";
}
----------------------------------------------------------------------------------------------------------------------------------

why it can be assign "0", but can't compare with "0"?
>>The iterator type in 'map' is implementation-defined. What
it means to initialise it with (int)0 is implementation-defined.
Why operator != (int)0 doesn't work is (you guessed it!)
implementation-defined.

It's not even implementation-defined, it's undefined.
Strictly speaking without an implementation it wouldn't even exist and
therefore would not compile
Well, perhaps. But the issue underlying this subthread is the
application of the technical terms "undefined" and "implementation
defined" as defined by the C++ standard. "Undefined behavior" means that
the standard does not impose any requirements. "Implementation defined"
means that the standard requires the implementation to document its
behavior.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)
Apr 6 '07 #12
Victor Bazarov wrote:
Is it explicitly undefined (as in dereferencing a null pointer)?
All I can see in the standard is that 'iterator' type in 'std::map'
is implementation-defined. Is it not conceivable that the type
might actually define comparison with 0?
If something is IMPLEMENTATION DEFINED the implementation
is required to document what it is. If it is UNDEFINED
it is not required. Therefore, if behavior is UNDEFINED
in any allowable instance, it's UNDEFINED in general.
Apr 6 '07 #13
red floyd wrote:
>
Any valid iterator
must refer to a container.
Any valid iterator must refer to a sequence. Containers are one way of
producing sequences, but not the only way.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)
Apr 6 '07 #14
bnonaj wrote:
So what does the default constructor for an iterator refer to?
The default constructor creates a singular iterator. The only
legitimate thing you can do with one is to assign a non-singular
iterator to it.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)
Apr 6 '07 #15
Ron Natalie wrote:
Victor Bazarov wrote:
>Is it explicitly undefined (as in dereferencing a null pointer)?
All I can see in the standard is that 'iterator' type in 'std::map'
is implementation-defined. Is it not conceivable that the type
might actually define comparison with 0?
If something is IMPLEMENTATION DEFINED the implementation
is required to document what it is. If it is UNDEFINED
it is not required. Therefore, if behavior is UNDEFINED
in any allowable instance, it's UNDEFINED in general.
You don't have to shout to get your point across, by the way.

And, what exactly *is* your point?
Apr 6 '07 #16
Pete Becker wrote:
red floyd wrote:
>Any valid iterator
must refer to a container.

Any valid iterator must refer to a sequence. Containers are one way of
producing sequences, but not the only way.
The standard defines it as something that peforms interations
over a container, stream, or streambuffer.

I suspect you are forgetting that the term SEQUENCE already has a
defined meaning in C++ as the subset of containers that include
vector, list, queue, dequeue, and stack.

In practice, an iterator is just a type that obeys the iterator
rules. It's quite possible to have a valid iterator that iterates
over just about anything including associative containers, plain
old arrays, and bizarre user defined types (we have our own
database iterators that are quite legal C++ iterators in their
own right).
Apr 6 '07 #17
Victor Bazarov wrote:
Ron Natalie wrote:
>Victor Bazarov wrote:
>>Is it explicitly undefined (as in dereferencing a null pointer)?
All I can see in the standard is that 'iterator' type in 'std::map'
is implementation-defined. Is it not conceivable that the type
might actually define comparison with 0?
If something is IMPLEMENTATION DEFINED the implementation
is required to document what it is. If it is UNDEFINED
it is not required. Therefore, if behavior is UNDEFINED
in any allowable instance, it's UNDEFINED in general.

You don't have to shout to get your point across, by the way.
Wasn't shouting. Just trying to highlight the defined terms.
Netnews typopgraphy leaves a little to be desired.
And, what exactly *is* your point?
My point is answering your point. You seem to be saying
that it's not undefined behavior to compare something with
zero because of the possiblity that some implementation
may have defined behavior for that which in undefined.
Well that's fine for that implementation, but if isn't
defined by the standard or required to be implementation
defined, then in general it's still undefined behavior.

Apr 6 '07 #18
Ron Natalie wrote:
[..] You seem to be saying
that it's not undefined behavior to compare something with
zero because of the possiblity that some implementation
may have defined behavior for that which in undefined.
Yes. Exactly. The type for the 'std::map::iterator' is
implementation-defined. That means the implementation has to
document that type (and all its traits along with it). The
ability for an object of that type to be compared to 0 _is_
going to be described in the same *required* documentation.
Well that's fine for that implementation, but if isn't
defined by the standard or required to be implementation
defined, then in general it's still undefined behavior.
No, I think it's implementation-defined by *extension* of
the requirement that the type itself is implementation-defined.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Apr 6 '07 #19
Ron Natalie wrote:
Pete Becker wrote:
>red floyd wrote:
>>Any valid iterator
must refer to a container.
Any valid iterator must refer to a sequence. Containers are one way of
producing sequences, but not the only way.
The standard defines it as something that peforms interations
over a container, stream, or streambuffer.
I couldn't find that definition. In fact, iterators are defined
operationally,
by the operations that they support.
I suspect you are forgetting that the term SEQUENCE already has a
defined meaning in C++ as the subset of containers that include
vector, list, queue, dequeue, and stack.
That's an unfortunate term, which should be "sequence container",
just as we have "associative container" and "unordered container." And
it's clear from the way I used it that I wasn't referring to a sequence
container, but to a sequence in its more ordinary sense.
>
In practice, an iterator is just a type that obeys the iterator
rules. It's quite possible to have a valid iterator that iterates
over just about anything including associative containers, plain
old arrays, and bizarre user defined types (we have our own
database iterators that are quite legal C++ iterators in their
own right).
Exactly.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)
Apr 6 '07 #20
Pete Becker wrote:
Ron Natalie wrote:
>Pete Becker wrote:
>>red floyd wrote:
Any valid iterator
must refer to a container.

Any valid iterator must refer to a sequence. Containers are one way of
producing sequences, but not the only way.
The standard defines it as something that peforms interations
over a container, stream, or streambuffer.

I couldn't find that definition. In fact, iterators are defined
operationally,
by the operations that they support.
>I suspect you are forgetting that the term SEQUENCE already has a
defined meaning in C++ as the subset of containers that include
vector, list, queue, dequeue, and stack.

That's an unfortunate term, which should be "sequence container",
just as we have "associative container" and "unordered container." And
it's clear from the way I used it that I wasn't referring to a sequence
container, but to a sequence in its more ordinary sense.
>In practice, an iterator is just a type that obeys the iterator
rules. It's quite possible to have a valid iterator that iterates
over just about anything including associative containers, plain
old arrays, and bizarre user defined types (we have our own
database iterators that are quite legal C++ iterators in their
own right).

Exactly.
I should add, too, that many of the algorithms in the standard are
described as operating on sequences, but aren't restricted to sequence
containers.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)
Apr 6 '07 #21
On Apr 6, 2:43 pm, Ron Natalie <r...@spamcop.netwrote:
Victor Bazarov wrote:
Is it explicitly undefined (as in dereferencing a null pointer)?
All I can see in the standard is that 'iterator' type in 'std::map'
is implementation-defined. Is it not conceivable that the type
might actually define comparison with 0?
If something is IMPLEMENTATION DEFINED the implementation
is required to document what it is. If it is UNDEFINED
it is not required. Therefore, if behavior is UNDEFINED
in any allowable instance, it's UNDEFINED in general.
It can also be unspecified.

In this case, the standard pretty much says that anything you do
with the standard library that is not conform with the specified
requirements is undefined behavior.

--
--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Apr 6 '07 #22
On Apr 6, 1:59 pm, "Victor Bazarov" <v.Abaza...@comAcast.netwrote:
James Kanze wrote:
On Apr 6, 3:02 am, "Victor Bazarov" <v.Abaza...@comAcast.netwrote:
ÀÖÀÖ´óÌìʦ wrote:
windows xp, visual studio 2005
----------------------------------------------------------------------------------------------------------------------------------
#include <iostream>
#include <map>
using namespace std;
>int main()
{
map<int, int>::iterator it = 0;
if( it != 0 ) //break point,
this is an run time error?
cout<<"ok!";
}
----------------------------------------------------------------------------------------------------------------------------------
why it can be assign "0", but can't compare with "0"?
The iterator type in 'map' is implementation-defined. What
it means to initialise it with (int)0 is implementation-defined.
Why operator != (int)0 doesn't work is (you guessed it!)
implementation-defined.
It's not even implementation-defined, it's undefined.
Is it explicitly undefined (as in dereferencing a null pointer)?
Yes. The standard says that just about anything you do with the
library that isn't conform results in undefined behavior. There
are practically no requirements that e.g. a diagnostic be
emitted.

In practice, there's a lot of undefined behavior that will
either work, or result in a diagnostic, even if the standard
says it's undefined. The line `cout<<"ok!";' in the above
program, for example, is undefined behavior, since the code
fails to include the necessary header (<ostream>). But I can't
conceive of an implementation in which it either worked, or
failed to compile.
All I can see in the standard is that 'iterator' type in 'std::map'
is implementation-defined.
The type is implementation defined; most typically, it will be a
nested class or a typedef. The operations which it must support
are defined, however. And any attempt to do anything else with
it is undefined behavior.
Is it not conceivable that the type
might actually define comparison with 0?
The implementation might define it. That's one legal way of
handling undefined behavior. In the case of `cout<<"ok!"', for
example, both the g++ and the Dinkumware library define it; g++,
at least, has explicitly added code in <iostreamto make it
defined. And on my system, dereferencing a null pointer is
defined---the system guarantees an immediate core dump. But the
standard still says it is undefined, and I've used systems where
it could do some very strange things.

--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Apr 6 '07 #23

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

Similar topics

38
by: Grant Edwards | last post by:
In an interview at http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=273 Alan Kay said something I really liked, and I think it applies equally well to Python as well as the languages...
3
by: John Smith | last post by:
Hey I have some code which I've been using on Microsoft VC++ for some time. Now I wanted to port my application to Mac OS X which offers gcc and the build fails. Here is the troublesome code:...
3
by: Ken Cecka | last post by:
This is a contrived example to demonstrate a syntax problem I'm struggling with: #include <vector> template <typename T> class Class { };
1
by: flopbucket | last post by:
Hi, For the learning experience, I am building a replacement for std::map. I built a templated red-black tree, etc., and all the basic stuff is working well. I implemented basic iterators and...
3
by: wolverine | last post by:
Hi I am accessing a map from inside threads. There is a chance that an element is inserted into the map, from inside any thread. Since i don't know about thread safety of stl implementation i am...
5
by: Bill Oliver | last post by:
Help! I am writing an image processing package. For one constructor, I allow creating an image from a map of points and color values. The points are of a "position" class and the colors are...
1
by: atomik.fungus | last post by:
Hi, I'm re-writting my matrix class to practice my programming and the computer doesn't let me compile the next code: ( this example come from the constructor of the class) //the matrix is made...
6
by: antani | last post by:
VolumeType::ISetType::iterator findFirstIteratorMarked(const VolumeType::ISetType::iterator & it,const VolumeType::ISetType::iterator & e_it) { VolumeType::ISetType::iterator _it=it; while...
3
by: pnayak | last post by:
Hi, I am trying to implement an iterator to a List class. The code is included below. I get the following compiler error. At the point where I use a class that is defined inside a template...
5
by: maverik | last post by:
Hi all. I'm implementing class AbstractCollection - just a wrap on std::vector - to hide from clients the fact of using std::vector in the base (because in the future I may change vector to a...
0
by: emmanuelkatto | last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud. Please let me know. Thanks! Emmanuel
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
1
by: nemocccc | last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
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,...
0
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
0
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,...
0
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...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new...

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.