473,839 Members | 1,514 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Boost process and C

Hi,

Is there any group in the manner of the C++ Boost group that works on
the evolution of the C language? Or is there any group that performs an
equivalent function?

Thanks,
-vs

Apr 29 '06
335 11909
Ben C wrote:
On 2006-05-03, we******@gmail. com <we******@gmail .com> wrote:
CBFalconer wrote:
we******@gmail. com wrote:
> CBFalconer wrote:
... snip ...
>> The last time I took an (admittedly cursory) look at Bstrlib, I
>> found it cursed with non-portabilities
>
> You perhaps would like to name one?

I took another 2 minute look, and was immediately struck by the use
of int for sizes, rather than size_t. This limits reliably
available string length to 32767.
[snip]
[...] I did find an explanation and
justification for this. Conceded, such a size is probably adequate
for most usage, but the restriction is not present in standard C
strings.
Your going to need to conceed on more grounds than that. There is a
reason many UNIX systems tried to add a ssize_t type, and why TR 24731
has added rsize_t to their extension. (As a side note, I strongly
suspect the Microsoft, in fact, added this whole rsize_t thing to TR
24731 when they realized that Bstrlib, or things like it, actually has
far better real world safety because its use of ints for string
lengths.) Using a long would be incorrect since there are some systems
where a long value can exceed a size_t value (and thus lead to falsely
sized mallocs.) There is also the matter of trying to codify
read-only and constant strings and detecting errors efficiently
(negative lengths fit the bill.) Using ints is the best choice
because at worst its giving up things (super-long strings) that nobody
cares about,
I think it's fair to expect the possibility of super-long strings in a
general-purpose string library.


Ok, so you can name a single application of such a thing right?
it allows in an efficient way for all desirable encoding scenarios,
and it avoids any wrap around anomolies causing under-allocations.


What anomalies? Are these a consequence of using signed long, or
size_t?


I am describing what int does (*BOTH* the encoding scenarios and
avoiding anomolies), Using a long int would allow for arithmetic on
numbers that exceed the maximum value of size_t on some systems (that
actually *exist*), so when there was an attempt to malloc or realloc on
such sizes, there would be a wrap around to some value that would just
make it screw up. And if I used a size_t, then there would be no
simple space of encodings that can catch errors, constants and write
protected strings.
If I tried to use size_t I would give up a significant amount of
safety and design features (or else I would have to put more entries
into the header, making it less efficient).


If you only need a single "special" marker value (for which you were
perhaps using -1), you could consider using ~(size_t) 0.


For the mlen, I need one value that indicates a write protected string
(that can be unprotected) and one the indicates a constant (that can
never be unprotected). The slen has to be of the same type as mlen,
and so in order to check for potential errors, I set it to -1 to
indicate that it has been deterministical ly set to an invalid value.
Of course I could just isolate a handful of values, however, but this
makes the error space extremely small, which reduces your chances of
finding accidental full corruptions, and removes a useful debugging
mechanism (where you could pass around useful information through
negative values.)
Things will go wrong for at most one possible string length, but that's
more than can be said for using int.
Huh? You *WANT* more erroneous scenarios. You want the mechanism to
require a somewhat tighter form of correctness, with it otherwise
leading to the thing stopping or other feeding back detectable errors.
If you have only a small error trap, random behaviour will not fall
into it.
But whatever the difference in efficiency, surely correctness and safety
first, efficiency second has to be the rule for a general-purpose
library?


It *IS* correct and safe. (And its fast, and easy to use/understand
and powerful and portable and secure ...) What are you talking about?
I'll take it you have never tried to use or understand Bstrlib either.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

May 4 '06 #201
On Tue, 02 May 2006 23:20:47 +0200, regis <re***@dil.un iv-mrs.fr> wrote:
without operator overloading, how about just an infix notation
for 2-ary functions (with, e.g., functions evaluated left to right,
all with the same priority) ?

typedef struct Vect { double x, y; } Vect;

infix Vect Vect_Sub (Vect u, Vect v) {
return (Vect) { .x= u.x - v.x, .y= u.y - v.y };
}
infix Vect Vect_Scale (double lambda, Vect u) {
return (Vect) { .x= lambda*u.x, .y= lambda*u.y };
}
infix double Vect_Dot (Vect u, Vect v) {
return u.x * v.x + u.y * v.y;
}
int main (void) {
Vect u, v, w, p, q, r, s, t;
...
t= ((v Vect_Sub u) Vect_Dot (w Vect_Sub v))
Vect_Scale (p Vect_Sub q Vect_Sub r Vect_Sub s);
...
}


No, please. This looks strangely familiar if you know LISP :P

Plus, it doesn't really work for functions with an arbitrary number of
arguments, and this creates an inconsistency in the elegantly simple
syntax of C.

May 4 '06 #202
On 2006-05-03, REH <me@you.com> wrote:

"Ben C" <sp******@spam. eggs> wrote in message
news:sl******** *************@b owser.marioworl d...
On 2006-05-03, REH <sp******@stny. rr.com> wrote:

Ben C wrote:
In C, builtin types are passed around by value and space for them
doesn't need to be allocated or freed.

Um, the same is true for C++.
Yes of course, I never intended to imply that it wasn't.

The point I was making was that operator overloading doesn't mix so
easily with things that might need to be allocated and freed manually--
i.e. objects of user-defined types. You start needing constructors and
destructors, which C++ (but not C) has.


Why? And why do you think objects of user-defined types have to be
"allocated and freed manually"?


They don't _have_ to be, but they _might_ be.

One of the "features" of C is that the programmer has control over
memory allocation and de-allocation.

Usually in practice this just means a lot of bugs and crashes; but there
are good reasons for it too: you can write domain-specific allocators
that are more efficient and/or tunable in the amount of space or time
they use, instead of relying on a general-purpose allocator or
garbage-collector all the time.

The programmer also might implement things like shallow-copy and
copy-on-write.

Somehow all of these things need to happen when an expression like this
is evaluated:

string a = b + c;

In C++ the basic mechanism you use for this is constructors. For example
the string copy constructor might set up a shallow copy-on-write copy.
Someone has to write the code for that. If the programmer writes it, and
it's not just part of the framework, then it has to get implicitly
called.
struct foo {
int x, y;
};

foo operator+ (const foo& a, const foo& b)
// for it you are of the "I hate references" camp: foo operator+ (foo a,
foo b)
{
const foo z = {a.x + b.x, a.y + b.y};
return z;
}

foo x = {1, 2};
foo y = {3, 4};
foo z = x + y;

simplistic, but no constructors.


Yes exactly, and AFAIK the kind of operator-overloading that has been
proposed for C is something like this-- it's fine for structs
representing things like complex numbers (that are a few words long and
don't contain pointers).

But this is quite limited. You can use it for complex numbers, numbers
longer than the largest machine type, and as has been suggested perhaps
to wrap assembler intrinsics for multimedia instructions.

But you can't easily use it efficiently as it stands for matrices or
strings (which are two other common uses for operator overloading).

On its own it's not enough; with the extra workarounds you need, you end
up with C++ (or some other kind of "octopus made by nailing four extra
legs onto a dog").
May 4 '06 #203
On 2006-05-04, we******@gmail. com <we******@gmail .com> wrote:
Ben C wrote:
On 2006-05-03, we******@gmail. com <we******@gmail .com> wrote:
> CBFalconer wrote:
>> we******@gmail. com wrote:
>> > CBFalconer wrote:
>> ... snip ...
>> >> The last time I took an (admittedly cursory) look at Bstrlib, I
>> >> found it cursed with non-portabilities
>> >
>> > You perhaps would like to name one?
>>
>> I took another 2 minute look, and was immediately struck by the use
>> of int for sizes, rather than size_t. This limits reliably
>> available string length to 32767.
[snip]
I think it's fair to expect the possibility of super-long strings in a
general-purpose string library.
Ok, so you can name a single application of such a thing right?


No, but I don't assume that everything I can't name an example of
doesn't exist.
> it allows in an efficient way for all desirable encoding scenarios,
> and it avoids any wrap around anomolies causing under-allocations.


What anomalies? Are these a consequence of using signed long, or
size_t?


I am describing what int does (*BOTH* the encoding scenarios and
avoiding anomolies), Using a long int would allow for arithmetic on
numbers that exceed the maximum value of size_t on some systems (that
actually *exist*), so when there was an attempt to malloc or realloc on
such sizes, there would be a wrap around to some value that would just
make it screw up. And if I used a size_t, then there would be no
simple space of encodings that can catch errors, constants and write
protected strings.


OK, I think I understand that part now.
> If I tried to use size_t I would give up a significant amount of
> safety and design features (or else I would have to put more entries
> into the header, making it less efficient).


If you only need a single "special" marker value (for which you were
perhaps using -1), you could consider using ~(size_t) 0.


For the mlen, I need one value that indicates a write protected string
(that can be unprotected) and one the indicates a constant (that can
never be unprotected). The slen has to be of the same type as mlen,
and so in order to check for potential errors, I set it to -1 to
indicate that it has been deterministical ly set to an invalid value.
Of course I could just isolate a handful of values, however, but this
makes the error space extremely small, which reduces your chances of
finding accidental full corruptions, and removes a useful debugging
mechanism (where you could pass around useful information through
negative values.)
Things will go wrong for at most one possible string length, but that's
more than can be said for using int.


Huh? You *WANT* more erroneous scenarios.[..]


Sorry, I was unclear; I meant "that's better than you can say of the
situation if you use int".
But whatever the difference in efficiency, surely correctness and safety
first, efficiency second has to be the rule for a general-purpose
library?


It *IS* correct and safe. (And its fast, and easy to use/understand
and powerful and portable and secure ...)


I have nothing against Bstrlib.
What are you talking about?
What if int is bigger than size_t?
I'll take it you have never tried to use or understand Bstrlib either.


No I'd never heard of it.
May 4 '06 #204
we******@gmail. com wrote:
Ben C wrote:
On 2006-05-03, we******@gmail. com <we******@gmail .com> wrote:
CBFalconer wrote:
we******@gmail. com wrote:
> CBFalconer wrote:
... snip ...
>> The last time I took an (admittedly cursory) look at Bstrlib, I
>> found it cursed with non-portabilities
> You perhaps would like to name one?
I took another 2 minute look, and was immediately struck by the use
of int for sizes, rather than size_t. This limits reliably
available string length to 32767.

[snip]
[...] I did find an explanation and
justification for this. Conceded, such a size is probably adequate
for most usage, but the restriction is not present in standard C
strings.
Your going to need to conceed on more grounds than that. There is a
reason many UNIX systems tried to add a ssize_t type, and why TR 24731
has added rsize_t to their extension. (As a side note, I strongly
suspect the Microsoft, in fact, added this whole rsize_t thing to TR
24731 when they realized that Bstrlib, or things like it, actually has
far better real world safety because its use of ints for string
lengths.) Using a long would be incorrect since there are some systems
where a long value can exceed a size_t value (and thus lead to falsely
sized mallocs.) There is also the matter of trying to codify
read-only and constant strings and detecting errors efficiently
(negative lengths fit the bill.) Using ints is the best choice
because at worst its giving up things (super-long strings) that nobody
cares about,

I think it's fair to expect the possibility of super-long strings in a
general-purpose string library.


Ok, so you can name a single application of such a thing right?


Handling an RTF document that you will be writing to a variable length
record in a database. Yes, I do have good reason for doing this. No, I
can't stream the document in to the database so I do have to have it all
in memory. Yes, RTF documents are encoded as text. Yes, they can be
extremely large, especially if they have graphics embedded in them
encoded as text.
it allows in an efficient way for all desirable encoding scenarios,
and it avoids any wrap around anomolies causing under-allocations.

What anomalies? Are these a consequence of using signed long, or
size_t?


I am describing what int does (*BOTH* the encoding scenarios and
avoiding anomolies), Using a long int would allow for arithmetic on
numbers that exceed the maximum value of size_t on some systems (that
actually *exist*), so when there was an attempt to malloc or realloc on
such sizes, there would be a wrap around to some value that would just
make it screw up. And if I used a size_t, then there would be no
simple space of encodings that can catch errors, constants and write
protected strings.


Is an extra byte (or word, or double word) for a flags field really that
big an overhead?

<snip>
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php
May 4 '06 #205
Giorgos Keramidas wrote:
On Tue, 02 May 2006 23:20:47 +0200, regis <re***@dil.un iv-mrs.fr> wrote:
without operator overloading, how about just an infix notation
for 2-ary functions (with, e.g., functions evaluated left to right,
all with the same priority) ?

typedef struct Vect { double x, y; } Vect;

infix Vect Vect_Sub (Vect u, Vect v) {
return (Vect) { .x= u.x - v.x, .y= u.y - v.y };
}
infix Vect Vect_Scale (double lambda, Vect u) {
return (Vect) { .x= lambda*u.x, .y= lambda*u.y };
}
infix double Vect_Dot (Vect u, Vect v) {
return u.x * v.x + u.y * v.y;
}
int main (void) {
Vect u, v, w, p, q, r, s, t;
...
t= ((v Vect_Sub u) Vect_Dot (w Vect_Sub v))
Vect_Scale (p Vect_Sub q Vect_Sub r Vect_Sub s);
...
}


No, please. This looks strangely familiar if you know LISP :P

Plus, it doesn't really work for functions with an arbitrary number of
arguments, and this creates an inconsistency in the elegantly simple
syntax of C.


I know no infix scheme for functions in Lisp.
In Lisp, This would look like:

(Vect_Scale
(Vect_Dot
(Vect_Sub v u)
(Vect_Sub w v)
)
(Vect_Sub_va p q r s)
)

which is much like it looks in C without infix notation:

Vect_Scale (
Vect_Dot (
Vect_Sub (u,v),
Vect_Sub (w,v)
),
Vect_Sub_va (p, q, r, s, ARGS_END)
);

May 4 '06 #206
Ben C a écrit :

Yes exactly, and AFAIK the kind of operator-overloading that has been
proposed for C is something like this-- it's fine for structs
representing things like complex numbers (that are a few words long and
don't contain pointers).

But this is quite limited. You can use it for complex numbers, numbers
longer than the largest machine type, and as has been suggested perhaps
to wrap assembler intrinsics for multimedia instructions.

But you can't easily use it efficiently as it stands for matrices or
strings (which are two other common uses for operator overloading).

Why not?

Suppose Matrix A,B,C;

C = A+B;

Your operator + function would allocate the space, add the matrix to a
possible linked lists of matrices that allows to GC unused ones, and
return the results.

Or, instead of taking all this trouble you could just use the GC and
forget about destructors. All intermediate results would be
automatically garbage collected.
On its own it's not enough; with the extra workarounds you need, you end
up with C++ (or some other kind of "octopus made by nailing four extra
legs onto a dog").


The crucial point in this is to know when to stop. There are NO
constructors/destructors in C, and none of the proposed extensions
proposes that.

Besides, I think that using the addition operator to "add" strings is an
ABOMINATION because:

a+b != b+a
"Hello" + "World" != "World" + "Hello"

It just makes NO SENSE. The same thing when you apply the addition
operator to dates: it makes NO SENSE to ADD dates. Only subtraction
makes sense. And yes, multiplying dates is left "as an exercise" for the
fools!

If you feel that operator overloading would not solve the problem for
matrices addition, then you will have to devise other means of doing that.

The GC however, is an ELEGANT solution to all this problems. We would
have the easy of use of C++ with its automatic destructors, WITHOUT
PAYING THE PRICE in language and compiler complexity.

This last point is important: compiler complexity increases the effort
that the language implementor must do and increases the "bug surface".

The module that handles the operator overloading in lcc-win32 is 1732
lines long, including all commentaries and lines that contain just a '{'
or a '}'.

The compiled operators module is 11K machine code. All the extensions of
lcc-win32 are conceptually simple, even if operator overloading is the
most complex one. The others like generic functions are much simpler to
implement.

jacob
May 4 '06 #207
Flash Gordon a écrit :

Is an extra byte (or word, or double word) for a flags field really that
big an overhead?


Well, I have that extra "Flags" field in the string library of
lcc-win32. I have the size as a size_t as you propose, and I need 32
bits for the flags.

The problem is that 32 bits is quite a lot for a few bits info... For
programs that use extensively strings, 32 bits multiplied by several
thousand small strings can make a big difference in RAM used, specially
for the more common short strings.

I see the point of Bstrlib, and it is a very valid design decision.
May 4 '06 #208
jacob navia wrote:
Flash Gordon a écrit :

Is an extra byte (or word, or double word) for a flags field really
that big an overhead?


Well, I have that extra "Flags" field in the string library of
lcc-win32. I have the size as a size_t as you propose, and I need 32
bits for the flags.

The problem is that 32 bits is quite a lot for a few bits info... For
programs that use extensively strings, 32 bits multiplied by several
thousand small strings can make a big difference in RAM used, specially
for the more common short strings.

I see the point of Bstrlib, and it is a very valid design decision.


I've yet to see software where short strings made up a significant
portion of the memory footprint and saving the memory that avoiding the
flags would be of real use. Of course, such applications might exist.

Personally I would say that using negative lengths was asking for
problems because at some point a negative length will be checked without
first changing it to positive.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc
May 4 '06 #209
On 2006-05-04, we******@gmail. com <we******@gmail .com> wrote:
Ben C wrote:
On 2006-05-03, we******@gmail. com <we******@gmail .com> wrote:
> CBFalconer wrote:
>> we******@gmail. com wrote:
>> > CBFalconer wrote:
>> ... snip ...
>> >> The last time I took an (admittedly cursory) look at Bstrlib, I
>> >> found it cursed with non-portabilities
>> >
>> > You perhaps would like to name one?
>>
>> I took another 2 minute look, and was immediately struck by the use
>> of int for sizes, rather than size_t. This limits reliably
>> available string length to 32767.


[snip]
>> [...] I did find an explanation and
>> justification for this. Conceded, such a size is probably adequate
>> for most usage, but the restriction is not present in standard C
>> strings.

> Your going to need to conceed on more grounds than that. There is a
> reason many UNIX systems tried to add a ssize_t type, and why TR 24731
> has added rsize_t to their extension. (As a side note, I strongly
> suspect the Microsoft, in fact, added this whole rsize_t thing to TR
> 24731 when they realized that Bstrlib, or things like it, actually has
> far better real world safety because its use of ints for string
> lengths.) Using a long would be incorrect since there are some systems
> where a long value can exceed a size_t value (and thus lead to falsely
> sized mallocs.) There is also the matter of trying to codify
> read-only and constant strings and detecting errors efficiently
> (negative lengths fit the bill.) Using ints is the best choice
> because at worst its giving up things (super-long strings) that nobody
> cares about,


I think it's fair to expect the possibility of super-long strings in a
general-purpose string library.


Ok, so you can name a single application of such a thing right?
> it allows in an efficient way for all desirable encoding scenarios,
> and it avoids any wrap around anomolies causing under-allocations.


What anomalies? Are these a consequence of using signed long, or
size_t?


I am describing what int does (*BOTH* the encoding scenarios and
avoiding anomolies), Using a long int would allow for arithmetic on
numbers that exceed the maximum value of size_t on some systems (that
actually *exist*), so when there was an attempt to malloc or realloc on
such sizes, there would be a wrap around to some value that would just
make it screw up. And if I used a size_t, then there would be no
simple space of encodings that can catch errors, constants and write
protected strings.


If it's longer than the maximum size_t value, you probably can't have it
anyway, so there's no point in being able to represent it.

Silly encoding tricks buy you nothing, just use another field with bit
flags.
> If I tried to use size_t I would give up a significant amount of
> safety and design features (or else I would have to put more entries
> into the header, making it less efficient).


If you only need a single "special" marker value (for which you were
perhaps using -1), you could consider using ~(size_t) 0.


For the mlen, I need one value that indicates a write protected string
(that can be unprotected) and one the indicates a constant (that can
never be unprotected). The slen has to be of the same type as mlen,
and so in order to check for potential errors, I set it to -1 to
indicate that it has been deterministical ly set to an invalid value.
Of course I could just isolate a handful of values, however, but this
makes the error space extremely small, which reduces your chances of
finding accidental full corruptions,


This shouldn't be left to chance anyway, pretending that it can be
caught invites disaster when inevitably one of the cases comes up when
it _doesn't_ get caught.
May 4 '06 #210

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

Similar topics

65
5406
by: perseus | last post by:
I think that everyone who told me that my question is irrelevant, in particular Mr. David White, is being absolutely ridiculous. Obviously, most of you up here behave like the owners of the C++ language. A C++ interface installation IS ABOUT THE C++ LANGUAGE! The language does not possess the ability to handle even simple file directory manipulation. Those wise people that created it did not take care of it. So, BOOST is a portable...
205
10760
by: Jeremy Siek | last post by:
CALL FOR PAPERS/PARTICIPATION C++, Boost, and the Future of C++ Libraries Workshop at OOPSLA October 24-28, 2004 Vancouver, British Columbia, Canada http://tinyurl.com/4n5pf Submissions
17
1902
by: Howard Gardner | last post by:
/* If I am using boost, then how should I write this program? As it sits, this program is using SFINAE to determine whether or not a type supports particular syntax. I suspect that there is functionality in boost to do this. I have found mpl::has_xxx, which I suspect of being part of the solution. I've also found type_traits::has_nothrow_constructor
2
6636
by: smith4894 | last post by:
{ not sure you're aware of that but there are the newsgroups for all major operating systems. you might want to try asking in the forum 'comp.os.linux.development.apps', since memory-mapped files are not a language-supported structure, they are platform-specific. -mod } I'm trying to use boost serialization to serialize/deserialize data to and from a mmap'd file. I have my own ostream/istream classes that essentially read/write bytes...
5
2400
by: linyanhung | last post by:
I used a boost multi thread in VS 2005 on a Duo Core PC, and made a two thread process. The code is something like this: #include <boost/thread/thread.hpp> void fun1() { //do something
8
6214
by: Matt England | last post by:
My team currently using Boost Threads, but we are considering switching to ZThreads. (We seek cross-platform, C++ multithreading capabilities in an external library.) ZThread(s): http://zthread.sourceforge.net/ http://www.inf.uni-konstanz.de/dbis/members/vinnik/zsim/doc/ Can anyone share their ZThreads experience, either good, bad, or
2
2417
by: ironpingwin | last post by:
Hi! I'd like to make few threads which will run in the same time in C++. I try to use boost library v 1.34.1 (it can't be newest, because I compile on remote machine, which is not administrated by me). In this version there isn't detach() function. How to run functions from two different class in the same time?
13
4541
by: brad | last post by:
Still learning C++. I'm writing some regex using boost. It works great. Only thing is... this code seems slow to me compared to equivelent Perl and Python. I'm sure I'm doing something incorrect. Any tips? #include <boost/regex.hpp> #include <iostream> // g++ numbers.cpp -o numbers -I/usr/local/include/boost-1_35 /usr/local/lib/libboost_regex-gcc41-mt-s.a // g++ numbers.cpp -o numbers.exe
5
3596
by: ameyav | last post by:
Hi All, I am converting some C code into C++ code. The objective is to improve throughput. I have some code written in C which serially parses through a list of files, opens each one of them, processes the data and closes the file. All the files are processed one by one. The obvious performance bottleneck that i could think of is the wasted cpu cycles for file i/o. *My solution* was to spawn multiple threads to do the file i/o. For...
0
9697
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 effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
10585
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
10647
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,...
1
7828
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 presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
5682
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
0
5866
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
4482
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
4064
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
3132
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.