473,322 Members | 1,417 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,322 software developers and data experts.

C needs a BOOST

It would be really nice if C could adopt a really nice algorithms
library like C++'s STL + BOOST.

The recent "reverse the words in this sentence" problem posted made me
think about it.
It's like 5 lines to do it in C++ because of all the nifty algorithms
that come with the language (I think BOOST is going to get bolted on
to the C++ language like STL did).

It's a lot more work in C than C++. Why doesn't C have stacks,
dequeues, and other common, simple tool sets already in its standard
library?

Opinions? Is keeping the language tiny worth the cost of C
programmers having to constantly reinvent the wheel?

Oct 3 '07
259 6835
"Ian Collins" <ia******@hotmail.comwrote in message
news:5m************@mid.individual.net...
jacob navia wrote:
>>
But lists, stacks and hash tables aren't any
C++ invention as far as I remember. Why can't
the C language offer a common interface to use those
commonly used data structures?
Then how come after 30 odd years, it doesn't?
IMHVO, C is to low-level to standardize trivial collection interfaces.
However, I bet we could standardize an API for this newsgroup.

Oct 4 '07 #51
Chris Thomasson said:
"Ian Collins" <ia******@hotmail.comwrote in message
news:5m************@mid.individual.net...
>jacob navia wrote:
>>>
But lists, stacks and hash tables aren't any
C++ invention as far as I remember. Why can't
the C language offer a common interface to use those
commonly used data structures?
Then how come after 30 odd years, it doesn't?

IMHVO, C is to low-level to standardize trivial collection interfaces.
However, I bet we could standardize an API for this newsgroup.
Previous attempts by clc to participate in similar projects have not been
conspiciously successful.

Still - hope springs eternal, eh?

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Oct 4 '07 #52
Chris Thomasson wrote:
"user923005" <dc*****@connx.comwrote in message
news:11**********************@y42g2000hsy.googlegr oups.com...
>It would be really nice if C could adopt a really nice algorithms
library like C++'s STL + BOOST.

The recent "reverse the words in this sentence" problem posted made me
think about it.
It's like 5 lines to do it in C++ because of all the nifty algorithms
that come with the language (I think BOOST is going to get bolted on
to the C++ language like STL did).

It's a lot more work in C than C++. Why doesn't C have stacks,
dequeues, and other common, simple tool sets already in its standard
library?

You can program your collections in C. For instance, a simple "inline"
LIFO linked-list:

http://appcore.home.comcast.net/misc/macro-slist-c.html

This is not rocket-science...
You can also code it cleanly without resorting to macros!

--
Ian Collins.
Oct 4 '07 #53
user923005 wrote:
It would be really nice if C could adopt a really nice algorithms
library like C++'s STL + BOOST.
http://www.research.att.com/~gsf/dow...f/cdt/cdt.html
Oct 4 '07 #54
On Oct 3, 8:17 pm, Keith Thompson <ks...@mib.orgwrote:
jacob navia <ja...@nospam.orgwrites:

[...]
Generic functions like
list = list_add(list,int);
list = list_add(list,double);
list = list_add(list,&CustomerStruct);
would make the library very easy to use. Above all, they
could be extended by the user at any time with
list = list_add(list,&MyNewDataStruct);
P.S. I will look at the glib again.

Ok, but C doesn't have generic functions, and you can't write a
function that takes either an int, a double, or a pointer as its
second argument.
Um, what about:

int list_add(List *list, ...);

With the type of the variable argument known based on something set in
the
List when it is created? Mind you, that might be painful to use, but
it
seems to work. I guess all pointer lists would be void* or some such.

-David

Oct 4 '07 #55
jacob navia wrote:
[...] and gcc and Microsoft decided
to just drop C. Gcc hasn't still 8 years later finished the
C99 implementation, they do not participate into any standard
body (even if they could).
Jacob, you do your argument no favours with falsehoods like this.
It just shows you don't know what you're talking about.
Oct 4 '07 #56
Neil Booth wrote:
jacob navia wrote:
[...] and gcc and Microsoft decided
to just drop C. Gcc hasn't still 8 years later finished the
C99 implementation, they do not participate into any standard
body (even if they could).

Jacob, you do your argument no favours with falsehoods like this.
It just shows you don't know what you're talking about.
Of course "I do not know what I am talking about".

You do. Please tell us then, some proposition that gcc has done
since C99 for standardization. Or proposal. Or whatever in this
direction.

If possible I would like to know if the C99 support
is finished in gcc. Even if it is very good, the last thing I
know is a web page where VLAs and other features are marked missing
or broken.

http://gcc.gnu.org/c99status.html

Since I am not a member of GNU I have just to believe the
public information that GNU itself publishes. Sorry.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Oct 4 '07 #57
jacob navia wrote:
Neil Booth wrote:
>jacob navia wrote:
> [...] and gcc and Microsoft decided
to just drop C. Gcc hasn't still 8 years later finished the
C99 implementation, they do not participate into any standard
body (even if they could).

Jacob, you do your argument no favours with falsehoods like this.
It just shows you don't know what you're talking about.

Of course "I do not know what I am talking about".

You do. Please tell us then, some proposition that gcc has done
since C99 for standardization. Or proposal. Or whatever in this
direction.
He's trying to tell you that GCC developers *do* participate
in standards bodies. You said they do not, and that was wrong.
It's OK, we're all wrong sometimes. It's a chance to learn.

-- James
Oct 4 '07 #58
James Dennett wrote:
jacob navia wrote:
>Neil Booth wrote:
>>jacob navia wrote:

[...] and gcc and Microsoft decided
to just drop C. Gcc hasn't still 8 years later finished the
C99 implementation, they do not participate into any standard
body (even if they could).
Jacob, you do your argument no favours with falsehoods like this.
It just shows you don't know what you're talking about.
Of course "I do not know what I am talking about".

You do. Please tell us then, some proposition that gcc has done
since C99 for standardization. Or proposal. Or whatever in this
direction.

He's trying to tell you that GCC developers *do* participate
in standards bodies. You said they do not, and that was wrong.
It's OK, we're all wrong sometimes. It's a chance to learn.

-- James
OK. I see. They participate but they do not say that they are from
GNU or I do not know that fact and I think that nobody from
GNU is there.

A misunderstanding then.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Oct 4 '07 #59
jacob navia wrote:
This is an error. Keeping the language in this state makes the language
impossible to use for any serious software development
unless your project is big enough to warrant rewriting the
C library and adding stacks, lists, etc etc at each project!
That's certainly not true. A large number of applications,
especially for embedded systems, are coded nearly entirely in C.

Why would you not maintain your programming support library
for reuse across multiple projects? Unless, perhaps, you
don't know how to design it well enough for reuse.
Oct 4 '07 #60
jacob navia wrote:
gets() is still there and will stay with us at least till 2019.
gets() was part of the Base Library. Generally the C Standard
bearers are cautious about changing previously supported
standardized features in incompatible ways, such as removing
them. The two main examples of removing features were both in
response to proposals I championed (one in a DR): implicit int
and gets. (Yes, gets has been officially deprecated.)

I don't know where "2019" comes from.
Oct 4 '07 #61
jxh
On Oct 3, 1:05 pm, user923005 <dcor...@connx.comwrote:
[snip]
Opinions? Is keeping the language tiny worth the cost of C
programmers having to constantly reinvent the wheel?
It would be a nice experiment to add template support to C and see
what kinds of generic solutions would fall out from it. OTOH, there
are plenty of C shops that are using C++ compilers, and cherry pick
features they want to use (such as STL).

Nice troll, BTW. :-)

-- James

Oct 4 '07 #62
jacob navia wrote:
The C community reacted with a tendency to look into the past,
and it "enshrined" their language resisting any change
of it at all.
Your history and rationale were entirely wrong.

C99 did not radically change the existing standard interfaces
because that would not have been in the best interest of our
"customers". Even as a highly compatible upgrade, it took
a long time for C99 to become widely implemented. As an
incompatible product, it very likely would never have been
accepted at all.

The advantage of having a committee of experience experts
deciding on Standard C's direction is that there is balance
so that more relevant factors get considered before changes
are made. The net newsgroups have seen many people who think
that obviously they know best how things should be done and
that any other ideas are wrong-headed. Fortunately that is
not how C has evolved.
Oct 4 '07 #63
On Oct 4, 11:04 am, jxh <j...@despammed.comwrote:
On Oct 3, 1:05 pm, user923005 <dcor...@connx.comwrote:
[snip]
Opinions? Is keeping the language tiny worth the cost of C
programmers having to constantly reinvent the wheel?

It would be a nice experiment to add template support to C and see
what kinds of generic solutions would fall out from it. OTOH, there
are plenty of C shops that are using C++ compilers, and cherry pick
features they want to use (such as STL).
The problem I see with template support is that it requires operator
overloading.
The problem with operator overloading is tht it requires references.
Now, if you introduce references into C, it becomes a lot less "C-
like".
So I guess that monumental collections of generic programs requires a
language like C++.
Nice troll, BTW. :-)
It turned out that way, but it wasn't my intention. I was just
wondering aloud why the C++ side of the fence has this wonderful bag
of 1001 tricks and C has an itty-bitty one. I was thinking it would
be nice to have more pre-built tools for problem solving ready to go.
It turns out it was more difficult than I thought to produce it.

Oct 4 '07 #64
user923005 wrote:
On Oct 4, 11:04 am, jxh <j...@despammed.comwrote:
>On Oct 3, 1:05 pm, user923005 <dcor...@connx.comwrote:
[snip]
Opinions? Is keeping the language tiny worth the cost of C
programmers having to constantly reinvent the wheel?

It would be a nice experiment to add template support to C and see
what kinds of generic solutions would fall out from it. OTOH, there
are plenty of C shops that are using C++ compilers, and cherry pick
features they want to use (such as STL).

The problem I see with template support is that it requires operator
overloading.
The problem with operator overloading is tht it requires references.
Now, if you introduce references into C, it becomes a lot less "C-
like".
So I guess that monumental collections of generic programs requires a
language like C++.
>Nice troll, BTW. :-)

It turned out that way, but it wasn't my intention. I was just
wondering aloud why the C++ side of the fence has this wonderful bag
of 1001 tricks and C has an itty-bitty one. I was thinking it would
be nice to have more pre-built tools for problem solving ready to go.
It turns out it was more difficult than I thought to produce it.
Well if you take into account non-Standard code, then the amount of reusable
code in C, for C, is *massive*

It's just that the Standardised library is quite small, but many of the
reasons Doug Gywn has listed seem very plausible to me.

Oct 4 '07 #65
jacob navia wrote:
Well, lcc-win32 *can* use the libc from the system, the libc from the
Microsoft compiler and probably the libc of GNU...
There are many reasons to use a different compiler.
>e.g. when allocating a big array on stack on Win32, they may call a
function (whose name starts with two underscores or one underscore and
a upper-case letter) that touches the stack at every multiple of 4096
bytes.
Changing the standard library breaks that.

No. If they are shared objects they just have a copy of the C runtime
with them anyway.
Maybe for lcc-win32.
That it works for *one* compiler is insufficient.
I said:

Link with another library

I did not said:

Use two libraries for lists at the same time!
Which isn't possible with Borland C, for example, because non-standard
functions of the default library are implicitly linked even for very
simple pieces of code.

Moreover, if one function is inlined, it may be recognized BY NAME.
e.g. A call to memset, even if it's imported in a third party library may
be replaced by raw assembly code.
Redefining a library function is undefined behavior, and is likely to
behave badly on many implementations.

Maybe *your* compiler wouldn't make it that way, but that doesn't mean
other compilers won't.
Note:
I used only ONE exclamation mark.
Good.

No. The list module I wrote makes fir 2380 bytes of code
and 204 bytes of data. Maybe adding some overhead it *could* grow to
4-5K.
I think that's small enough to be a perfectly acceptable proposal.
If you add the modules for a few other common containers, it should still
be acceptable...
If possible, you should write a proposal that doesn't require extra
features (e.g. OOL), then, it has some chance of being accepted.
However, I highly doubt you can do something as full-featured as the
STL+BOOST as the OP wishes, in less than several hundred of kilobytes.

--
If you've a question that doesn't belong to Usenet, contact me at
<ta*****************@yahoDELETETHATo.fr>
Oct 4 '07 #66
James Dennett wrote:
>
And yet the field of generic programming has been built for
years on a foundation of abstraction *not* costing performance,
which is to a large extent realized with C++'s STL and real
current compilers.
Not to a so large extent.
Maybe the string append function of std::string is as fast as, or faster
than, I could ever write, but, when using std::string, anybody tends to
make much much more copies and costy operations than when manually
managing pointers.
I remember than, when I refactored a lexical parser using the STL, to use
lower level features, I got a x20 speed up, keeping the same algorithmic
complexity.

--
If you've a question that doesn't belong to Usenet, contact me at
<ta*****************@yahoDELETETHATo.fr>
Oct 4 '07 #67
jacob navia wrote:

P.S. I will look at the glib again.
Yes, in particular, even if the GNU implementation may be of low quality,
and to big, it may be possible to keep the SAME interface, and get a
lightweight library.

If GLib is too big, it may be possible to take a meaningful subset of
GLib, of course.
--
If you've a question that doesn't belong to Usenet, contact me at
<ta*****************@yahoDELETETHATo.fr>
Oct 4 '07 #68
Douglas A. Gwyn wrote:
Ian Collins wrote:
>My conclusion has to be that the demand isn't there.

The very age of C might be partly responsible, in that the vast
amount of existing C applications already embed some solutions
to the requirements for lists, etc. The maintenance programmer
(a)is unlikely to rework the existing app just to use some new
standardized interface for the same thing; and (b) has to
continue to maintain whatever libraries he has been using.

The only real use for such a library would be for new program
development, once the learning hurdle has been overcome. Much
new development really ought to use higher-level languages in
the first place.
Excuse me but did I understand you correctly?

That library would be of no use but in new code you say.

Then,

"Much new development really ought to use higher level
languages in the first place".

So, you say that new development shouldn't be done in C but in
"higher level" languages.

Actually then, you say it is better not to develop anything new in C.

OK. I understand better now, what do you think about C, and
why our viewpoints differ completely. Until now I thought that
you (like people in a news group about the C language) would
agree that C is a language that is worth developing code
in.

I would like that you claify this of course. Did I understand you
correctly?
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Oct 4 '07 #69
Douglas A. Gwyn wrote:
The only real use for such a library would be for new program
development, once the learning hurdle has been overcome. Much
new development really ought to use higher-level languages in
the first place.
C can still be a good choice for many new projects.

--
If you've a question that doesn't belong to Usenet, contact me at
<ta*****************@yahoDELETETHATo.fr>
Oct 4 '07 #70
jacob navia wrote:
C is then seen as an old and obsolete language by most
programmers. Its main use should be in small circuit
boards where there is no space for a language like
C++.
I see more C as an UNIVERSAL language that had the advantage of not
changing every two years.
That's wonderful how PORTABLE C90 is. Much more portable than C++98.
(C99 broke the portability dream, which explains why C90 is still much
more popular than C99)
That's wonderful how reliable are the ports of C90 programs. You don't
have version conflicts.
C90 is ONE language.
Not changing is the strength of C90.

NOTE: I don't think that the container library would "break" the C
language. It wouldn't be a big change. It wouldn't create any
incompatibility. It may not increase too much the size of the library.
When those circuit boards disappear, C will disappear
with them. It will remain (like COBOL) in a frozen state
for the biggest part of this century as the software
written in C is slowly rewritten in other, more
modern languages.
If that happens, would you die?
That's not as if there had to be an affectional relation to a language.
Sometimes it's better to use an entirely different new language, instead
of cheating in transforming the first language in the latter and creating
thousands of painful compatibility issues.
What is crucial is that the library has a small memory footprint.
Not in RAM of course, but in HUMAN memory footprint. This means that
the library is easy to remember and use, that it has a consistent
naming, and that it is kept as simple as possible.
It would equally be good if it had a small RAM footprint. :)
Software has a tendency to bloat forever.
As languages have. Compare C99 to K&R C. Compare Fotran 2003 to Fotran 66.

--
If you've a question that doesn't belong to Usenet, contact me at
<ta*****************@yahoDELETETHATo.fr>
Oct 4 '07 #71
jacob navia wrote:
Neil Booth wrote:
>jacob navia wrote:
> [...] and gcc and Microsoft decided
to just drop C. Gcc hasn't still 8 years later finished the
C99 implementation, they do not participate into any standard
body (even if they could).
Jacob, you do your argument no favours with falsehoods like this.
It just shows you don't know what you're talking about.

Of course "I do not know what I am talking about".

You do. Please tell us then, some proposition that gcc has done
since C99 for standardization. Or proposal. Or whatever in this
direction.

If possible I would like to know if the C99 support
is finished in gcc. Even if it is very good, the last thing I
know is a web page where VLAs and other features are marked missing
or broken.
GCC TRIES to support C99, but hasn't yet got it.
Similarly, GCC TRIES to support C++98, but hasn't yet got it.
Well, actually, it doesn't try to get full C++98 conformance, while it
does, for C99!
(GCC doesn't try to implement the C++ export feature).

The fact that C99 is already to big and requires YEARS to be implemented
correctly (unlike C90 which is much simplier)

Implementing standards requires time. Especially when they're big.

--
If you've a question that doesn't belong to Usenet, contact me at
<ta*****************@yahoDELETETHATo.fr>
Oct 4 '07 #72
jacob navia wrote:
But even if I use the same syntax, the simplicity of the language
is preserved. That's why I was completely opposed to introducing
constructors for instance, remember?
And of course, it's obvious to everybody that OOL is much easier to
implement than constructors. Maybe it's possible to implement constructors
in 2000 LOC as you did for OOL.

Did you know that C++ had slowly evolved from C?
"C with objects" was very small.
Then, it became C++ as new features were added.

Similarly C evolved continuously from B... But, C99 clearly is much bigger
than B.

--
If you've a question that doesn't belong to Usenet, contact me at
<ta*****************@yahoDELETETHATo.fr>
Oct 4 '07 #73
jacob navia <ja***@nospam.orgwrites:
Since I am not a member of GNU I have just to believe the
public information that GNU itself publishes. Sorry.
I don't think that there is such a thing as a "member of GNU".
--
Ben Pfaff
http://benpfaff.org
Oct 4 '07 #74
user923005 wrote:
The problem I see with template support is that it requires operator
overloading.
It's simply huge, very complex, and causes linking issues.
It's also quite weak without function overloading support with complex
resolution rules.
Classes support, with constructors and destructors, also greatly help to
the functionality of C++ templates.

--
If you've a question that doesn't belong to Usenet, contact me at
<ta*****************@yahoDELETETHATo.fr>
Oct 4 '07 #75
user923005 wrote:
overloading.
The problem with operator overloading is tht it requires references.
Now, if you introduce references into C, it becomes a lot less "C-
like".
So I guess that monumental collections of generic programs requires a
language like C++.
There are many other solutions.

I rewrote part of my library with

list list_add(list, $$T$$ arg)
{
// code
}

and developed a very small program that would automatically specialize
the generic code for a given type. Then you pass the expanded
code to the compiler and put it in a static library.

The C++ compiler makes not *much* more and this is completely
customizable, simple and easy to use.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Oct 4 '07 #76
"Ben Pfaff" <bl*@cs.stanford.edua écrit dans le message de news:
87************@blp.benpfaff.org...
jacob navia <ja***@nospam.orgwrites:
>Since I am not a member of GNU I have just to believe the
public information that GNU itself publishes. Sorry.

I don't think that there is such a thing as a "member of GNU".
Since you are playing smartie, let's see how good your French is:

Le membre du gnou peut mesurer jusqu'à un mètre en érection.

For sure, you would want to stay out of its way ;-)

--
Chqrlie.
Oct 4 '07 #77
David Resnick wrote:
On Oct 3, 8:17 pm, Keith Thompson <ks...@mib.orgwrote:
jacob navia <ja...@nospam.orgwrites:

[...]
Generic functions like
list = list_add(list,int);
list = list_add(list,double);
list = list_add(list,&CustomerStruct);
would make the library very easy to use. Above all, they
could be extended by the user at any time with
list = list_add(list,&MyNewDataStruct);
P.S. I will look at the glib again.
Ok, but C doesn't have generic functions, and you can't write a
function that takes either an int, a double, or a pointer as its
second argument.

Um, what about:

int list_add(List *list, ...);

With the type of the variable argument known based on something set in
the
List when it is created? Mind you, that might be painful to use, but
it
seems to work. I guess all pointer lists would be void* or some such.
Difficult to do with a user-defined type.


Brian
Oct 4 '07 #78
On Oct 4, 4:16 pm, "Default User" <defaultuse...@yahoo.comwrote:
David Resnick wrote:
On Oct 3, 8:17 pm, Keith Thompson <ks...@mib.orgwrote:
jacob navia <ja...@nospam.orgwrites:
[...]

Ok, but C doesn't have generic functions, and you can't write a
function that takes either an int, a double, or a pointer as its
second argument.
Um, what about:
int list_add(List *list, ...);
With the type of the variable argument known based on something set in
the
List when it is created? Mind you, that might be painful to use, but
it
seems to work. I guess all pointer lists would be void* or some such.

Difficult to do with a user-defined type.

Brian
Which is why I said all pointer lists would be void *. I'd guess the
list needs something like a union of all types supported. Which
wouldn't include user defined types (by which you mean structs I
assume?), though pointers to those types would be fine... I agree it
would be clunky, just possible.

-David
Oct 4 '07 #79
jacob navia wrote:
user923005 wrote:
>overloading.
The problem with operator overloading is tht it requires references.
Now, if you introduce references into C, it becomes a lot less "C-
like".
So I guess that monumental collections of generic programs requires a
language like C++.

There are many other solutions.

I rewrote part of my library with

list list_add(list, $$T$$ arg)
{
// code
}

and developed a very small program that would automatically specialize
the generic code for a given type. Then you pass the expanded
code to the compiler and put it in a static library.

The C++ compiler makes not *much* more and this is completely
customizable, simple and easy to use.

P.S. Here is the code, using the string library of lcc-win32:
#include <str.h>
int main(int argc,char *argv[])
{
if (argc < 4) {
printf(
"Usage: %s <template file<resulting type<input type\n",argv[0]);
return 1;
}
// Read a file into a string
String template = Strfromfile(argv[1],0);
// Replace TYPENAME with input type
Strrepl(template,"$(TYPENAME)",argv[2]);
// Replace T with output Type
Strrepl(template,"$(T)",argv[3]);
// Note the cast of a String into a char *
printf("%s\n",(char *)template);
// Done
return 0;
}
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Oct 4 '07 #80
jacob navia wrote:
Douglas A. Gwyn wrote:
>Ian Collins wrote:
>>My conclusion has to be that the demand isn't there.

The very age of C might be partly responsible, in that the vast
amount of existing C applications already embed some solutions
to the requirements for lists, etc. The maintenance programmer
(a)is unlikely to rework the existing app just to use some new
standardized interface for the same thing; and (b) has to
continue to maintain whatever libraries he has been using.

The only real use for such a library would be for new program
development, once the learning hurdle has been overcome. Much
new development really ought to use higher-level languages in
the first place.

Excuse me but did I understand you correctly?
<snip>
So, you say that new development shouldn't be done in C but in
"higher level" languages.

Actually then, you say it is better not to develop anything new in C.
You talk as if C were a silver bullet. Different languages are suitable for
different tasks. C is not suitable for any and every type of programming.
It very good in what it _is_ suitable for, which is why it is among the top
five oldest programming languages. But things change.

It funny you know, how you constantly complain that the "regulars" of this
group, (and comp.std.c), want to "enshrine" C and cling to the past, while
you're doing exactly the same. You seem to be obsessed with "saving" C from
a supposed death. As Andre Gillibert asked, would it _kill_ you if C did
indeed slowly fade away?

I hope we all agree that programming is more important than any one language
or the other.

Oct 4 '07 #81
"jacob navia" <ja***@nospam.orga écrit dans le message de news:
47***********************@news.orange.fr...
jacob navia wrote:
>user923005 wrote:
>>overloading.
The problem with operator overloading is tht it requires references.
Now, if you introduce references into C, it becomes a lot less "C-
like".
So I guess that monumental collections of generic programs requires a
language like C++.

There are many other solutions.

I rewrote part of my library with

list list_add(list, $$T$$ arg)
{
// code
}

and developed a very small program that would automatically specialize
the generic code for a given type. Then you pass the expanded
code to the compiler and put it in a static library.

The C++ compiler makes not *much* more and this is completely
customizable, simple and easy to use.


P.S. Here is the code, using the string library of lcc-win32:
#include <str.h>
int main(int argc,char *argv[])
{
if (argc < 4) {
printf(
"Usage: %s <template file<resulting type<input type\n",argv[0]);
return 1;
}
// Read a file into a string
String template = Strfromfile(argv[1],0);
// Replace TYPENAME with input type
Strrepl(template,"$(TYPENAME)",argv[2]);
// Replace T with output Type
Strrepl(template,"$(T)",argv[3]);
// Note the cast of a String into a char *
printf("%s\n",(char *)template);
what does this cast do?
is it a form of operator overloading?
what is the life cycle of the char array to which a pointer is returned?
or are your Strings both '\0' terminated and length specified?
// Done
return 0;
}
--
Chqrlie.
Oct 4 '07 #82
santosh wrote:
jacob navia wrote:
>Douglas A. Gwyn wrote:
>>Ian Collins wrote:
My conclusion has to be that the demand isn't there.
The very age of C might be partly responsible, in that the vast
amount of existing C applications already embed some solutions
to the requirements for lists, etc. The maintenance programmer
(a)is unlikely to rework the existing app just to use some new
standardized interface for the same thing; and (b) has to
continue to maintain whatever libraries he has been using.

The only real use for such a library would be for new program
development, once the learning hurdle has been overcome. Much
new development really ought to use higher-level languages in
the first place.
Excuse me but did I understand you correctly?

<snip>
>So, you say that new development shouldn't be done in C but in
"higher level" languages.

Actually then, you say it is better not to develop anything new in C.

You talk as if C were a silver bullet. Different languages are suitable for
different tasks. C is not suitable for any and every type of programming.
It very good in what it _is_ suitable for, which is why it is among the top
five oldest programming languages. But things change.

It funny you know, how you constantly complain that the "regulars" of this
group, (and comp.std.c), want to "enshrine" C and cling to the past, while
you're doing exactly the same. You seem to be obsessed with "saving" C from
a supposed death. As Andre Gillibert asked, would it _kill_ you if C did
indeed slowly fade away?
I have been working since 12 years in the development of a C99
compatible standard compliant compiler system. I wanted a system easy
to use, simple, with a simple language but with all modern
sophistication of a windowed debugger, a good IDE, etc.

Yes, I believe in simple, small things. The whole IDE of lcc-win
makes for a 700K executable, compared to modern IDes that need
more than hundre MB for the same thing it demonstrates the power
of the language.

I am convinced that C is the way of the future. Simple, transparent,
it requires less memory from the user's brain, less figuring out
of what is going on, less opaque "black boxes" like the C++
compiler, programs of a sheer complexity that nobody understands
any more.

I see this at work when a coworker tells me:

Ohh sh...! This module uses the STL and I just do not understand
at all what it does!

Remember the dinosaurs?

They were extremely sophisticated compared to the small mammals.

:-)
I hope we all agree that programming is more important than any one language
or the other.
Not so. I remember APL for instance, a language that deeply
impressed me. It was fun to program in APL.

I remember MWBAsic too. It wasn't the same thing as in APL.

Yes, I program a lot in assembly, but that is completely different
again.

The language matters. And I think C is the way to go. Small
efficient and simple.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Oct 4 '07 #83
Charlie Gordon wrote:
"jacob navia" <ja***@nospam.orga écrit dans le message de news:
47***********************@news.orange.fr...
>jacob navia wrote:
>>user923005 wrote:
overloading.
The problem with operator overloading is tht it requires references.
Now, if you introduce references into C, it becomes a lot less "C-
like".
So I guess that monumental collections of generic programs requires a
language like C++.
There are many other solutions.

I rewrote part of my library with

list list_add(list, $$T$$ arg)
{
// code
}

and developed a very small program that would automatically specialize
the generic code for a given type. Then you pass the expanded
code to the compiler and put it in a static library.

The C++ compiler makes not *much* more and this is completely
customizable, simple and easy to use.

P.S. Here is the code, using the string library of lcc-win32:
#include <str.h>
int main(int argc,char *argv[])
{
if (argc < 4) {
printf(
"Usage: %s <template file<resulting type<input type\n",argv[0]);
return 1;
}
// Read a file into a string
String template = Strfromfile(argv[1],0);
// Replace TYPENAME with input type
Strrepl(template,"$(TYPENAME)",argv[2]);
// Replace T with output Type
Strrepl(template,"$(T)",argv[3]);
// Note the cast of a String into a char *
printf("%s\n",(char *)template);

what does this cast do?
"Unbox" the structure and return a plain char pointer.
is it a form of operator overloading?
yes
what is the life cycle of the char array to which a pointer is returned?
It still belongs to the string.
or are your Strings both '\0' terminated and length specified?
Both. This is useful as an extra check that a valid
string is passed to me. I know at all times that

String->Data[length] == 0

If that is not the case this is not a string!
>
>// Done
return 0;
}

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Oct 4 '07 #84
jxh
On Oct 4, 11:37 am, user923005 <dcor...@connx.comwrote:
On Oct 4, 11:04 am, jxh <j...@despammed.comwrote:
On Oct 3, 1:05 pm, user923005 <dcor...@connx.comwrote:
[snip]
Opinions? Is keeping the language tiny worth the cost of C
programmers having to constantly reinvent the wheel?
It would be a nice experiment to add template support to C and see
what kinds of generic solutions would fall out from it. OTOH, there
are plenty of C shops that are using C++ compilers, and cherry pick
features they want to use (such as STL).

The problem I see with template support is that it requires operator
overloading.
The problem with operator overloading is tht it requires references.
Now, if you introduce references into C, it becomes a lot less "C-
like".
So I guess that monumental collections of generic programs requires a
language like C++.
I was thinking of templates as a more elegant and powerful mechanism
for code generation than what C macros provide today. The type safety
aspect of templates are also a plus. I was not thinking of trying to
replicate STL or BOOST into C.

My hope was that clever C developers would figure out how to use C
templates for useful generic and type safe solutions that are more
efficient than the current approach of void * containers and
algorithms.

This is in the spirit of how STL evolved. C++ introduced templates
without STL first. STL was a by product of a useful C++ feature, not
a feature of C++ itself (Doug G. pointed this out).

-- James

Oct 5 '07 #85
André Gillibert wrote:
James Dennett wrote:
>>
And yet the field of generic programming has been built for
years on a foundation of abstraction *not* costing performance,
which is to a large extent realized with C++'s STL and real
current compilers.

Not to a so large extent.
YMMV. I've seen it achieved to an extent I judge to be
very large indeed. Your experience may not cover that;
maybe you've seen too much bad code and not enough good
code. (Come to that, *I've* seen too much bad code and
not enough good code. A common ailment.)
Maybe the string append function of std::string is as fast as, or faster
than, I could ever write, but, when using std::string, anybody tends to
make much much more copies and costy operations than when manually
managing pointers.
Bad programmers write bad code with std::string, it's true.
And they also write horrendous code when managing pointers
manually.
I remember than, when I refactored a lexical parser using the STL, to
use lower level features, I got a x20 speed up, keeping the same
algorithmic complexity.
Similarly, you might get a factor of 20 speedup by using a
good modern std::string compared to most manual pointer based
approaches, in particular as it can avoid dynamic allocation
for most strings while keeping code simple.

(There are also terrible implementations of std::string out
there, which used inappropriate pessimisations such as CoW
particularly in multi-threaded situations.)

However, std::string isn't/wasn't part of the STL, so this
somewhat misses the point. It's certainly not an example of
elegant design; it was a result of standardizing existing
practice, which happened to be ugly.

I fear this is drifting off-topic on comp.std.c, and even
for comp.lang.c. I'll bow out at this point; you may have
the last word if you wish.

-- James
Oct 5 '07 #86
On 5 oct, 05:22, jxh <j...@despammed.comwrote:
On Oct 4, 11:37 am, user923005 <dcor...@connx.comwrote:
On Oct 4, 11:04 am, jxh <j...@despammed.comwrote:
On Oct 3, 1:05 pm, user923005 <dcor...@connx.comwrote:
[snip]
Opinions? Is keeping the language tiny worth the cost of C
programmers having to constantly reinvent the wheel?
It would be a nice experiment to add template support to C and see
what kinds of generic solutions would fall out from it. OTOH, there
are plenty of C shops that are using C++ compilers, and cherry pick
features they want to use (such as STL).
The problem I see with template support is that it requires operator
overloading.
The problem with operator overloading is tht it requires references.
Now, if you introduce references into C, it becomes a lot less "C-
like".
So I guess that monumental collections of generic programs requires a
language like C++.

I was thinking of templates as a more elegant and powerful mechanism
for code generation than what C macros provide today. The type safety
aspect of templates are also a plus.
Type safety can be achieved easily in C. See my post for a generic
typesafe array in this news groups some time ago (google for "deniau
array"):

http://groups.google.fr/group/comp.l...263e52c0850000

The code is a bit heavy (e.g. macro B()) because despite of its
genericity and its type safety, it behaves like a C array (i.e. arr[i]
is valid) while array_get provides bound-checked access. It was part
of my previous framework (called Object Oriented C aka ooc) so it is
not complete and requires the framework for exception handling. But it
takes 10 minutes to make it standalone. I have also other typesafe ADT
containers like hash table and set. The technic is not new and
frequently used in the C++ STL where templated code (e.g. std::map)
rely on standalone generic code to avoid code blowup.
I was not thinking of trying to
replicate STL or BOOST into C.
good since you can't.
My hope was that clever C developers would figure out how to use C
templates for useful generic and type safe solutions that are more
efficient than the current approach of void * containers and
algorithms.
What you can't do with macros that templates can do is specialisation.
And this is the conerstone of the "more efficient when appropriate"
like for bool containers.
This is in the spirit of how STL evolved. C++ introduced templates
without STL first. STL was a by product of a useful C++ feature, not
a feature of C++ itself (Doug G. pointed this out).
Right, but once you put the fingers into templated code, it's hard to
get out of it. BTW, templates are turing complete while cpp macros are
not. Not talking of the heavy mecanism required by the macros to
emulate part of the templates features. People who find templates
metaprogramming hugly might be afraid by macros metaprogramming.

a+, ld.

Oct 5 '07 #87
On 3 Oct, 23:32, jacob navia <ja...@nospam.orgwrote:
Note:
I used only ONE exclamation mark.

no you didn't.
Why do you say things like this!
--
Nick keighley

Oct 5 '07 #88
On 3 Oct, 22:31, jacob navia <ja...@nospam.orgwrote:

<snip>
Because C's implementation should be SUBSTANTIALLY smaller,
giving just bare bones usage and not all the blat that comes
with the STL
so what could be ommitted?

<snip>
Yes. SMALL! Like C. And the point of is that SMALL is better in
software. Like smaller integrated circuits that are MORE efficient
than bulky ones,
bad analogy. In transistor count (ie. functionality) ICs are
getting bigger. Much bigger. That's one reason there are so few
CPU designs out there. Designing a modern IC is expensive.
SMALL software components are more mangeable and
easy to understand and USE!!!!!!!
count the '!'s...

<snip>
--
Nick Keighley
Oct 5 '07 #89
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:se*********************@bt.com...
Chris Thomasson said:
>"Ian Collins" <ia******@hotmail.comwrote in message
news:5m************@mid.individual.net...
>>jacob navia wrote:

But lists, stacks and hash tables aren't any
C++ invention as far as I remember. Why can't
the C language offer a common interface to use those
commonly used data structures?

Then how come after 30 odd years, it doesn't?

IMHVO, C is to low-level to standardize trivial collection interfaces.
However, I bet we could standardize an API for this newsgroup.

Previous attempts by clc to participate in similar projects have not been
conspiciously successful.

Still - hope springs eternal, eh?
Humm... I will post an example LIFO linked collection API (e.g. stack) in a
day or two. We should be able to tear it apart into something usable... A
simple standardized API wrt this newsgroup could be beneficial. Well, any
question that deals with common/trivial collection abstractions can be
directed at the various implementations of this newsgroups standardized API.

There is only one requirement I would personally leverage against any
submission: The KISS principal should be the main goal... C is low-level,
therefore we should keep anything we create for this group bound to the land
of minimalism...

Any thoughts?

Oct 5 '07 #90
Chris Thomasson wrote:
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:se*********************@bt.com...
>Chris Thomasson said:
>>"Ian Collins" <ia******@hotmail.comwrote in message
news:5m************@mid.individual.net...
jacob navia wrote:
>
But lists, stacks and hash tables aren't any
C++ invention as far as I remember. Why can't
the C language offer a common interface to use those
commonly used data structures?
>
Then how come after 30 odd years, it doesn't?

IMHVO, C is to low-level to standardize trivial collection interfaces.
However, I bet we could standardize an API for this newsgroup.

Previous attempts by clc to participate in similar projects have not been
conspiciously successful.

Still - hope springs eternal, eh?

Humm... I will post an example LIFO linked collection API (e.g. stack)
in a day or two. We should be able to tear it apart into something
usable... A simple standardized API wrt this newsgroup could be
beneficial. Well, any question that deals with common/trivial collection
abstractions can be directed at the various implementations of this
newsgroups standardized API.

There is only one requirement I would personally leverage against any
submission: The KISS principal should be the main goal... C is
low-level, therefore we should keep anything we create for this group
bound to the land of minimalism...

Any thoughts?
Perfect!
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Oct 5 '07 #91
Chris Thomasson said:
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:se*********************@bt.com...
>Chris Thomasson said:
<snip>
>>IMHVO, C is to low-level to standardize trivial collection interfaces.
However, I bet we could standardize an API for this newsgroup.

Previous attempts by clc to participate in similar projects have not
been conspiciously successful.

Still - hope springs eternal, eh?

Humm... I will post an example LIFO linked collection API (e.g. stack) in
a day or two.
Um... well, it's entirely up to you, obviously.
We should be able to tear it apart into something usable...
Knowing clc, I can guarantee the first bit. I'm not so sure about the
second. :-)

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Oct 5 '07 #92
On 2007-10-03 at 17:31 jacob navia wrote:
....
easy to understand and USE!!!!!!!
On 2007-10-03 at 18:32 jacob navia wrote:
....
I used only ONE exclamation mark.
I count 7. Is the name for 7 spelled "ONE" in your part of the world?
Oct 5 '07 #93
James Kuyper Jr. wrote:
On 2007-10-03 at 17:31 jacob navia wrote:
...
easy to understand and USE!!!!!!!

On 2007-10-03 at 18:32 jacob navia wrote:
...
>I used only ONE exclamation mark.

I count 7. Is the name for 7 spelled "ONE" in your part of the world?
They're just multiple /references/ to the same Platonic ideal exclamation
mark.

--
Chris "no, wait, references are /C++/ ..." Dollin

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

Oct 5 '07 #94
Chris Thomasson wrote On 10/05/07 06:14,:
>
Humm... I will post an example LIFO linked collection API (e.g. stack) in a
day or two. We should be able to tear it apart into something usable... A
simple standardized API wrt this newsgroup could be beneficial. Well, any
question that deals with common/trivial collection abstractions can be
directed at the various implementations of this newsgroups standardized API.

There is only one requirement I would personally leverage against any
submission: The KISS principal should be the main goal... C is low-level,
therefore we should keep anything we create for this group bound to the land
of minimalism...

Any thoughts?
Perhaps it might be too ambitious to begin with
something as advanced as a stack. How about starting
with a lower-level data structure, just to get the
hang of designing API's that the C community at large
will find useful? How about a suite of functions to
manage an array of elements, for example?

struct ArrayHandle *
ArrayCreate(size_t count, size_t esize);

void
ArrayStore(struct ArrayHandle *handle,
size_t index, const void *pdata);

void
ArrayFetch(struct ArrayHandle *handle,
size_t index, void *pdata);

void
ArrayDestroy(struct ArrayHandle *handle);

Hmmm... Given the somewhat contentious tone of
the C discussion groups, even that might be too
controversial. It might be more prudent to begin
with an API for manipulating int values, like

int IntAdd(int x, int y);
int IntSubtract(int x, int y);
int IntMultiply(int x, int y);
int IntDivide(int x, int y);
int IntModulus(int x, int y);
_Bool IntLessThan(int x, int y);
_Bool IntLessThanOrEqual(int x, int y);
_Bool IntEqual(int x, int y);
_Bool IntGreaterThanOrEqual(int x, int y);
_Bool IntGreaterThan(int x, int y);
_Bool IntNotEqual(int x, int y);
int IntShiftLeft(int x, int bits);
int IntShiftRight(int x, int bits);
int IntAnd(int x, int y);
int IntInclusiveOr(int x, int y);
int IntExclusiveOr(int x, int y);
int IntUnaryMinus(int x);
int IntUnaryPlus(int x);
int IntComplement(int x);
long IntPromoteToLong(int x);
int LongDemoteToInt(long x);
int ShortPromoteToInt(short x);
short IntDemoteToShort(int x);
...

(For efficiency's sake, some of these functions might
also be implemented with masking macros.)

Comments?

--
Er*********@sun.com

Oct 5 '07 #95
Eric Sosman said:

<snip>
>
Perhaps it might be too ambitious to begin with
something as advanced as a stack. How about starting
with a lower-level data structure, just to get the
hang of designing API's that the C community at large
will find useful? How about a suite of functions to
manage an array of elements, for example?

struct ArrayHandle *
ArrayCreate(size_t count, size_t esize);
Add parameters for maximum capacity (to prevent Denial of Memory attacks),
constructor (a pointer to a function that creates space for a new object
if necessary, and properly copies a provided object into it), destructor
(to take it down properly), and a comparator (to compare two objects
within the array). You might also want to add an iterator function
pointer, although you might prefer to provide an iterator-setting function
instead, since it is entirely possible that you might want to use
different functions for different purposes.
>
void
ArrayStore(struct ArrayHandle *handle,
size_t index, const void *pdata);
And another void * to allow ancillary data to be used in the copy, and
return an int which indicates whether the copy was successful.
>
void
ArrayFetch(struct ArrayHandle *handle,
size_t index, void *pdata);
How about returning a pointer to the object, to simplify the call?
>
void
ArrayDestroy(struct ArrayHandle *handle);
** rather than * please, so that the function can set the pointer to NULL
after taking down the object.
Hmmm... Given the somewhat contentious tone of
the C discussion groups, even that might be too
controversial. It might be more prudent to begin
with an API for manipulating int values, like

int IntAdd(int x, int y);
int IntSubtract(int x, int y);
int IntMultiply(int x, int y);
int IntDivide(int x, int y);
int IntModulus(int x, int y);
Add a mechanism to each of these for dealing with overflow, division by
zero, etc.
_Bool IntLessThan(int x, int y);
_Bool IntLessThanOrEqual(int x, int y);
_Bool IntEqual(int x, int y);
_Bool IntGreaterThanOrEqual(int x, int y);
_Bool IntGreaterThan(int x, int y);
_Bool IntNotEqual(int x, int y);
Why not int? No sense in alienating our 2 to 3% of Turbo C users...
int IntShiftLeft(int x, int bits);
int IntShiftRight(int x, int bits);
int IntAnd(int x, int y);
int IntInclusiveOr(int x, int y);
int IntExclusiveOr(int x, int y);
int IntUnaryMinus(int x);
int IntUnaryPlus(int x);
int IntComplement(int x);
Again, you need mechanisms to deal with invalid inputs.
long IntPromoteToLong(int x);
int LongDemoteToInt(long x);
int ShortPromoteToInt(short x);
short IntDemoteToShort(int x);
Same here (for the demotions, at least).
...

(For efficiency's sake, some of these functions might
also be implemented with masking macros.)

Comments?
Yes, I think those would be a good idea too. :-)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Oct 5 '07 #96
[snip nonsense]

You can't contribute anything to this discussion, then, you
try to destroy it.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Oct 5 '07 #97
Nick Keighley wrote:
bad analogy. In transistor count (ie. functionality) ICs are
getting bigger. Much bigger. That's one reason there are so few
CPU designs out there. Designing a modern IC is expensive.
It's not clear that that is a significant factor. The tools for
designing CPUs are much better also. There are still several
distinct CPU "designs" (by which I assume you mean ISAs), but
there is also no compelling reason to come up with a different
binary-incompatible design just for the sake of being different.
Being able to more or less painlessly replace existing older
parts is a significant economic advantage.
Oct 5 '07 #98
In article <1191595375.510864@news1nwk>,
Eric Sosman <Er*********@Sun.COMwrote:
Hmmm... Given the somewhat contentious tone of
the C discussion groups, even that might be too
controversial. It might be more prudent to begin
with an API for manipulating int values, like

int IntAdd(int x, int y);
int IntSubtract(int x, int y);
int IntMultiply(int x, int y);
int IntDivide(int x, int y);
If we're going to design an API around such things, we should have
provision for detecting underflow and overflow; we also need to
consider what layer we would want potential "saturate on overflow"
to be handled.
> int IntShiftLeft(int x, int bits);
int IntShiftRight(int x, int bits);
Unless you wish to handle negative bit counts, the bits
parameter should be unsigned.
> int IntUnaryPlus(int x);
Behaviour on -0 ?

--
So you found your solution
What will be your last contribution?
-- Supertramp (Fool's Overture)
Oct 5 '07 #99
In article <47***********************@news.orange.fr>,
jacob navia <ja***@nospam.orgwrote:
>[snip nonsense]
>You can't contribute anything to this discussion, then, you
try to destroy it.
It wasn't nonsense -- it was merely the equivilent of
"stretching exercises" before getting down to the hard work.

--
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth
Oct 5 '07 #100

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

Similar topics

7
by: sbobrows | last post by:
{Whilst I think much of this is OT for this newsgroup, I think the issue of understanding diagnostics just about gets under the door. -mod} Hi, I'm a C++ newbie trying to use the Boost regex...
1
by: Hardy | last post by:
Hi, just come into the boost world. just the first.cpp in the program_options examples, with many link error... devc++4.9.9.2, gcc 3.4.2, can I get your opinions on this problem? thank you~ ...
1
by: å¼ æ²ˆé¹ | last post by:
How to compile the HelloWorld of boost.asio? Maybe this is a stupid problem , but I really don't konw how to find the right way. My compile environment is WinXP, Msys , MinGw , G++ 3.4.2,...
1
by: Max Wilson | last post by:
Hi, Has anyone here built Boost.Python modules under MinGW? I'm trying to build the Boost.Python tutorial under MinGW and getting an error that says it depends on MSVC, which puzzles me because...
11
by: Osiris | last post by:
I have these pieces of C-code (NOT C++ !!) I want to call from Python. I found Boost. I have MS Visual Studio 2005 with C++. is this the idea: I write the following C source file:...
1
by: =?UTF-8?B?SmVucyBNw7xsbGVy?= | last post by:
(I also posted this to boost-user) The BGL implementation of breadth-first search uses a dedicated color map. I had the following idea: Some algorithms don't need to distinguish black/gray,...
1
by: Noah Roberts | last post by:
Trying to use boost::function in a C++/CLI program. Here is code: pragma once #include <boost/function.hpp> #include <boost/shared_ptr.hpp> #include <vector> using namespace System;
4
by: Man4ish | last post by:
namespace ve/////////////////ve.h { struct VertexProperties { std::size_t index; boost::default_color_type color; }; }...
2
by: Man4ish | last post by:
I have created Graph object without vertex and edge property.It is working fine. #include <boost/config.hpp> #include <iostream> #include <vector> #include <string> #include...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
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...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you

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.