Apologies for the length - this post is best viewed with fixed font
and a line width >= 72.
Below is the source code for a C header file that provides a suite
of storage management macros. I am asking for comments on it. In
particular: Are there any gotchas that I have overlooked? Are
there any suggestions for improvements? Is there a generally
available superior packages to do the same thing with the same
general licensing? Comments on the documentation and suggestions
for improving it are welcome.
And, of course, anyone is welcome to use this little package as
they see fit.
/* ----------------------------------------------------------------- */
/* Copyright (c) 2006 by Richard Harter */
/* */
/* Permission is hereby granted, free of charge, to any person */
/* obtaining a copy of this software and associated documentation */
/* files (the "Software") , to deal in the Software without */
/* restriction, including without limitation the rights to use, */
/* copy, modify, merge, publish, distribute, sublicense, and/or */
/* sell copies of the Software, and to permit persons to whom the */
/* Software is furnished to do so, subject to the following */
/* conditions: */
/* */
/* The above copyright notice and this permission notice shall be */
/* included in all copies or substantial portions of the */
/* Software. */
/* */
/* Derived works shall include a notice that the software is a */
/* modified version of the copyrighted software. */
/* */
/* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY */
/* KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE */
/* WARRANTIES OF MERCHANTABILITY , FITNESS FOR A PARTICULAR */
/* PURPOSE AND NONINFRINGEMENT . IN NO EVENT SHALL THE AUTHORS OR */
/* COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER */
/* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR */
/* OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE */
/* SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. */
/* */
/* ----------------------------------------------------------------- */
/* */
/* This include file provides a suite of macros that simplify the */
/* management of allocatable storage. There are two groups of */
/* macros, the segmented space macros, and dynamic array macros. */
/* The segmented space macros create a sequence of segments, where */
/* the segments are all of the same type but are variable in size. */
/* The dynamic array macros create an extensible array of elements */
/* all the same size. Typically the segspace macros are used for */
/* creating blocks of storage of primitive types, e.g., ints or */
/* chars; there is no provision for indexing through the blocks. */
/* Dynamic arrays, on the other hand, are typically used for tables. */
/* */
/* All of the storage is allocated off the heap. Control data is */
/* global to the file containing the include file. All references */
/* to storage should be of the form of base+offset (e.g. array */
/* indexing) rather than pointers because the base address can */
/* can as the base is resized. Resizing is always upwards, i.e. the */
/* storage elements never decrease in size. Each separate storage */
/* unit can be invidually freed. */
/* */
/* Usage: */
/* */
/* Storage units (segmented spaces or dynamic arrays) should be */
/* declared at the file level using the STF_DCL_SEGSPAC E and */
/* STG_DCL_DYNARRA Y macros. Both macros take a type and a base */
/* name as arguments; in addition the STG_DCL_DYNARRA Y macro has the */
/* the address of a variable that will contain the array length. */
/* The "name" argument is the address of the variable that contains */
/* the pointer to base of the storage space. */
/* */
/* There are two macros for increasing segspace storage, one to add */
/* a segment and one to trim the length of the last segment. The */
/* STG_ADD_SEGSPAC E macro takes three arguments, the base name, the */
/* segment length (tentative), and the address of the offset. The */
/* trim macro reduces the length of the last segment. */
/* */
/* There are also two macros for increasing the size of dynamic */
/* arrays, one to increment the array size, and one to increase its */
/* size by an arbitrary amount. The STG_INCR_DYNARR AY macro has a */
/* single argument, the base pointer. The STG_REQSZ_DYNAR RAY macro */
/* two arguments, the base pointer, and the new size. */
/* */
/* Caveats: */
/* */
/* There is no error checking. Users are expected to use the macros */
/* intelligently. The calls are not followed by error checks on the */
/* returned value. All macro calls must be followed by a semicolon. */
/* */
/* ----------------------------------------------------------------- */
#ifndef utl_stgmacros_i nclude
#define utl_stgmacros_i nclude
#define STG_DCL_SEGSPAC E(name,type) \
static type * name = 0; \
static size_t name##_size = sizeof(type); \
static size_t name##_alloc = 0; \
static size_t name##_used = 0
#define STG_ADD_SEGSPAC E(name,offset,l ength) \
do { \
offset = name##_used; \
name##_used += length; \
if (name##_used name##_alloc) { \
name##_alloc = 2*name##_alloc + length; \
name = realloc(name, name##_alloc*na me##_size); \
} \
} while (0)
#define STG_TRIM_SEGSPA CE(name,length) \
name##_used -= length
#define STG_FREE_SEGSPA CE(name); \
do { \
free(name); \
name = 0; \
name##_alloc = 0; \
name##_used = 0; \
} while (0)
#define STG_DCL_DYNARRA Y(name, type, length) \
static type * name = 0; \
static int length = 0; \
static size_t name##_size = sizeof(type); \
static size_t name##_alloc = 0; \
static int * name##_lenptr = &length
#define STG_INCR_DYNARR AY(name) \
do { \
(*name##_lenptr )++; \
if (*name##_lenptr name##_alloc ) { \
if (name##_alloc < 8) name##_alloc = 8; \
else name##_alloc *= 2; \
name = realloc(name,na me##_alloc * name##_size); \
} \
} while (0)
#define STG_REQSZ_DYNAR RAY(name,length ) \
do { \
if (length name##_alloc) { \
name = realloc(name,le ngth * name##_size); \
name##_alloc = length; \
} \
} while (0)
#define STG_FREE_DYNARR AY(name) \
do { \
free(name); \
name = 0; \
*name##_lenptr = 0; \
name##_alloc = 0; \
} while (0)
#endif
14  2130 
Richard Harter wrote On 11/08/06 13:58,:
Apologies for the length - this post is best viewed with fixed font
and a line width >= 72.
Below is the source code for a C header file that provides a suite
of storage management macros. I am asking for comments on it.
Please forgive me for not repeating your copyright
notice. I promise not to reproduce any "substantia l portions"
of the code, and I promise not to offer any suggestions that
might be considered "derived works."
*/
/* Caveats: */
/* */
/* There is no error checking. Users are expected to use the macros */
/* intelligently. The calls are not followed by error checks on the */
/* returned value.
Indeed, there is no error checking. For example, realloc()
failure leaks memory unconditionally and irretrievably, to the
detriment of the program using the macros. To my mind, that
means there is exactly one way to use them intelligently: don't.
Without error-checking, the package is useless except in
toy programs where leaks and crashes don't really matter -- so
I'm not going to waste time studying your work in detail. A
few things stood out, though:
- Why this fascination with macros? Why not use functions?
It's the excessive macroization that's making error recovery
awkward (not impossible), whereas doing such things in
function contexts is relatively routine.
- Why use multiple independent variables to describe the
blobs of storage? This is what structs are for.
- Why force `static' on all the identifiers? Might not a
user occasionally want external linkage, or maybe even
an `auto' version?
If you decide to do something about handling errors, I'll
take a longer look. But until and unless ...
-- Er*********@sun .com
On Wed, 08 Nov 2006 14:25:50 -0500, Eric Sosman <Er*********@su n.com>
wrote:
>
Richard Harter wrote On 11/08/06 13:58,:
>Apologies for the length - this post is best viewed with fixed font
and a line width >= 72.
Below is the source code for a C header file that provides a suite
of storage management macros. I am asking for comments on it.
Please forgive me for not repeating your copyright
notice. I promise not to reproduce any "substantia l portions"
of the code, and I promise not to offer any suggestions that
might be considered "derived works."
Your thoughtfullness is greatly appreciated; you are hereby forgiven.
Of course that should have been "derivative works", but I fancy that the
change would not relieve your anxieties.
>
*/
>/* Caveats: */
/* */
/* There is no error checking. Users are expected to use the macros */
/* intelligently. The calls are not followed by error checks on the */
/* returned value.
Indeed, there is no error checking. For example, realloc()
failure leaks memory unconditionally and irretrievably, to the
detriment of the program using the macros. To my mind, that
means there is exactly one way to use them intelligently: don't.
As a practical matter if realloc fails the using program will crash
almost immediately afterwards on dereferencing a null pointer.
Including error checking is desirable of course, but what should it do?
There is no universal error checking policy. My thought here was to let
whoever used the package put in their own error checking. It would be
good to put in a comment like
/* Put in your own error check on realloc failure here */
>
Without error-checking, the package is useless except in
toy programs where leaks and crashes don't really matter -- so
I'm not going to waste time studying your work in detail. A
few things stood out, though:
- Why this fascination with macros? Why not use functions?
It's the excessive macroization that's making error recovery
awkward (not impossible), whereas doing such things in
function contexts is relatively routine.
It's an alternative, but there are some issues. The functions had
better be local to the file (static); if not, you need something like
handles to avoid conflicts. You still need to create the same of suite
of globals in the file.
>
- Why use multiple independent variables to describe the
blobs of storage? This is what structs are for.
Point well taken. Somewhere along the way I said to myself, self, you
really should have used structs. I haven't bothered to redo it yet,
but I shall.
>
- Why force `static' on all the identifiers? Might not a
user occasionally want external linkage, or maybe even
an `auto' version?
The issue is state. Static gives the storage elements file scope. If
you want external linkage then you really do want to use functions, put
them in their own file, and use some kind of handle. All auto buys you
is a bit of name isolation.
>
If you decide to do something about handling errors, I'll
take a longer look. But until and unless ...
What I decided to do was to let the user roll their own. Be that as it
may I thank you for your comments and thoughts.
Richard Harter said:
As a practical matter if realloc fails the using program will crash
almost immediately afterwards on dereferencing a null pointer.
As a practical matter, if realloc fails, the careful programmer will detect
this and find a way around that does not involve crashing. If you are
expecting people to use the macros intelligently, it is not unreasonable to
expect them to be intelligent people, and intelligent people don't ignore
vital information supplied to them by realloc (such as a null pointer
return value).
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.
On Wed, 08 Nov 2006 21:26:02 +0000, Richard Heathfield
<in*****@invali d.invalidwrote:
>Richard Harter said:
>As a practical matter if realloc fails the using program will crash
almost immediately afterwards on dereferencing a null pointer.
As a practical matter, if realloc fails, the careful programmer will detect
this and find a way around that does not involve crashing. If you are
expecting people to use the macros intelligently, it is not unreasonable to
expect them to be intelligent people, and intelligent people don't ignore
vital information supplied to them by realloc (such as a null pointer
return value).
Point well taken. If I take your point correctly, you are in the right
and Eric is in the wrong. That is, the package (macros, functions,
whatever) should let the user know in some way that there is a problem;
it is the user's decision as to what kind of error handling should be
done and not the package's, because it the user and not the package that
sets the context. In this case the macro may change the base pointer.
It is the users responsibility to check that it is not null and do
something about it.
My comment was in response to the suggestion that realloc failures could
lead to runaway memory leaks. No such thing - you never get there.
It's a side point though. I guess the right thing to do is to make a
point in the documentation that it is the user's responsibility to make
a validity check after resizing.
The other error that occurs to me is with the trim macro - what if the
trim is "too large". I'm not quite certain as to what to do there. cr*@tiac.net (Richard Harter) writes:
[...]
As a practical matter if realloc fails the using program will crash
almost immediately afterwards on dereferencing a null pointer.
You don't know that.
Including error checking is desirable of course, but what should it do?
The simplest thing to do is to abort the program; it's better to do so
immediately than to wait until it attempts to dereference the null
pointer.
There is no universal error checking policy. My thought here was to let
whoever used the package put in their own error checking. It would be
good to put in a comment like
/* Put in your own error check on realloc failure here */
A better way to do that would be for the package to return some sort
of error indication to the caller. (I haven't looked at your package
in enough detail to know how it should do that.)
--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Richard Harter said:
On Wed, 08 Nov 2006 21:26:02 +0000, Richard Heathfield
<in*****@invali d.invalidwrote:
>>Richard Harter said:
>>As a practical matter if realloc fails the using program will crash
almost immediately afterwards on dereferencing a null pointer.
As a practical matter, if realloc fails, the careful programmer will
detect this and find a way around that does not involve crashing. If you
are expecting people to use the macros intelligently, it is not
unreasonabl e to expect them to be intelligent people, and intelligent
people don't ignore vital information supplied to them by realloc (such as
a null pointer return value).
Point well taken. If I take your point correctly, you are in the right
and Eric is in the wrong.
Um, close, but no banana. I'm in the right and Eric is in the right.
To be more specific; in the following macro:
#define STG_ADD_SEGSPAC E(name,offset,l ength) \
do { \
offset = name##_used; \
name##_used += length; \
if (name##_used name##_alloc) { \
name##_alloc = 2*name##_alloc + length; \
name = realloc(name, name##_alloc*na me##_size); \
} \
} while (0)
....you make it more awkward than necessary to recover from a realloc
failure, because you overwrite the original pointer, rather than use a temp
in case of failure. That's a rookie mistake, and it doesn't give me
confidence in the code.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.
On Wed, 08 Nov 2006 22:14:03 GMT, Keith Thompson <ks***@mib.orgw rote:
>cr*@tiac.net (Richard Harter) writes:
[snip]
>
>Including error checking is desirable of course, but what should it do?
The simplest thing to do is to abort the program; it's better to do so
immediately than to wait until it attempts to dereference the null
pointer.
True.
>
>There is no universal error checking policy. My thought here was to let
whoever used the package put in their own error checking. It would be
good to put in a comment like
/* Put in your own error check on realloc failure here */
A better way to do that would be for the package to return some sort
of error indication to the caller. (I haven't looked at your package
in enough detail to know how it should do that.)
Actually, the error indication is already there - after resizing check
the base pointer for being null. The documentation should say that.
Thanks for the comments.
On Wed, 08 Nov 2006 22:27:40 +0000, Richard Heathfield
<in*****@invali d.invalidwrote:
>Richard Harter said:
>On Wed, 08 Nov 2006 21:26:02 +0000, Richard Heathfield
<in*****@inval id.invalidwrote :
>>>Richard Harter said:
As a practical matter if realloc fails the using program will crash
almost immediately afterwards on dereferencing a null pointer.
As a practical matter, if realloc fails, the careful programmer will
detect this and find a way around that does not involve crashing. If you
are expecting people to use the macros intelligently, it is not
unreasonab le to expect them to be intelligent people, and intelligent
people don't ignore vital information supplied to them by realloc (such as
a null pointer return value).
Point well taken. If I take your point correctly, you are in the right
and Eric is in the wrong.
Um, close, but no banana. I'm in the right and Eric is in the right.
I'll give you you, but not Eric. Eric implied that the error checking
should be in the macros. In this case, no.
>
To be more specific; in the following macro:
#define STG_ADD_SEGSPAC E(name,offset,l ength) \
do { \
offset = name##_used; \
name##_used += length; \
if (name##_used name##_alloc) { \
name##_alloc = 2*name##_alloc + length; \
name = realloc(name, name##_alloc*na me##_size); \
} \
} while (0)
...you make it more awkward than necessary to recover from a realloc
failure, because you overwrite the original pointer, rather than use a temp
in case of failure. That's a rookie mistake, and it doesn't give me
confidence in the code.
OTOH, this is well taken. The previous value should be saved and there
should be a recovery macro to restore the previous value. My bad here.
Thank you for the comments.
Richard Harter wrote On 11/08/06 16:04,:
On Wed, 08 Nov 2006 14:25:50 -0500, Eric Sosman <Er*********@su n.com>
wrote:
>>
Richard Harter wrote On 11/08/06 13:58,:
>>>Apologies for the length - this post is best viewed with fixed font
and a line width >= 72.
Below is the source code for a C header file that provides a suite
of storage management macros. I am asking for comments on it.
>>>/* Caveats: */
/* */
/* There is no error checking. Users are expected to use the macros */
/* intelligently. The calls are not followed by error checks on the */
/* returned value.
Indeed, there is no error checking. For example, realloc()
failure leaks memory unconditionally and irretrievably, to the
detriment of the program using the macros. To my mind, that
means there is exactly one way to use them intelligently: don't.
As a practical matter if realloc fails the using program will crash
almost immediately afterwards on dereferencing a null pointer.
As a practical matter, many programs will be unable to
do much more work after failing to obtain memory. But that
doesn't suggest they should crash! If you are in an airplane
and bad weather closes the closes the airport it's heading for,
the pilot might announce "Ladies and gentlemen, we're going
to land in Schenectady and wait out the storm" or he might
simply nosedive into a convenient feature of the landscape.
Which would you prefer: the landing or the crash?
Even if the "recovery" from an out-of-memory condition
consists of no more than termination with regrets, at least
give the program an opportunity to do so in a controlled
manner. When a realloc() fails in one of your macros, the
pointer to the still-allocated storage is lost; if the program
wants to save some of that data to disk before dying, it's
out of luck. (Well, it could first squirrel away a copy of
the pointer so it could repair your macro's variable after
the fact in the event of failure -- but a macro package that
requires such work-arounds doesn't seem to me to "simplify the
management of allocatable storage.")
Including error checking is desirable of course, but what should it do?
There is no universal error checking policy. My thought here was to let
whoever used the package put in their own error checking. It would be
good to put in a comment like
/* Put in your own error check on realloc failure here */
Exposing the failure to the user should be enough: if the
user can detect the failure, he can handle it according to
whatever framework is appropriate for the program. Alas, the
macros as they stand make his job harder rather than easier
(as described above).
> Without error-checking, the package is useless except in
toy programs where leaks and crashes don't really matter -- so
I'm not going to waste time studying your work in detail. A
few things stood out, though:
- Why this fascination with macros? Why not use functions?
It's the excessive macroization that's making error recovery
awkward (not impossible), whereas doing such things in
function contexts is relatively routine.
It's an alternative, but there are some issues. The functions had
better be local to the file (static); if not, you need something like
handles to avoid conflicts. You still need to create the same of suite
of globals in the file.
Okay, there's something about your design goals that I
haven't understood from reading the big comment block.
> - Why force `static' on all the identifiers? Might not a
user occasionally want external linkage, or maybe even
an `auto' version?
The issue is state. Static gives the storage elements file scope.
No: The presence or absence of `static' does not affect the
scope of an identifier. The keyword has a context-dependent
meaning which is either (1) to use internal instead of external
linkage for a file-scope identifier or (2) to use static instead
of dynamic storage duration for a block-scope variable.
If
you want external linkage then you really do want to use functions, put
them in their own file, and use some kind of handle. All auto buys you
is a bit of name isolation.
... and a fresh instance of the variable (freshly initialized
if there's an initializer) for each entry to the block. Written
any recursive functions lately?
-- Er*********@sun .com This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Shailesh |
last post by:
Hello,
I am using Oracle 10g and have configured OEM grid control. I am
searching for some tool like Capacity Planner which was present in
Oracle 9i OEM as a part of Oracle EM9i Management Packs.
Somewhere I read on metalink, that the package is not yet supported
(available) in 10g and will be introduced later. Is this true? If its
not supported are there any other tools or facilities available for
STORAGE CAPACITY PLANNING?
|
by: Nick Kew |
last post by:
Rationale
=========
Many applications today benefit from an SGML and/or XML Entity Catalogue
to dereference entities referenced by a Public Identifier. For a
validating SGML parser this is an absolute requirement. For any
SGML or XML parser it serves to enable entities such as DTDs and
modules to be resolved locally.
Hitherto, different packages and applications have distributed entity
|
by: Jeremy |
last post by:
Hi all,
I'm getting very confused about how DB2 uses shared memory and I
wonder if someone could clarify matters for me, please ?
We are running 32bit DB2 V7.2 FP9 under AIX 4.3.3 on a machine with 64
Gb of memory with a single non-partitioned database using extended
storage and with intra-parallelism enabled.
I've been experimenting with changing various parameters in an attempt
|
by: CompGeek |
last post by:
Hi there,
I am trying to load a file with 1729 records into a DB2 UDB EEE 7.1
DataBase (on AIX 4.3) which is across two partitions. The partitioning
key is BI_INSTITUTIONAL_KEY which is a BIGINT and is explicitly
defined in the table DDL (with "using hashing" ON). The autoloader
config file is attached below.
The results of the autoloader are as :
|
by: Ahmadf |
last post by:
Hi
I need to find out how much DASD has been used in a Very large DB (MVS DB2
environment) for every table space, or to put plainly how much of the space
is used from the underlying VSAM file. I am not talking DB2 pages, or leafs.
Just Plain DASD. I'll be grateful for any sort of JCL example.
I am sorry for posting this question here, I could not find any Storage news
group.
| | |
by: Lyle Fairfield |
last post by:
SQL Server Management Studio Express CTP is a freely downloadable utility
(http://www.microsoft.com/downloads/details.aspx?familyid=82afbd59-57a4-
455e-a2d6-1d4c98d40f6e&displaylang=en)
something like but not as extensive as MS-SQL Enterprise Manager.
Im am posting about this because:
I have not seen its use mentioned a lot here.
Some capabilities of Access 2003 (and prior) ADP MS-SQL interfaces fail for
SQL Studio Express; other...
|
by: Christoph Haas |
last post by:
Evening,
I'm currently working on a larger Python project that consists of multiple
programs and packages. As I need a few utility functions time and again I
moved them all into a Utility package and created a class there. Like this:
Util.py:
~~~~~~~~
class Util:
def __init__(self, debugFlag=False, vibranceLevel='good'):
|
by: Laurence |
last post by:
Hi folks,
DB2 UDB supports automatic storage management in v8.2.2 and v9. The
question is how do I know the databases and/or tablespaces are enable
"automatic storage management" or not after created for a period of
time?
Thanks in advance,
|
by: Ark Khasin |
last post by:
My pet project is a command-line utility (preprocessor), so it runs and
terminates. It uses lots of memory allocations; most of them are quite
small. What to do with the allocated objects when they are no longer
used? I consider the following "pure" strategies:
- Meticulously free anything ever malloc'ed. This involves
inefficiencies of calling free, but worse yet, in certain cases object
duplication appears necessary to ensure uniqueness...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
|
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: 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: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert into image.
Globals.ThisAddIn.Application.ActiveDocument.Select();...
|
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...
| |
