Hi All,
Here is a small Code,
int main(void)
{
char *p=(char *) malloc(100);
strcpy(p,"Test1 234567890");
p=p+10;
free(p);
/*** Is here a memory Leak, because p is now
pointing 10 location past to the start of allocated memory
****/
/** some stuff with p again**/
}
Thanks and Regards,
Raman Chalotra
Feb 1 '07
171  4944 
Yevgen Muntyan wrote:
I don't know what "underdog" means, so I can't tell. I can tell though
that I dislike this "mainstream " thing in this newsgroup, when people
get template responses and get *flamed* when try to defend themselves,
even if they are right.
I'm the last person to be part of any clique here.
And it does concern me. The last thing I remember is
int *ptr = malloc (10 * sizeof (int));
It's declared heretic here, and you shall not do it, you must
do
int *ptr = malloc (10 * sizeof *ptr);
Because it promotes bad habits! That's the entire point. If you change the
type of "ptr" then you must change the sizeof as well. If you do not happen
to remember changing the sizeof (because it's not on the same line, e.g.,
you're a C coder and not just throwing malloc into the declaration AND
definition because it's a: not a typical idiom, b: you won't know how much to
allocate until later, c: you value context of use rather than "well I know
I'll probably be using this later, so let's just allocate now") in the
malloc() statement. This has bitten every single person in this newsgroup
until they learned not to use that construct.
It's like you're at a motorcycle safety school trying to argue why wheelies
should be allowed on public motorways. Nobody is going to buy it there.
In situations like this I even feel some sympathy to Kenny McSomething.
He's at least an honest troll, not like many people here who insist
on "educating" everybody else and who will throw shit at you if you
refuse to be "educated".
I agree with Kenny on other points as well, but like I said: promotes bad
habits.
Christopher Layne wrote:
Yevgen Muntyan wrote:
>I don't know what "underdog" means, so I can't tell. I can tell though
that I dislike this "mainstream " thing in this newsgroup, when people
get template responses and get *flamed* when try to defend themselves,
even if they are right.
I'm the last person to be part of any clique here.
>And it does concern me. The last thing I remember is
int *ptr = malloc (10 * sizeof (int));
It's declared heretic here, and you shall not do it, you must
do
int *ptr = malloc (10 * sizeof *ptr);
Because it promotes bad habits! That's the entire point. If you change the
type of "ptr" then you must change the sizeof as well.
And if you change the name, you have to change it twice. And if you look
at
ptr = malloc (10 * sizeof *ptr);
then you don't know how much is allocated, while 10*sizeof(int) means
"ten ints". And if you use spaces instead of tabs, then you're wrong
because you must use tabs.
(Oh, and if suddenly *ptr is simply wrong there, then it's an advanced
code and we are not discussing advanced situations here, sure).
If you do not happen
to remember changing the sizeof (because it's not on the same line, e.g.,
you're a C coder and not just throwing malloc into the declaration AND
definition because it's
You better don't throw malloc in your code at all. If it's strings, you
don't need sizeof. If it's anything else, you better be careful. And if
it's structures, you better isolate allocation to some special functions
(where you simply don't care what form you use).
a: not a typical idiom, b: you won't know how much to
allocate until later, c: you value context of use rather than "well I know
I'll probably be using this later, so let's just allocate now") in the
malloc() statement. This has bitten every single person in this newsgroup
until they learned not to use that construct.
The last sentence is not true. And it's not just me who wasn't bitten
by that (I simply don't use raw malloc() much though).
It's like you're at a motorcycle safety school trying to argue why wheelies
should be allowed on public motorways. Nobody is going to buy it there.
No no, not on public anything. On my own yard, my own one-wheel
motorcycle is fine because of have additional safety measures.
>In situations like this I even feel some sympathy to Kenny McSomething.
He's at least an honest troll, not like many people here who insist
on "educating" everybody else and who will throw shit at you if you
refuse to be "educated".
I agree with Kenny on other points as well, but like I said: promotes bad
habits.
What promotes bad habits? Bad habits? Okay, let it be a bad habit to
cast return value of malloc (which I agree with if it's "always
cast"). Do you say that it's fine to claim that the cast in the
following code
#include <stdlib.h>
int main (void)
{
char *foo = (char*) malloc (18);
return 0;
}
*necessarily* and *always* leads to bad results for every single person
in every single situation? Please don't say about habits, just say "yes"
or "no" (and read the thread to see what I am talking about if you're
interested).
Yevgen
CBFalconer wrote:
Yevgen Muntyan wrote:
>Christopher Layne wrote:
... snip ...
>>This isn't C++ here.
Same thing again, huh? "here" means what? I can compile C code
with C++ compiler *here*, and I may want my *C* code to be
compilable with C++ compiler, now what? Come on, I am not going
to try to convince *you* that *you* want the cast. Just because
I don't think so. What I am trying to do is to convince you that
*I* may want to do that evil thing, and I am still fine doing
that evil thing. Because I use compiler flags lalala, lalala,
and so on.
Do what you wish, but don't recommend bad habits here. There are
innocent newbies around, who might become perverted. That is the
major reason for jumping on such posts.
"Innocent newbies"! Think about it next time when you post
not strictly conforming code here. You may hurt some
newbies who can believe that's "C language as defined
by the standard"!
Seriously speaking, if one cares about newbies and wants
to prevent them from learning something bad, he must
say so, he must not say "You're wrong period". Simply
because "You're wrong period" claim is wrong, and poor
newbies who trust everyone will learn wrong things.
Good one, by the way. "Major reason for jumping on such
posts", yeah.
Yevgen
On Thu, 08 Feb 2007 01:36:11 GMT, in comp.lang.c , Yevgen Muntyan
<mu************ ****@tamu.eduwr ote:
>
Me: I am fine here, I make gcc take care of this.
You: No, you're wrong. anycc is not obliged to emit a warning.
Me: *I* make *gcc* take care of this *here*.
You: No, you're wrong. See above.
You: its ok, I always put the safety on.
Me: its still dangerous, safetys don't always work.
You: *I* always make sure the safety is *on*. So there.
Me: I wouldn't do -
<sfx>*BANG* </>
You: urk.
Me: oh well, Darwin in action.
--
Mark McIntyre
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Yevgen Muntyan wrote, On 08/02/07 13:34:
Christopher Layne wrote:
>Yevgen Muntyan wrote:
>>I don't know what "underdog" means, so I can't tell. I can tell though
that I dislike this "mainstream " thing in this newsgroup, when people
get template responses and get *flamed* when try to defend themselves,
even if they are right.
I'm the last person to be part of any clique here.
>>And it does concern me. The last thing I remember is
int *ptr = malloc (10 * sizeof (int));
It's declared heretic here, and you shall not do it, you must
do
int *ptr = malloc (10 * sizeof *ptr);
Because it promotes bad habits! That's the entire point. If you change
the
type of "ptr" then you must change the sizeof as well.
And if you change the name, you have to change it twice. And if you look
at
ptr = malloc (10 * sizeof *ptr);
then you don't know how much is allocated, while 10*sizeof(int) means
"ten ints". And if you use spaces instead of tabs, then you're wrong
because you must use tabs.
(Oh, and if suddenly *ptr is simply wrong there, then it's an advanced
code and we are not discussing advanced situations here, sure).
This is more obviously a problem
newptr = malloc( 10 * sizeof *oldptr);
than
ptr = malloc( 10 * sizeof(int)
Also with most editors it is easier to do an interactive search and
replace on a variable name that a type name and get it right. Unless you
want to change all int variables to doubles!
>If you do not happen
to remember changing the sizeof (because it's not on the same line, e.g.,
you're a C coder and not just throwing malloc into the declaration AND
definition because it's
You better don't throw malloc in your code at all. If it's strings, you
don't need sizeof. If it's anything else, you better be careful. And if
it's structures, you better isolate allocation to some special functions
(where you simply don't care what form you use).
You should not throw anything in your code. You should always place it
there with care and knowing it is needed. You should also delete
anything that is not needed for the simple reason that it is normally
easier to introduce a bug by having something you don't need that by not
having something you do. Note I am not saying absence is never a bug,
but my experience is that deleting things which are not needed on
average decreases the bug count even if you occasionally delete
something that is needed by mistake.
>a: not a typical idiom, b: you won't know how much to
allocate until later, c: you value context of use rather than "well I
know
I'll probably be using this later, so let's just allocate now") in the
malloc() statement. This has bitten every single person in this newsgroup
until they learned not to use that construct.
The last sentence is not true. And it's not just me who wasn't bitten
by that (I simply don't use raw malloc() much though).
It hasn't bitten me but then I have *never* used a cast on the value
returned by malloc in real code.
>It's like you're at a motorcycle safety school trying to argue why
wheelies
should be allowed on public motorways. Nobody is going to buy it there.
No no, not on public anything. On my own yard, my own one-wheel
motorcycle is fine because of have additional safety measures.
If you get in to the habit of doing something potentially dangerous you
are more likely to do it at a time when it really matters than if you
are not in the habit.
>>In situations like this I even feel some sympathy to Kenny McSomething.
He's at least an honest troll, not like many people here who insist
on "educating" everybody else and who will throw shit at you if you
refuse to be "educated".
I agree with Kenny on other points as well, but like I said: promotes bad
habits.
What promotes bad habits? Bad habits? Okay, let it be a bad habit to
cast return value of malloc (which I agree with if it's "always
cast").
Casting is a bad habit. Casting the value returned by malloc is just a
special case with additional reasons why it can hide problems that
*have* caused programs to fail to run on *modern* hardware and OSs.
Do you say that it's fine to claim that the cast in the
following code
#include <stdlib.h>
int main (void)
{
char *foo = (char*) malloc (18);
return 0;
}
*necessarily* and *always* leads to bad results for every single person
in every single situation? Please don't say about habits, just say "yes"
or "no" (and read the thread to see what I am talking about if you're
interested).
It does not always lead to bad results any more than crossing the road
with your eyes closed always leads to bad results. However, the *habit*
of casting is always a bad habit and the habit of casting malloc is
always a bad habit.
I have seen exactly one person come up with a convincing reason why he
should cast the value returned by malloc in his specific situation. That
reason is at least in part due to commercial reality rather than
technical merit.
Note the compatibility with C++ is a bad reason because:
1) In C++ there are better methods than using malloc to get memory
2) C++ defines mechanisms to interface to C code that has been compiled
as C code.
--
Flash Gordon
On Feb 8, 7:26 am, Christopher Layne <cla...@com.ano dizedwrote:
Yevgen Muntyan wrote:
I don't know what "underdog" means, so I can't tell. I can tell though
that I dislike this "mainstream " thing in this newsgroup, when people
get template responses and get *flamed* when try to defend themselves,
even if they are right.
I'm the last person to be part of any clique here.
And it does concern me. The last thing I remember is
int *ptr = malloc (10 * sizeof (int));
It's declared heretic here, and you shall not do it, you must
do
int *ptr = malloc (10 * sizeof *ptr);
Because it promotes bad habits! That's the entire point. If you change the
type of "ptr" then you must change the sizeof as well. If you do not happen
to remember changing the sizeof (because it's not on the same line, e.g.,
you're a C coder and not just throwing malloc into the declaration AND
definition because it's a: not a typical idiom, b: you won't know how much to
allocate until later, c: you value context of use rather than "well I know
I'll probably be using this later, so let's just allocate now") in the
malloc() statement. This has bitten every single person in this newsgroup
until they learned not to use that construct.
I tend to disagree on this one. If you change the type of "ptr" you
*should* examine *all* the places where "ptr" was used anyhow (not
just the line with malloc). If you don't, that's promoting bad habits
and that may bite harder than the x*sizeof(<type> ). I personally
always use the latter and have never had any trouble with it.
It's like you're at a motorcycle safety school trying to argue why wheelies
should be allowed on public motorways. Nobody is going to buy it there.
Nonsense.
--
WYCIWYG
Christopher Layne wrote:
Yevgen Muntyan wrote:
>>cast malloc, b: declare your C code as just that if you're compiling it
within a C++ environment.
Please show an example.
>>Mandating -W as a way "handling" things is nothing but a goofy workaround.
I am not *mandating* anything! I am saying that *if* I use -W -Wall,
then casting return value of malloc() doesn't cause any troubles.
Do you not agree with this one exact sentence?
Yevgen
$ cat nonsense.c
[snip an irrelevant example of using g++ to compile C++ sources and
gcc to compile C sources]
But apparently some people still want to compile C code as C++. They're in C++
land and using malloc(), when they should probably be using new? Alright.
I wonder if it was "yes" or "no".
Anyway, there are cases when one wants to compile C code with C++
compiler. The most realistic example is macros in headers. Then inline
functions. Then sources which don't know about __cplusplus and extern
"C". Generated code doesn't count since it's way too advanced, right?
And if one likes to compile C code with C++ compiler to get stricter
type checking, that's a you-shall-not-do-that-just-because thing.
Anyway, C++ compiler is only one thing. You may get the cast
in C code just because it's there, e.g. in third party sources.
And you didn't fix it because you don't like to touch working code. Etc.
See, what you're saying is a reply to "Cast is always good and needed".
But nobody claimed that. And so on, and so forth.
Funny how people can talk about different things in form of dialog,
isn't it?
Perhaps I should have said that I don't think casting return value of
malloc is a good idea? Instead of not-saying which gets interpreted
as saying-the-contrary.
Yevgen
Mark McIntyre wrote:
On Thu, 08 Feb 2007 01:36:11 GMT, in comp.lang.c , Yevgen Muntyan
<mu************ ****@tamu.eduwr ote:
>Me: I am fine here, I make gcc take care of this.
You: No, you're wrong. anycc is not obliged to emit a warning.
Me: *I* make *gcc* take care of this *here*.
You: No, you're wrong. See above.
You: its ok, I always put the safety on.
Me: its still dangerous, safetys don't always work.
You: *I* always make sure the safety is *on*. So there.
Me: I wouldn't do -
<sfx>*BANG* </>
You: urk.
Me: oh well, Darwin in action.
Indeed, code tends to break when you don't touch it. You
put cast in, it explodes in two months.
What you're all saying is why it's not a good idea to
use cast. And that's indeed true, it's not a good idea
to cast when you don't have to. What's not true
is that any given piece of code with cast is wrong and
dangerous in any situation.
Yevgen
Flash Gordon wrote:
Yevgen Muntyan wrote, On 08/02/07 13:34:
>Christopher Layne wrote:
>>Yevgen Muntyan wrote:
I don't know what "underdog" means, so I can't tell. I can tell though
that I dislike this "mainstream " thing in this newsgroup, when people
get template responses and get *flamed* when try to defend themselves,
even if they are right.
I'm the last person to be part of any clique here.
And it does concern me. The last thing I remember is
int *ptr = malloc (10 * sizeof (int));
It's declared heretic here, and you shall not do it, you must
do
int *ptr = malloc (10 * sizeof *ptr);
Because it promotes bad habits! That's the entire point. If you
change the
type of "ptr" then you must change the sizeof as well.
And if you change the name, you have to change it twice. And if you look
at
ptr = malloc (10 * sizeof *ptr);
then you don't know how much is allocated, while 10*sizeof(int) means
"ten ints". And if you use spaces instead of tabs, then you're wrong
because you must use tabs.
(Oh, and if suddenly *ptr is simply wrong there, then it's an advanced
code and we are not discussing advanced situations here, sure).
This is more obviously a problem
newptr = malloc( 10 * sizeof *oldptr);
than
ptr = malloc( 10 * sizeof(int)
Also with most editors it is easier to do an interactive search and
replace on a variable name that a type name and get it right. Unless you
want to change all int variables to doubles!
If you use editor's search to modify code then you'll get errors,
just because this edit is that complex. And you'll get errors
unrelated to malloc() ;)
>
>>If you do not happen
to remember changing the sizeof (because it's not on the same line,
e.g.,
you're a C coder and not just throwing malloc into the declaration AND
definition because it's
You better don't throw malloc in your code at all. If it's strings, you
don't need sizeof. If it's anything else, you better be careful. And if
it's structures, you better isolate allocation to some special functions
(where you simply don't care what form you use).
You should not throw anything in your code. You should always place it
there with care and knowing it is needed. You should also delete
anything that is not needed for the simple reason that it is normally
easier to introduce a bug by having something you don't need that by not
having something you do. Note I am not saying absence is never a bug,
but my experience is that deleting things which are not needed on
average decreases the bug count even if you occasionally delete
something that is needed by mistake.
>>a: not a typical idiom, b: you won't know how much to
allocate until later, c: you value context of use rather than "well I
know
I'll probably be using this later, so let's just allocate now") in the
malloc() statement. This has bitten every single person in this
newsgroup
until they learned not to use that construct.
The last sentence is not true. And it's not just me who wasn't bitten
by that (I simply don't use raw malloc() much though).
It hasn't bitten me but then I have *never* used a cast on the value
returned by malloc in real code.
>>It's like you're at a motorcycle safety school trying to argue why
wheelies
should be allowed on public motorways. Nobody is going to buy it there.
No no, not on public anything. On my own yard, my own one-wheel
motorcycle is fine because of have additional safety measures.
If you get in to the habit of doing something potentially dangerous you
are more likely to do it at a time when it really matters than if you
are not in the habit.
>>>In situations like this I even feel some sympathy to Kenny McSomething.
He's at least an honest troll, not like many people here who insist
on "educating" everybody else and who will throw shit at you if you
refuse to be "educated".
I agree with Kenny on other points as well, but like I said: promotes
bad
habits.
What promotes bad habits? Bad habits? Okay, let it be a bad habit to
cast return value of malloc (which I agree with if it's "always
cast").
Casting is a bad habit. Casting the value returned by malloc is just a
special case with additional reasons why it can hide problems that
*have* caused programs to fail to run on *modern* hardware and OSs.
Do you say that it's fine to claim that the cast in the
following code
#include <stdlib.h>
int main (void)
{
char *foo = (char*) malloc (18);
return 0;
}
*necessarily * and *always* leads to bad results for every single person
in every single situation? Please don't say about habits, just say "yes"
or "no" (and read the thread to see what I am talking about if you're
interested).
It does not always lead to bad results any more than crossing the road
with your eyes closed always leads to bad results.
True statement, just as true as that jumping on the ground is no more
dangerous than jumping off a skyscraper. And so nicely makes it sound
as dangerous even though it doesn't explicitely say so.
However, the *habit*
of casting is always a bad habit and the habit of casting malloc is
always a bad habit.
Yes, such a *habit* is bad. Did I tell it's not?
I have seen exactly one person come up with a convincing reason why he
should cast the value returned by malloc in his specific situation. That
reason is at least in part due to commercial reality rather than
technical merit.
Note the compatibility with C++ is a bad reason because:
1) In C++ there are better methods than using malloc to get memory
You lose compatibility with C then ;)
2) C++ defines mechanisms to interface to C code that has been compiled
as C code.
And I am talking about compiling *C* code with *C++* compiler.
Yevgen
On Thu, 08 Feb 2007 12:56:40 -0600, in comp.lang.c , Yevgen Muntyan
<mu************ ****@tamu.eduwr ote:
>Mark McIntyre wrote:
>On Thu, 08 Feb 2007 01:36:11 GMT, in comp.lang.c , Yevgen Muntyan
<mu*********** *****@tamu.eduw rote:
>>Me: I am fine here, I make gcc take care of this.
You: No, you're wrong. anycc is not obliged to emit a warning.
Me: *I* make *gcc* take care of this *here*.
You: No, you're wrong. See above.
You: its ok, I always put the safety on.
Me: its still dangerous, safetys don't always work.
You: *I* always make sure the safety is *on*. So there.
Me: I wouldn't do -
<sfx>*BANG* </>
You: urk.
Me: oh well, Darwin in action.
Indeed, code tends to break when you don't touch it.
I assume you got the point, and are merely trying to avoid it. :-)
>You put cast in, it explodes in two months.
Sure, if during that 2 months, you upgraded your compiler, OS or
target infrastructure.
>What you're all saying is why it's not a good idea to
use cast. And that's indeed true, it's not a good idea
to cast when you don't have to.
And malloc is a case where you don't have to.
>What's not true
is that any given piece of code with cast is wrong and
dangerous in any situation.
Nobody ever said that.
--
Mark McIntyre
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: disco |
last post by:
I am working on this example from a book "C Primer Plus" by Prata 4th
edition - p. 672. There is no erata on this problem at the publisher's
website.
1) Is it a violation of copyright laws to post example code from a
book to a newsgroup?
2) The program crashes as it tries to free memory and I would like to
know the best way to correct THIS section of the code. By assigning
current = head, current now points to the first structure in...
|
by: f.oppedisano |
last post by:
Hi,
i would like to allocate two structures making only one malloc call.
So i do prt=malloc(sizeof(struct1)+sizeof(struct2));
After this operation i make two pointers one to the first struct (ptr1=ptr),
the other to second struct(ptr2=ptr+sizeof(struct2)).
These two pointer are later used by two threads in mutual exclusion so
thread1 can't access ptr2 and thread2 can't access ptr1.
At some time thread2 wants to free his part of memory but...
|
by: Rodrigo Dominguez |
last post by:
there are sometimes that I use third party libraries, I use some functions
that returns char * or structs, etc. sometimes the memory that is returned
by those libraries, when I try to free this memory whith the function free,
it brokes my application, and sometimes it's ok, why? how do I realize when
I have to free the memory that is allocated by third party libraries and
why sometimes I don't have to free this memory?
Thank you
|
by: Fernando Cacciola |
last post by:
Help me out here please:
While watching Brad Abraham's MSDN TV talk about the Dispose pattern,
refering to:
public virtual void Dispose ( bool disposing )
{
if ( disposing )
{
<-- WHAT GOES HERE -->
|
by: Atul Sureka |
last post by:
Hi,
I want to free the object memory in C# - like we do using 'delete' keyword
in C++.
Lets say I have an object of some class and I want to explicitly free the
memory.
C# do not have any free or delete keyword to do so.
Also I don't want to wait for the GC to be called.
| | |
by: karthikbalaguru |
last post by:
Hi,
Will 'free' return the memory Immediately to the OS ?
Thx in advans,
Karthik Balaguru
|
by: david |
last post by:
I will past only two segments from the code it should be enough to see
what I did wrong, I think I know there I made a mistake, but how to
fix it I can not tell. This why I need help from you all.
Main code:
----------------
/* duomenu rasymas i faila */
dst = fopen(argv, "w");
if (dst != NULL) {
wordDBSize = sizeStack(wordDB);
|
by: vivek |
last post by:
Hello,
I have a pointer to a main structure which again consists of
structures, enums, char, int, float and again complex structures.
When i free all the contents of the main structure, it takes me a lot
of time (since i have to loop determining the data type and freeing
it). Is there any idea to free all the contents of the structure in
shortest possible time.
|
by: Andreas Eibach |
last post by:
Hi again,
one of the other big woes I'm having...
typedef struct perBlockStru /* (structure) Long words per block
*/
{
unsigned long *lword;
} lwperBlockStru_t;
|
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,...
|
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...
| | |
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,...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
|
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...
|
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...
|
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
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| | |
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...
| |
