473,326 Members | 2,104 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,326 software developers and data experts.

is *ptr++ equivalent to *(ptr++)

Is *ptr++ equivalent to *(ptr++) ?

Nov 15 '05 #1
27 6599
Yes you are right.

Nov 15 '05 #2
ju**********@yahoo.co.in wrote:
Is *ptr++ equivalent to *(ptr++) ?


Yes. In each case, the associativity is right-to-left and, in each case, the
value seen by * is the old value of ptr, not the new value that it will
have when ++ has completed its work.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
mail: rjh at above domain
Nov 15 '05 #3


ju**********@yahoo.co.in wrote:
Is *ptr++ equivalent to *(ptr++) ?


yes it is correct....
one more

++*ptr == (*ptr)++

Nov 15 '05 #4
Richard Heathfield <in*****@address.co.uk.invalid> wrote:
ju**********@yahoo.co.in wrote:
Is *ptr++ equivalent to *(ptr++) ?
Yes. In each case, the associativity is right-to-left and, in each case, the


I don't think "associativity" is the right word here, as they are
unary operators. "Precedence" is more appropriate, I think.
value seen by * is the old value of ptr, not the new value that it will
have when ++ has completed its work.

There's a rule of thumb for unary operators in C, first you read ones
to the right, then ones to the left (unless, of cource, paretheses
override this).

A couple of (non-trivial) examples:
*p++
++p[i];
*p[i]
&a[i]
++p->m
(type*)p->m
*p()

(But I haven't really made sure that it always works; and `sizeof' is
special.)

--
Stan Tobias
mailx `echo si***@FamOuS.BedBuG.pAlS.INVALID | sed s/[[:upper:]]//g`
Nov 15 '05 #5
ra***********@gmail.com wrote:


ju**********@yahoo.co.in wrote:
Is *ptr++ equivalent to *(ptr++) ?


yes it is correct....
one more

++*ptr == (*ptr)++


I hardly think so.

--
Chris "electric hedgehog" Dollin
It's called *extreme* programming, not *stupid* programming.
Nov 15 '05 #6
Yes. See the details here:
http://msdn.microsoft.com/library/de....operators.asp
(google with "operator precedence" and "left to right" and "right to left"
for more lists)

Like you can see in the list, the post-increment operator will be executed
first, if there are no brackets.

The associativity for the indirection operator is right to left and for the
post-increment operator left to right. But for this example this is not of
any importance.

Eric
<ju**********@yahoo.co.in> wrote in message
news:11********************@g43g2000cwa.googlegrou ps.com...
Is *ptr++ equivalent to *(ptr++) ?

Nov 15 '05 #7


Chris Dollin wrote:
ra***********@gmail.com wrote:


ju**********@yahoo.co.in wrote:
Is *ptr++ equivalent to *(ptr++) ?


yes it is correct....
one more

++*ptr == (*ptr)++


I hardly think so.


The two constructs are equivalent in the following scenarios:

int *ptr = ...;
int i;

(void)++*ptr;
(void)(*ptr)++;

However, their behaviour is not the same when used like this:

i = (*ptr)++;
i = ++*ptr;

--
Vijay Kumar R. Zanvar
Home Page - http://geocities.com/vijoeyz/

Nov 15 '05 #8
Vijay Kumar R. Zanvar wrote:


Chris Dollin wrote:
ra***********@gmail.com wrote:
>
>
> ju**********@yahoo.co.in wrote:
>> Is *ptr++ equivalent to *(ptr++) ?
>
> yes it is correct....
> one more
>
> ++*ptr == (*ptr)++


I hardly think so.


The two constructs are equivalent in the following scenarios:

int *ptr = ...;
int i;

(void)++*ptr;
(void)(*ptr)++;

However, their behaviour is not the same when used like this:

i = (*ptr)++;
i = ++*ptr;


Hence, they are not equivalent; you can't just use one in place
of the other.

--
Chris "electric hedgehog" Dollin
It's called *extreme* programming, not *stupid* programming.
Nov 15 '05 #9


Chris Dollin wrote:
Vijay Kumar R. Zanvar wrote:


Chris Dollin wrote:
ra***********@gmail.com wrote:

>
>
> ju**********@yahoo.co.in wrote:
>> Is *ptr++ equivalent to *(ptr++) ?

[..]
Hence, they are not equivalent; you can't just use one in place
of the other.

Yes, you're quite correct. But for a learner, he/she must know the
difference. Practically, these two construct should not be
interchanged.
--
Chris "electric hedgehog" Dollin
It's called *extreme* programming, not *stupid* programming.


Nov 15 '05 #10
Vijay Kumar R. Zanvar wrote:
Chris Dollin wrote:
Vijay Kumar R. Zanvar wrote:
>
>
> Chris Dollin wrote:
>> ra***********@gmail.com wrote:
>>
>> >
>> >
>> > ju**********@yahoo.co.in wrote:
>> >> Is *ptr++ equivalent to *(ptr++) ?
[..]
Your snipping is excessive; you've eliminated the thing we were
talkign about and left in the thing we're /not/ talking about.

The two things we - or, at least, I - were talking about were

++*ptr and (*ptr)++
Hence, they are not equivalent; you can't just use one in place
of the other.


Yes, you're quite correct. But for a learner, he/she must know the
difference.


Learners should learn the difference; experts already know the
difference, to wit, that their results are different, by 1,
because one is pre-increment and the other is post-increment.
Practically, these two construct should not be interchanged.


Because they're not equivalent, yes. If one /doesn't care
about the result/, they are - but in that case, I'd write
them as

*ptr += 1;

which I think both better expresses the don't-care, and is
less likely to lead to queries or arguments about precedence
and associativity and order-of-evaluation.

--
Chris "electric hedgehog" Dollin
It's called *extreme* programming, not *stupid* programming.
Nov 15 '05 #11


S.Tobias wrote:
Richard Heathfield <in*****@address.co.uk.invalid> wrote:
ju**********@yahoo.co.in wrote:
Is *ptr++ equivalent to *(ptr++) ?


Yes. In each case, the associativity is right-to-left and, in each case, the


I don't think "associativity" is the right word here, as they are
unary operators. "Precedence" is more appropriate, I think.


But the precedence of *(indirection) and ++(post increment) operators
is same. So, I think associativity should be the right word.

Nov 15 '05 #12
ju**********@yahoo.co.in wrote:
S.Tobias wrote:
Richard Heathfield <in*****@address.co.uk.invalid> wrote:
> ju**********@yahoo.co.in wrote: >> Is *ptr++ equivalent to *(ptr++) ?
>
> Yes. In each case, the associativity is right-to-left and, in each case, the
I don't think "associativity" is the right word here, as they are
unary operators. "Precedence" is more appropriate, I think.

But the precedence of *(indirection) and ++(post increment) operators
is same.


No.

unary-expr:
postfix-expr
unary-operator cast-expr

unary-operator: one of
& * + - ~ !

cast-expr:
unary-expr
( type-name ) cast-expr
So, I think associativity should be the right word.


It makes no sense, associativity is a propoerty of binary operators.

--
Stan Tobias
mailx `echo si***@FamOuS.BedBuG.pAlS.INVALID | sed s/[[:upper:]]//g`
Nov 15 '05 #13
Hi

The operator precedence is NOT the same. And yes, the associativity is
different too.
Please have a look at my link I posted earlier.

Eric

<ju**********@yahoo.co.in> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...


S.Tobias wrote:
Richard Heathfield <in*****@address.co.uk.invalid> wrote:
> ju**********@yahoo.co.in wrote:
>
>> Is *ptr++ equivalent to *(ptr++) ?
>
> Yes. In each case, the associativity is right-to-left and, in each
> case, the


I don't think "associativity" is the right word here, as they are
unary operators. "Precedence" is more appropriate, I think.


But the precedence of *(indirection) and ++(post increment) operators
is same. So, I think associativity should be the right word.

Nov 15 '05 #14
S.Tobias wrote:
Richard Heathfield <in*****@address.co.uk.invalid> wrote:
ju**********@yahoo.co.in wrote:
Is *ptr++ equivalent to *(ptr++) ?


Yes. In each case, the associativity is right-to-left and, in each case,
the


I don't think "associativity" is the right word here, as they are
unary operators. "Precedence" is more appropriate, I think.


Not so. * and ++ have the same precedence, so the word is not useful in this
context.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
mail: rjh at above domain
Nov 15 '05 #15
S.Tobias wrote:
ju**********@yahoo.co.in wrote:
S.Tobias wrote:
Richard Heathfield <in*****@address.co.uk.invalid> wrote:
> ju**********@yahoo.co.in wrote:> Is *ptr++ equivalent to *(ptr++) ?
>
> Yes. In each case, the associativity is right-to-left and, in each
> case, the

I don't think "associativity" is the right word here, as they are
unary operators. "Precedence" is more appropriate, I think.
But the precedence of *(indirection) and ++(post increment) operators
is same.


No.


Wrong. They are the same.
unary-expr:
postfix-expr
unary-operator cast-expr

unary-operator: one of
& * + - ~ !

cast-expr:
unary-expr
( type-name ) cast-expr


That isn't particularly helpful. Of rather more explanatory power is the
table on p53 of K&R, which shows us that * and ++ have the same precedence
level, so the ordering within the statement becomes relevant - and that
ordering is right-to-left for that particular precedence level.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
mail: rjh at above domain
Nov 15 '05 #16
Richard Heathfield <in*****@address.co.uk.invalid> wrote:
S.Tobias wrote:
ju**********@yahoo.co.in wrote:
S.Tobias wrote:
Richard Heathfield <in*****@address.co.uk.invalid> wrote:
> ju**********@yahoo.co.in wrote:

>> Is *ptr++ equivalent to *(ptr++) ?
>
> Yes. In each case, the associativity is right-to-left and, in each
> case, the

I don't think "associativity" is the right word here, as they are
unary operators. "Precedence" is more appropriate, I think.

But the precedence of *(indirection) and ++(post increment) operators
is same.


No.


Wrong. They are the same.
unary-expr:
postfix-expr
unary-operator cast-expr

unary-operator: one of
& * + - ~ !

cast-expr:
unary-expr
( type-name ) cast-expr


That isn't particularly helpful. Of rather more explanatory power is the
table on p53 of K&R, which shows us that * and ++ have the same precedence
level, so the ordering within the statement becomes relevant - and that
ordering is right-to-left for that particular precedence level.


All right, I agree. There's nothing to argue about. I haven't
looked at that table for a long time.

I might not be a good pupil, but I have learned here in c.l.c that
C does not actually define precedence, but rather the precedence
is expressed in terms of syntax rules. What I tried to show is
that whenever a unary and a post-fix operators meet, the post-fix
one is evaluated first (which I guess is the same as what "right
associative" means in that table, though I'm still not convinced
that the choice of words was right).

--
Stan Tobias
mailx `echo si***@FamOuS.BedBuG.pAlS.INVALID | sed s/[[:upper:]]//g`
Nov 15 '05 #17
Richard Heathfield <in*****@address.co.uk.invalid> wrote:

That isn't particularly helpful. Of rather more explanatory power is the
table on p53 of K&R, which shows us that * and ++ have the same precedence
level, so the ordering within the statement becomes relevant - and that
ordering is right-to-left for that particular precedence level.


The precedences shown in that table are not the same as the precedences
implied by the grammar in the standard. It's of no practical
consequence since, as you might expect given the source, the table
produces the same result for all valid expressions, but it does have an
impact on academic discussions such as this one. According to the
standard, postfix ++ and -- do have higher precedence than unary *
(which has the same precedence as prefix ++ and --; K&R's table give the
prefix and postfix operators the same precedence and count on
associativity to get the correct results).

-Larry Jones

OK, what's the NEXT amendment say? I know it's in here someplace. -- Calvin
Nov 15 '05 #18
la************@ugs.com writes:
Richard Heathfield <in*****@address.co.uk.invalid> wrote:

That isn't particularly helpful. Of rather more explanatory power is the
table on p53 of K&R, which shows us that * and ++ have the same precedence
level, so the ordering within the statement becomes relevant - and that
ordering is right-to-left for that particular precedence level.


The precedences shown in that table are not the same as the precedences
implied by the grammar in the standard. It's of no practical
consequence since, as you might expect given the source, the table
produces the same result for all valid expressions, but it does have an
impact on academic discussions such as this one. According to the
standard, postfix ++ and -- do have higher precedence than unary *
(which has the same precedence as prefix ++ and --; K&R's table give the
prefix and postfix operators the same precedence and count on
associativity to get the correct results).


Furthermore, the table is wrong (at least if it's the same table as the
one I'm used to). The expression

sizeof (int) - 1

is parsed as

(sizeof (int)) - 1

not as

sizeof ((int) (- 1))

as the table implies.
Nov 15 '05 #19
Chris Dollin wrote:

ra***********@gmail.com wrote:


ju**********@yahoo.co.in wrote:
Is *ptr++ equivalent to *(ptr++) ?


yes it is correct....
one more

++*ptr == (*ptr)++


I hardly think so.


In contexts where the value of ptr isn't used,
they can be equivalent.
In short, they aren't equivalent.

But, the expression
++*ptr == (*ptr)++
is undefined.
*ptr is modified twice with no sequence point.

--
pete
Nov 15 '05 #20
On Wed, 20 Jul 2005 12:13:03 -0700, Tim Rentsch wrote:
la************@ugs.com writes:
Richard Heathfield <in*****@address.co.uk.invalid> wrote:
>
> That isn't particularly helpful. Of rather more explanatory power is the
> table on p53 of K&R, which shows us that * and ++ have the same precedence
> level, so the ordering within the statement becomes relevant - and that
> ordering is right-to-left for that particular precedence level.


The precedences shown in that table are not the same as the precedences
implied by the grammar in the standard. It's of no practical
consequence since, as you might expect given the source, the table
produces the same result for all valid expressions, but it does have an
impact on academic discussions such as this one. According to the
standard, postfix ++ and -- do have higher precedence than unary *
(which has the same precedence as prefix ++ and --; K&R's table give the
prefix and postfix operators the same precedence and count on
associativity to get the correct results).


Furthermore, the table is wrong (at least if it's the same table as the
one I'm used to). The expression

sizeof (int) - 1

is parsed as

(sizeof (int)) - 1

not as

sizeof ((int) (- 1))

as the table implies.


The problem here is not that the precedence table mispredicts the binding,
it is that it cannot predict it at all, the precedence rules allow both of
these. A precedence table assumes that you already know what operators are
being used or have a grammar without such ambiguities, and it will then
determine how operands are bound to those operators. In this case there is
an ambiguity over which operators the original exprrssion contains. In the
first parse there is a sizeof operator and a binary -, in the second parse
there is a sizeof, a cast and a unary -. This ambiguity cannot be solved
by pure precedence, there have to be other non-precedence based rules to
resolve this. E.g. a rule that states that sizeof followed by a type in
parentheses is parsed as a single sizeof(TYPE) operation rather than
sizeof (CAST). I don't have K&R2 with me here, but I though it did mention
sizeof in the accompanying text for the precedence table.

This demonstrates that the grammar form used to specify C's syntax is more
powerful than precedence rules since it can express this directly.

Lawrence

Nov 15 '05 #21
On Tue, 19 Jul 2005 23:10:41 +0000, Richard Heathfield wrote:
S.Tobias wrote:
Richard Heathfield <in*****@address.co.uk.invalid> wrote:
ju**********@yahoo.co.in wrote:

Is *ptr++ equivalent to *(ptr++) ?

Yes. In each case, the associativity is right-to-left and, in each case,
the


I don't think "associativity" is the right word here, as they are
unary operators. "Precedence" is more appropriate, I think.


Not so. * and ++ have the same precedence, so the word is not useful in this
context.


In the precedence tables given in K&R and K&R 2 that is true but other
equivalent precedence tables are possible. IIRC King uses a precedence
table where postfix operators have higher precedence than prefix operators.

As long as the table predicts that when an operand is between two unary
operators it is bound to the one on its right that's fine.

Lawrence

Nov 15 '05 #22
On Thu, 21 Jul 2005 12:54:09 +0100, Lawrence Kirby
<lk****@netactive.co.uk> wrote:
The problem here is not that the precedence table mispredicts the binding,
it is that it cannot predict it at all, the precedence rules allow both of
these. A precedence table assumes that you already know what operators are
being used or have a grammar without such ambiguities, and it will then
determine how operands are bound to those operators. In this case there is
an ambiguity over which operators the original exprrssion contains. In the
first parse there is a sizeof operator and a binary -, in the second parse
there is a sizeof, a cast and a unary -. This ambiguity cannot be solved
by pure precedence, there have to be other non-precedence based rules to
resolve this. E.g. a rule that states that sizeof followed by a type in
parentheses is parsed as a single sizeof(TYPE) operation rather than
sizeof (CAST). I don't have K&R2 with me here, but I though it did mention
sizeof in the accompanying text for the precedence table.
Thanks for that explanation. In my precedence-based parser I simply
remembered whether the previous token was an identifier or an operator,
if it was an identifier I treated it like a function call (with
sizeof(...) being handled as a "compile-time function") which got the
precedence right. However, the ternary operator can't be done that
simply using a precedence-based parser.
This demonstrates that the grammar form used to specify C's syntax is more
powerful than precedence rules since it can express this directly.


Indeed. With a precedence-only grammar you can't distinguish between
unary and binary operators which use the same token without remembering
the context. (Of course you can't with BNF either, the 'state' or
context is in remembering which rule you're processing, but it's easier
to describe in BNF.)

Chris C
Nov 15 '05 #23
Lawrence Kirby <lk****@netactive.co.uk> writes:
On Wed, 20 Jul 2005 12:13:03 -0700, Tim Rentsch wrote:
la************@ugs.com writes:
Richard Heathfield <in*****@address.co.uk.invalid> wrote:
>
> That isn't particularly helpful. Of rather more explanatory power is the
> table on p53 of K&R, which shows us that * and ++ have the same precedence
> level, so the ordering within the statement becomes relevant - and that
> ordering is right-to-left for that particular precedence level.

The precedences shown in that table are not the same as the precedences
implied by the grammar in the standard. It's of no practical
consequence since, as you might expect given the source, the table
produces the same result for all valid expressions, but it does have an
impact on academic discussions such as this one. According to the
standard, postfix ++ and -- do have higher precedence than unary *
(which has the same precedence as prefix ++ and --; K&R's table give the
prefix and postfix operators the same precedence and count on
associativity to get the correct results).
Furthermore, the table is wrong (at least if it's the same table as the
one I'm used to). The expression

sizeof (int) - 1

is parsed as

(sizeof (int)) - 1

not as

sizeof ((int) (- 1))

as the table implies.


The problem here is not that the precedence table mispredicts the binding,
it is that it cannot predict it at all, the precedence rules allow both of
these. A precedence table assumes that you already know what operators are
being used or have a grammar without such ambiguities, and it will then
determine how operands are bound to those operators. In this case there is
an ambiguity over which operators the original exprrssion contains. In the
first parse there is a sizeof operator and a binary -, in the second parse
there is a sizeof, a cast and a unary -. This ambiguity cannot be solved
by pure precedence, there have to be other non-precedence based rules to
resolve this. E.g. a rule that states that sizeof followed by a type in
parentheses is parsed as a single sizeof(TYPE) operation rather than
sizeof (CAST).

This demonstrates that the grammar form used to specify C's syntax is more
powerful than precedence rules since it can express this directly.


The table isn't supposed to be a table of operator precedences for an
operator precedence grammar. If it were, there are already problems
without casts, because + and - appear in two different places as
different operators.

If we take the table to be what it pretty clearly was meant to be,
which is a compact summary intended for human consumption, then adding
a level below sizeof/++ that has just casts in it (or, adding a level
for sizeof(type) just above), does a reasonable job of specifying
precedences for its intended audience.

It isn't that the comments about operator precedence are wrong; only
that they seem to be applying a technical standard in what is pretty
clearly a non-technical arena.

None of which changes my basic point, which is that the table can't be
relied on for defining "precedence" in a technically accurate way.
I don't have K&R2 with me here, but I though it did mention
sizeof in the accompanying text for the precedence table.


I didn't say the book is wrong. I said the table is wrong.
Nov 15 '05 #24
On Tue, 19 Jul 2005 23:19:15 +0000 (UTC), Richard Heathfield
<in*****@address.co.uk.invalid> wrote:

<snip>
But the precedence of *(indirection) and ++(post increment) operators
is same.
<snip grammar excerpts> That isn't particularly helpful. Of rather more explanatory power is the
table on p53 of K&R, which shows us that * and ++ have the same precedence
level, so the ordering within the statement becomes relevant - and that
ordering is right-to-left for that particular precedence level.

I concur with the other posters; what we informally call precedence is
a shorthand for the decisions made by the grammar rules, and by those
rules postfix are higher than prefix with a variation for sizeof.

Associativity is also implied by the grammar rules and is actually
defined in mathematics only for binary operators/ions, but the
situation for postfix versus prefix can be seen as similar in that the
operand 'prefers' the righthand=postfix operator over the
lefthand=prefix one.

But that still doesn't give a 'right-to-left' rule. That would say
given: double (*funcs[10]) (double) = {sin, cos, etc.}
then: funcs[i](3.0) would call the function [i] with the value 3.0,
and use its return to subscript funcs. That makes no sense.

The most you can say is: (unless overridden by grouping parentheses)
apply (or bind to) all/any postfix operators first, then all/any
prefix operators. That sure sounds like higher precedence to me.
- David.Thompson1 at worldnet.att.net
Nov 15 '05 #25

Rajan wrote:
Yes you are right.

When executed with ANSI C and gcc,* wins over ++.Then what exactly
happens?
another anamoly:
int i = 1;
c = i++ + i++;
is c = 6 or 2?
-Siliconwafer

Nov 15 '05 #26

siliconwafer wrote:
Rajan wrote:
Yes you are right.

When executed with ANSI C and gcc,* wins over ++.Then what exactly
happens?
another anamoly:
int i = 1;
c = i++ + i++;
is c = 6 or 2?


Are you *really*, *really*, asking this? Better, take a break,
and maybe goto:
http://www.eskimo.com/~scs/C-faq/q3.2.html

Nov 15 '05 #27
siliconwafer wrote:
Rajan wrote:
Yes you are right.

When executed with ANSI C and gcc,* wins over ++.Then what exactly
happens?
another anamoly:
int i = 1;
c = i++ + i++;
is c = 6 or 2?


No.

See the FAQ.

--
Chris "electric hedgehog" Dollin
predicting self-predictors' predictions is predictably unpredictable.
Nov 15 '05 #28

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

Similar topics

9
by: G Fernandes | last post by:
Hello fellow C-goers, Comparisons of pointer variables to 0 are automatically converted to comparisons to NULL (which can be represented at the bit level but something non-zero). But how...
19
by: Jason | last post by:
Hello, could someone explain the difference to me inbetween: *ptr++ and ++*ptr Thankx a lot.. Jason.
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 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 former...

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.