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

when to use C and when to use C++

Hi everyone,

I have been asked this question quite a few times and i wonder what
could the actual reason?

" When to prefer C over C++ or vice versa, of course this is for real
world pratical scenario"

As per my understanding, C++ makes it easier to program application
related logic as OOPS helps in that sense, but for some reason that is
not a reasonable explanation, could any one add on their comments?

Nov 13 '06
102 3297
jacob navia said:

<snip>
All this would be unnecessary if I could declare:

int fn(int array[253]);

and have the expected semantics.
For those who have read K&R2, the expected semantics is "pointer to an int"
- and that's exactly what you get.

--
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.
Nov 14 '06 #51
Richard Heathfield wrote:
jacob navia said:

<snip>

>>All this would be unnecessary if I could declare:

int fn(int array[253]);

and have the expected semantics.


For those who have read K&R2, the expected semantics is "pointer to an int"
- and that's exactly what you get.
The expected semantics are that sizeof(array) is 253*sizeof(int).
Obviously C has a different opinion about this, what I find is a
big problem for the language. Arrays are not first class objects.
Nov 14 '06 #52
jacob navia:
The expected semantics are that sizeof(array) is 253*sizeof(int).
Obviously C has a different opinion about this, what I find is a
big problem for the language. Arrays are not first class objects.

Let's say that there's a country called Malingua. In Malingua, they
manufacture cars. These cars are just like the cars we have all over the
world, except that their accelerator and break pedals are switched.

What are the expected semantics of pressing the left pedal? Well that depends
entirely on how ignorant you are. There's the correct answer, and then
there's the incorrect answer which you hold to be true on account of your
ignorance.

To say, in this context, that the expected semantics for "sizeof array" is to
be equal to "253*sizeof(int)", is an expectation whose foundation is
ignorance.

Now, since _when_ can we make arguments based upon ignorance? Applying sizeof
to a pointer type yields the size of the pointer. Applying sizeof to an array
type yields the size of the array. If you don't like it, then tough -- but
don't use ignorance as an excuse to imply fault in the C programming
language.

--

Frederick Gotham
Nov 14 '06 #53
Frederick Gotham wrote:
jacob navia:

>>The expected semantics are that sizeof(array) is 253*sizeof(int).
Obviously C has a different opinion about this, what I find is a
big problem for the language. Arrays are not first class objects.

Let's say that there's a country called Malingua. In Malingua, they
manufacture cars. These cars are just like the cars we have all over the
world, except that their accelerator and break pedals are switched.

What are the expected semantics of pressing the left pedal? Well that depends
entirely on how ignorant you are. There's the correct answer, and then
there's the incorrect answer which you hold to be true on account of your
ignorance.

To say, in this context, that the expected semantics for "sizeof array" is to
be equal to "253*sizeof(int)", is an expectation whose foundation is
ignorance.

Now, since _when_ can we make arguments based upon ignorance? Applying sizeof
to a pointer type yields the size of the pointer. Applying sizeof to an array
type yields the size of the array. If you don't like it, then tough -- but
don't use ignorance as an excuse to imply fault in the C programming
language.
This is obvious. If I do not like some feature of the language, I am
an ignorant since I should know that "C is like that".

OK.

Be it
Nov 14 '06 #54
Frederick Gotham wrote:
jacob navia:
>The expected semantics are that sizeof(array) is 253*sizeof(int).
Obviously C has a different opinion about this, what I find is a
big problem for the language. Arrays are not first class objects.


Let's say that there's a country called Malingua. In Malingua, they
manufacture cars. These cars are just like the cars we have all over the
world, except that their accelerator and break pedals are switched.

What are the expected semantics of pressing the left pedal? Well that depends
entirely on how ignorant you are. There's the correct answer, and then
there's the incorrect answer which you hold to be true on account of your
ignorance.

To say, in this context, that the expected semantics for "sizeof array" is to
be equal to "253*sizeof(int)", is an expectation whose foundation is
ignorance.

Now, since _when_ can we make arguments based upon ignorance? Applying sizeof
to a pointer type yields the size of the pointer. Applying sizeof to an array
type yields the size of the array. If you don't like it, then tough -- but
don't use ignorance as an excuse to imply fault in the C programming
language.
No, let's go one step further. In Malingua, they have objects which
outwardly resemble cars. However, if you get into one, you find out that
they're actually showers. You can't drive them; they just happen to have
car-shaped enclosures.

If you're surprised by this, don't be: it's your own fault for assuming that
things that look like cars in Malingua are cars. If you don't like it, then
tough -- but don't use ignorance as an excuse to imply fault in Malingua's
culture.

Your point (that the semantics of a language are dictated, and match our
expectations only when they happen to do so) is well taken. It is, however,
disingenuous to pretend that therefore, a language can be designed in
whatever way we please and no-one can fault it for having syntax or
semantics that mislead a programmer's casual instincts. Whether you agree
with the criticism is one thing, but simply dismissing it as invalid is silly.

If programming were just a programmer reading the language standard and
henceforth magicking programs out of the void with the assimilated
knowledge, there would be no need to evaluate language design decisions.
However, it's not.

S.
Nov 14 '06 #55
On Tue, 14 Nov 2006 00:18:14 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>Frederick Gotham wrote:
>int array[5];

That is an array only in very special situations... In most cases it
will "decay" into a pointer to int.
Actually the wrong way round. Its a pointer in very special
situations, vis when you pass it as an argument to a function.
>The size information is destroyed
or discarded and there it goes, a buffer overflow please...
The overflow or otherwise is a flaw of programme design and/or coding
mistake. Other languages also allow equally stupid programming
mistakes. If this were not so, then surely they'd have taken over the
world already.

--
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
Nov 14 '06 #56
On Tue, 14 Nov 2006 18:32:32 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>Richard Bos a écrit :
>>
...is not at all the same as this, which is a function declaration which
includes a _pointer_ _argument_ which only looks like an array.
int array[5]: the size information is destroyed or discarded...
You fundamentally misunderstand whats going on here. Naturally, if you
convert it to something else, its not what it was any more.
>Yeah, looks like an array, feel like an array, but it is not an array.
In what way is int array[8] not an array?
--
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
Nov 14 '06 #57
On Tue, 14 Nov 2006 00:25:26 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>Mark McIntyre wrote:
>On Mon, 13 Nov 2006 09:55:55 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

What a logic. This is 100% McIntyre:
When will you realise that insulting the regulars and being a dickhead
is not going to impress anyone? You behave like a teenager on a
hormone trip trying desperately to drink and pull simultaneously, and
rarely has a sigblock been more appropriate.

--
Mark McIntyre

"The lusers I know are so clueless, that if they were dipped in clue
musk and dropped in the middle of pack of horny clues, on clue prom
night during clue happy hour, they still couldn't get a clue."
--Michael Girdwood, in the monastery
Nov 14 '06 #58
Skarmander:
No, let's go one step further. In Malingua, they have objects which
outwardly resemble cars. However, if you get into one, you find out that
they're actually showers. You can't drive them; they just happen to have
car-shaped enclosures.

OK, I'm with you so far...

If you're surprised by this, don't be: it's your own fault for assuming
that things that look like cars in Malingua are cars. If you don't like
it, then tough -- but don't use ignorance as an excuse to imply fault in
Malingua's culture.

Indeed, as a Westerner, I might find it quite strange that Malingua's
showers look like cars.

What can I do about it? Well, before travelling to Malingua, I can say,
"OK, I going to disregard everything I learned in Ireland, and I'm going to
start afresh in Malingua without making any presumptions as to how things
work."

Is this a viable choice? No, not when talking about going to a different
country.

However, we're talking about a programming language. When you're learning a
new programming language, you can't really build on past experience. You
need to confirm and clarify everything.

The simple fact of the matter is that you have to be in the know when it
comes to a programming language. Some people may presume that you can pass
an array by value, but alas they're wrong. Was their intuition flawed to
think they could simply write:

void Func(int arr[5]) {}

Maybe, maybe not. At the end of the day though, the C Standard is the C
Standard. You can either come to terms with the fact (however much you
dislike it) that Malingua's showers look like cars, or you can rant on
about how backwards Malingua is.

This reminds me of the argument posed recently whereby the following was
deemed to be bad style:

SomeAggregateType obj = {0};

in place of:

SomeAggregateType obj;
memset(&obj,0,sizeof obj);

(Let's forget for the moment that the latter form is only guaranteed to
work with integer types.)

The argument posed was that the former form wasn't explicit enough, i.e.
that the programmer wasn't expected to know that all the members/elements
would be default-initialised.

This, in my own humble opinion, is BS. The semantics of the former form are
perfectly well defined by the Standard, and that's good enough for me. One
shouldn't censor one's code because they think a particular feature might
be a little too advanced for some people.

The only compromise I would accept is the following:

SomeAggregateType obj = {0}; /* Everything ges default value */

I find it quite odd that a programmer would choose a flawed construct over
a simple comment. We have comments, use them if you like.

Your point (that the semantics of a language are dictated, and match our
expectations only when they happen to do so) is well taken. It is,
however, disingenuous to pretend that therefore, a language can be
designed in whatever way we please and no-one can fault it for having
syntax or semantics that mislead a programmer's casual instincts.

Yes, we can agree (slightly) on this one. Maybe C should have disallowed
the following:

void Func(int arr[5]) {}

Whether you agree with the criticism is one thing, but simply dismissing
it as invalid is silly.

It is the implication of a flaw in C that I was dismissing.

If programming were just a programmer reading the language standard and
henceforth magicking programs out of the void with the assimilated
knowledge, there would be no need to evaluate language design decisions.
However, it's not.

Oh but a boy can dream...

--

Frederick Gotham
Nov 14 '06 #59
Mark McIntyre:

<snip tripe>

While I disagree with quite a few of the points Jacob makes, I still think he
comes across as a nice, reasonable person. I've nothing bad to say about him.

I cannot the same for you.

--

Frederick Gotham
Nov 14 '06 #60
Mark McIntyre:
In what way is int array[8] not an array?
In the following context:

void Func(int array[8])
{
sizeof array;
}

int main(void) { return 0; }

--

Frederick Gotham
Nov 14 '06 #61
jacob navia said:
Richard Heathfield wrote:
>jacob navia said:

<snip>

>>>All this would be unnecessary if I could declare:

int fn(int array[253]);

and have the expected semantics.


For those who have read K&R2, the expected semantics is "pointer to an
int" - and that's exactly what you get.

The expected semantics are that sizeof(array) is 253*sizeof(int).
Not to anyone who has read K&R2 or any decent C reference book, nor to
anyone sufficiently competent in C to write or maintain a C compiler
properly. Presumably that includes you.

--
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.
Nov 14 '06 #62
Richard Heathfield:
Not to anyone who has read K&R2 or any decent C reference book, nor to
anyone sufficiently competent in C to write or maintain a C compiler
properly. Presumably that includes you.

Seeing as how Jacob is fully aware that an array cannot be passed by value,
I think he is arguing that C should be more intuitive, i.e. that you should
be able to figure stuff out by yourself without having to consult a book.
It's debateable how far this view can be taken.

The following snippet a load of cod's wallop in my opinion; I don't know
why C ever allowed the presence of the redundant array dimension in there:

void Func(int array[8]) {}

It looks, sounds, smells like an array, but it's a pointer. At least with
the following snippet, you know things aren't quite straight-forward:

void Func(int array[]) {}

, but again, it's debateable as to whether array syntax should have been
allowed at all. I myself always opt for the pointer syntax, i.e.:

void Func(char **p) {}

instead of:

void Func(char *p[]) {}

It's more honest in my opinion.

--

Frederick Gotham
Nov 14 '06 #63
jacob navia <ja***@jacob.remcomp.frwrites:
Richard Heathfield wrote:
>jacob navia said:
<snip>
>>>All this would be unnecessary if I could declare:

int fn(int array[253]);

and have the expected semantics.
For those who have read K&R2, the expected semantics is "pointer to
an int" - and that's exactly what you get.

The expected semantics are that sizeof(array) is 253*sizeof(int).
No, the *expected* semantics are that sizeof array == sizeof(int*), at
least to anyone who understands that particular aspect of the C
language. I would certainly expect anyone who works on a C compiler
to understand that, and I'm sure you do. I think that rather than
"expected semantics", you really mean "desired semantics", i.e., the
semantics that *you* want.
Obviously C has a different opinion about this, what I find is a
big problem for the language. Arrays are not first class objects.
This is not a matter of opinion, it's a matter of definition.

I'm not sure what "first class objects" are, but I certainly agree
that array types are not first class types in C. That's just the way
it is.

The fact that "int array[235]" in a parameter declaration really means
"int *array" is, in my opinion, an annoyance. The fact that the 235
is silently ignored is particularly counterintuitive. I dislike this
particular feature of C. Having said that, I move on and deal with
the language as it is, and I rarely use that particular feature (I'd
just declare the parameter as "int *array").

If your point is that C is imperfect, I don't think anyone is going to
disagree with you. If your point is that this particular imperfection
makes the language useless, this is refuted by the fact that plenty of
people actually use it.

It would be nice if array types were more nearly first-class in C, but
I don't believe it's possible to make that happen without breaking
existing code. If you can manage to design such a language change,
I'll be very impressed.

If you want first-class arrays, use a different language, and discuss
it in a different newsgroup.

--
Keith Thompson (The_Other_Keith) 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.
Nov 14 '06 #64
jacob navia <ja***@jacob.remcomp.frwrites:
Frederick Gotham wrote:
[...]
>To say, in this context, that the expected semantics for "sizeof
array" is to be equal to "253*sizeof(int)", is an expectation whose
foundation is ignorance.
Now, since _when_ can we make arguments based upon ignorance?
Applying sizeof to a pointer type yields the size of the
pointer. Applying sizeof to an array type yields the size of the
array. If you don't like it, then tough -- but don't use ignorance
as an excuse to imply fault in the C programming language.

This is obvious. If I do not like some feature of the language, I am
an ignorant since I should know that "C is like that".
jacob, please make up your mind about what you're trying to say.

If you do not like some feature of the language, that's perfectly
fine. I don't like that particular feature myself.

Context: we're talking about a parameter declaration, something like:

void func(int array[253]);

The phrase "expected semantics" implies, at least to me and I think to
most of us, that you *expect* "sizeof array", evaluated inside func,
to yield 253*sizeof(int). It doesn't, and the standard is perfectly
clear on that point. I'm sure your own lcc-win32 handles this in
accordance with the C standard.

If you're trying to say that you'd *prefer* "sizeof array" to yield
253*sizeof(int), that's perfectly reasonable, but it's not what you've
been saying. The word "expected" implies a belief about what the
expression actually does yield, not a desire for it to behave
differently than it really does.

I wonder if this is partly a language problem (French vs. English).

--
Keith Thompson (The_Other_Keith) 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.
Nov 14 '06 #65
Keith Thompson wrote:
jacob navia <ja***@jacob.remcomp.frwrites:
>>Frederick Gotham wrote:

[...]
>>>To say, in this context, that the expected semantics for "sizeof
array" is to be equal to "253*sizeof(int)", is an expectation whose
foundation is ignorance.
Now, since _when_ can we make arguments based upon ignorance?
Applying sizeof to a pointer type yields the size of the
pointer. Applying sizeof to an array type yields the size of the
array. If you don't like it, then tough -- but don't use ignorance
as an excuse to imply fault in the C programming language.

This is obvious. If I do not like some feature of the language, I am
an ignorant since I should know that "C is like that".


jacob, please make up your mind about what you're trying to say.

If you do not like some feature of the language, that's perfectly
fine. I don't like that particular feature myself.

Context: we're talking about a parameter declaration, something like:

void func(int array[253]);

The phrase "expected semantics" implies, at least to me and I think to
most of us, that you *expect* "sizeof array", evaluated inside func,
to yield 253*sizeof(int). It doesn't, and the standard is perfectly
clear on that point. I'm sure your own lcc-win32 handles this in
accordance with the C standard.

If you're trying to say that you'd *prefer* "sizeof array" to yield
253*sizeof(int), that's perfectly reasonable, but it's not what you've
been saying. The word "expected" implies a belief about what the
expression actually does yield, not a desire for it to behave
differently than it really does.

I wonder if this is partly a language problem (French vs. English).
Yes, I meant obviously that it should be 253*sizeof(int)...

I KNOW that the standard says otherwise and I have implemented it like
that and I have used it like that for the 20+ years I have been
programming in C, but still, after all this time, I think it is
a mistake. Arrays should KEEP its size information so that it can
be checked at run-time, and sizeof() should be a run-time function
that returns the stored size...

BUT

It would mean quite a lot of changes to the language.
Nov 14 '06 #66
Mark McIntyre <ma**********@spamcop.netwrites:
On Tue, 14 Nov 2006 00:18:14 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>>Frederick Gotham wrote:
>>int array[5];

That is an array only in very special situations... In most cases it
will "decay" into a pointer to int.

Actually the wrong way round. Its a pointer in very special
situations, vis when you pass it as an argument to a function.
[...]

The implicit conversion of an array expression to a pointer value has
nothing to do with function arguments. A function argument merely
happens to be one of the many contexts in which the conversion take
place. For example, given:

void func(int *p);
int foo[10];
...

func(foo);

the expression "foo" is converted to a pointer value, but *not*
because it's being passed to a function.

There are two rules to remember:

1. An expression of array type is implicitly converted to a pointer to
the array's first element *unless* the expression is the operand of
a unary "&" or "sizeof" operator, or is a string literal used to
initialize an array. (C99 6.3.2.1p3).

2. A parameter declaration of an array type is adjusted to a pointer
type. This is not a conversion; in a parameter declaration,
"int array[5]" really *means* "int *array". (C99 6.7.5.3p7)

If you look at the history of the language, these two rules exist for
similar reasons, but they're really completely independent of each
other; neither follows from the other.

People often try to re-state these rules in other terms. The result
is almost always either needlessly complex or needlessly imprecise.

--
Keith Thompson (The_Other_Keith) 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.
Nov 14 '06 #67
Frederick Gotham wrote:
Mark McIntyre:

>>In what way is int array[8] not an array?


In the following context:

void Func(int array[8])
{
sizeof array;
}

int main(void) { return 0; }
Yes, that's precisely my point.

Arrays become just pointers, and any size information
must be passed to the function in an extra parameter
by the programmer, with all the associated error possibilities.

jacob
Nov 14 '06 #68
Mark McIntyre wrote:
>Martin Ambuhl a écrit :
>>Usually the reason for the question is that some asshole wants to
start a flame war.
Well, at least you guys have managed to start a flame war about flame wars.

--
Martijn
http://www.sereneconcepts.nl
http://blogger.xs4all.nl/mihaak/
Nov 14 '06 #69
Martijn wrote:
Mark McIntyre wrote:
>>>Martin Ambuhl a écrit :

Usually the reason for the question is that some asshole wants to
start a flame war.


Well, at least you guys have managed to start a flame war about flame wars.
!!!!!!!!!!!!!!!!!!!

:-)
Nov 14 '06 #70
Frederick Gotham wrote:
Skarmander:
>No, let's go one step further. In Malingua, they have objects which
outwardly resemble cars. However, if you get into one, you find out that
they're actually showers. You can't drive them; they just happen to have
car-shaped enclosures.


OK, I'm with you so far...

>If you're surprised by this, don't be: it's your own fault for assuming
that things that look like cars in Malingua are cars. If you don't like
it, then tough -- but don't use ignorance as an excuse to imply fault in
Malingua's culture.


Indeed, as a Westerner, I might find it quite strange that Malingua's
showers look like cars.
But here, of course, the analogy breaks down readily: Malingua, as we
presume it to exist, isn't man-made, and isn't meant to serve a purpose. And
even then, Malinguans familiar with cars may concede that it doesn't make a
whole lot of sense to them either.
What can I do about it? Well, before travelling to Malingua, I can say,
"OK, I going to disregard everything I learned in Ireland, and I'm going to
start afresh in Malingua without making any presumptions as to how things
work."
That is humanly impossible. Only computers can work without presumptions,
and that only because they cannot presume in the first place.
Is this a viable choice? No, not when talking about going to a different
country.
OK, I'm with you so far. :-)
However, we're talking about a programming language. When you're learning a
new programming language, you can't really build on past experience. You
need to confirm and clarify everything.
Says who? The language? No. So what, then? Experience? Sure. Experience
tells us we cannot rely on our previous experience, but you see how that
only goes so far.

If I read

c = a + b;

it is not possible and not helpful for me to pretend that these are
meaningless symbols barring an explicit definition in a language standard
somewhere that will explain to me what exactly this sequence of symbols
means, if anything.

For sure, the language standard *is* the only authority on it. I cannot
*rely* on my assumptions about the statement's semantics, and a good many
may be wrong. I cannot with any definite justification shout "that's wrong"
if it shouldn't match my expectation. However, if "c = a + b;" turned out to
mean "perform a low-level format of all attached disk drives", I would have
reason to complain nonetheless, however formally precise and consistent the
definition might be.
The simple fact of the matter is that you have to be in the know when it
comes to a programming language. Some people may presume that you can pass
an array by value, but alas they're wrong. Was their intuition flawed to
think they could simply write:

void Func(int arr[5]) {}

Maybe, maybe not.
As long as we're willing to concede the possibility, that's enough. It's not
a black and white issue, and that's my point. "It's standard C so there's no
point criticizing it for what it isn't" is a reasonable attitude for writing
programs (indeed, the only reasonable attitude), but not when the point
precisely is criticism of C's design.

Is the intuition flawed? Consider this: in C, everything that can be passed
is passed by value, but arrays cannot be passed as values. This is not
reflected in the most intuitive attempt at doing it, since that is not an
error, but instead implements quite different semantics.

There are two separate issues here. First, should C have included passing
arrays by value? There are obvious and understandable reasons why it does
not (though whether they are sufficiently good reasons is a completely
different matter, which I will not go into here). Second, since C does not
include passing arrays by value, should it have included the syntax form
that it does, with the semantics that has? The latter decision is much
harder to defend.
At the end of the day though, the C Standard is the C
Standard. You can either come to terms with the fact (however much you
dislike it) that Malingua's showers look like cars, or you can rant on
about how backwards Malingua is.
Or, indeed, you can do both. Nobody said coming to terms meant keeping your
peace hereafter. What would become of activism? :-)
This reminds me of the argument posed recently whereby the following was
deemed to be bad style:
Style is a lot murkier than even intuition.
SomeAggregateType obj = {0};

in place of:

SomeAggregateType obj;
memset(&obj,0,sizeof obj);

(Let's forget for the moment that the latter form is only guaranteed to
work with integer types.)

The argument posed was that the former form wasn't explicit enough, i.e.
that the programmer wasn't expected to know that all the members/elements
would be default-initialised.

This, in my own humble opinion, is BS. The semantics of the former form are
perfectly well defined by the Standard, and that's good enough for me. One
shouldn't censor one's code because they think a particular feature might
be a little too advanced for some people.
There are no clear insights on how intuition works, so these matters remain
thoroughly debatable. However, in my opinion, this is still quite a bit
removed from the opinion that it's counterintuitive that

void func(int arr[5]) {
...

does not declare 'arr' to be a parameter of type "array of five ints", and
that indeed what looks like a dimension is actually meaningless.

Both these things rely on intuition, and both can be chalked up to
inappropriate extrapolation: you thought it meant one thing based on what
you saw earlier, but you were wrong. How obviously jarring you might find
either is subjective, of course, but I do think most people would agree that
confusion about passing arrays is more "natural" than confusion about struct
initializers.
>Whether you agree with the criticism is one thing, but simply dismissing
it as invalid is silly.

It is the implication of a flaw in C that I was dismissing.
It *is* a flaw in C. The syntax is confusing, and pointlessly so. The
language would be better if it did not include this particular syntax form
at all, and if array parameters looked as what they are: pointers.

Of course, the question of whether arrays should be first-class citizens
instead (which would be an alternate way of solving the problem) is a whole
'nother bag of beans, as it involves a lot more arguments and being a lot
more explicit about design goals.

And, obviously, now that the language is what it is there is no sense in
arguing that it should be different, as the mass of existing code is now a
very strong argument against. But then, that's not the argument in question
either.

S.
Nov 14 '06 #71
jacob navia:
Arrays become just pointers, and any size information
must be passed to the function in an extra parameter
by the programmer, with all the associated error possibilities.

While I agree with the meaning, I don't agree with your language. An array
doesn't "just become" a pointer any more than a double "just becomes" an int.
It's an implicit conversion.

--

Frederick Gotham
Nov 14 '06 #72
jacob navia:
It would mean quite a lot of changes to the language.

And we'd probably end up with something like C++...

--

Frederick Gotham
Nov 14 '06 #73
Frederick Gotham <fg*******@SPAM.comwrites:
jacob navia:
>It would mean quite a lot of changes to the language.


And we'd probably end up with something like C++...
C++ has the same array/pointer conversion rules as C (though it also
has STL vectors and so forth).

--
Keith Thompson (The_Other_Keith) 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.
Nov 14 '06 #74
jacob navia wrote:
Frederick Gotham wrote:
>Mark McIntyre:
>>>In what way is int array[8] not an array?

In the following context:

void Func(int array[8])
{
sizeof array;
}

int main(void) { return 0; }

Yes, that's precisely my point.

Arrays become just pointers, and any size information
must be passed to the function in an extra parameter
by the programmer, with all the associated error possibilities.
Not necessarily. You can always create a completely passable array
by embedding it in a struct. In fact, by using the "struct hack"
or C99 open arrays you can even make those variable length.

typedef struct vlgharr {
size_t maxsize;
char arrproper[1];
} vlgharr, *pvlgharr;

pvlgharr vlacreate(size_t sz) {
pvlgharr pv;
size_t needed;

if (!sz) return NULL;
needed = offsetof(arrproper, vlgharr) + sz;
if (pv = malloc(needed)) pv->maxsize = sz;
return pv;
} /* untested */

and you can now pass either pv or *pv as function parameters. You
should probably create a corresponding "vladestroy(pvlgharr pv);"
function.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
Nov 14 '06 #75
Skarmander wrote:
>
.... snip ...
>
It *is* a flaw in C. The syntax is confusing, and pointlessly so. The
language would be better if it did not include this particular syntax
form at all, and if array parameters looked as what they are: pointers.
So all you have to do is write your function prototypes to specify
pointers, rather than the confusing array format. It's your own
fault.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

Nov 14 '06 #76
CBFalconer <cb********@yahoo.comwrites:
jacob navia wrote:
>Frederick Gotham wrote:
>>Mark McIntyre:

In what way is int array[8] not an array?

In the following context:

void Func(int array[8])
{
sizeof array;
}

int main(void) { return 0; }

Yes, that's precisely my point.

Arrays become just pointers, and any size information
must be passed to the function in an extra parameter
by the programmer, with all the associated error possibilities.

Not necessarily. You can always create a completely passable array
by embedding it in a struct. In fact, by using the "struct hack"
or C99 open arrays you can even make those variable length.

typedef struct vlgharr {
size_t maxsize;
char arrproper[1];
} vlgharr, *pvlgharr;

pvlgharr vlacreate(size_t sz) {
pvlgharr pv;
size_t needed;

if (!sz) return NULL;
needed = offsetof(arrproper, vlgharr) + sz;
if (pv = malloc(needed)) pv->maxsize = sz;
return pv;
} /* untested */

and you can now pass either pv or *pv as function parameters. You
should probably create a corresponding "vladestroy(pvlgharr pv);"
function.
Well I am sure I'll shot down in flames, but that really surprises
me. Passing pv, OK (setting aside the legality of the hack in the
first place) but I can't see how most implementations have a hope of
passing *pv correctly.

C99 regularised this by giving the implementation a way to know the
object's size.

--
Ben.
Nov 14 '06 #77
2006-11-14 <45***************@yahoo.com>,
CBFalconer wrote:
jacob navia wrote:
>Frederick Gotham wrote:
>>Mark McIntyre:

In what way is int array[8] not an array?

In the following context:

void Func(int array[8])
{
sizeof array;
}

int main(void) { return 0; }

Yes, that's precisely my point.

Arrays become just pointers, and any size information
must be passed to the function in an extra parameter
by the programmer, with all the associated error possibilities.

Not necessarily. You can always create a completely passable array
by embedding it in a struct. In fact, by using the "struct hack"
or C99 open arrays you can even make those variable length.
Doing this precludes passing the "whole" struct by value. You can only
pass up to the single element that is actually declared for arrproper[],
and possibly by accident a bit extra that's present as padding.

I have no idea what "variably modified types" are or whether they are
useful for getting around this.

I have no idea what happens if you pass a struct with a flexible array
member in c99. probably an error message.
Nov 14 '06 #78
Frederick Gotham said:

<snip>
it's debateable as to whether array syntax should have been
allowed at all.
As a matter of fact, I agree with you (with regard to function parameters) -
but it's historical baggage from the days when [] actually /did/ mean
"pointer", and historical baggage tends to decay into tradition.

--
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.
Nov 15 '06 #79
Frederick Gotham said:
jacob navia:
>It would mean quite a lot of changes to the language.


And we'd probably end up with something like C++...
....and we already have C++, if we want it. It's over there somewhere. So
there's no need to change C to be like it. Otherwise we'd have two C++s,
which would be silly.

--
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.
Nov 15 '06 #80
In article <11**********************@k70g2000cwa.googlegroups .com>,
sa*****@yahoo.co.in writes
>Hi everyone,

I have been asked this question quite a few times and i wonder what
could the actual reason?

" When to prefer C over C++ or vice versa, of course this is for real
world pratical scenario"

As per my understanding, C++ makes it easier to program application
related logic as OOPS helps in that sense, but for some reason that is
not a reasonable explanation, could any one add on their comments?
Some preamble...
Many regard C as a sub set of C++ this is not correct. C and C++
diverged in 1990. Therefore they are subtly different in some places
even where the syntax is the same.

C++ has a whole load of features not available in C. Many of which take
up a lot of space and time but are seen as "essentia" by some

C++ is not available on many platforms. This is practically speaking.

C can be written in a tight modular from that in many ways is object
orientated not that the OO purists will admit it.

It is perceived that C is faster and more compact than C++. This is
generally true though with discipline C++ can be as compact and fast as
C. You just have to know which features *not* to use.

Therefore C tends to be used on the smaller micros the 8 and 16 bit
types which make up the majority of MCU in the world by a long way.
(Partly because there is no C++ support for them)

Traditionally on larger systems C gets used for all the device drivers
and low level stuff including the RTOS. C++ tends to get used for the
application.

These days a lot of it comes down to the compilers (and debug tools)
available for your target platform and experience.

As I have a lot more C experience than C++ I tend to grab the C compiler
first in embedded systems. . On a PC I would tend to use the C++
compiler.

Others will use C++ for every thing because it is what they know and it
is "modern" compared to C. .

C is not going to die out as it is widely used in the embedded world and
will remain so for years to come.

C++ on the other hand is being subverted by C# and C++/CLI (by MS) and
also to some extent by Java. So C++ as we know it could morph into
something else in about 4-5 years. .

OS there you are.... as clear as mud :-)

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Nov 15 '06 #81
CBFalconer wrote:
Skarmander wrote:
... snip ...
>It *is* a flaw in C. The syntax is confusing, and pointlessly so. The
language would be better if it did not include this particular syntax
form at all, and if array parameters looked as what they are: pointers.

So all you have to do is write your function prototypes to specify
pointers, rather than the confusing array format. It's your own
fault.
You're suggesting that people not use the confusing syntax in order not to
be confused by it?

Assuming everyone did this, it would be still be a flaw, because everyone
would be required to learn not to do something that ought to be impossible.

S.
Nov 15 '06 #82

sa*****@yahoo.co.in wrote:
Hi everyone,

I have been asked this question quite a few times and i wonder what
could the actual reason?

" When to prefer C over C++ or vice versa, of course this is for real
world pratical scenario"

As per my understanding, C++ makes it easier to program application
related logic as OOPS helps in that sense, but for some reason that is
not a reasonable explanation, could any one add on their comments?
You have to use C when you can, C++ when you have to, or the other way,
use C++ you have to, C when you can. :-)

Nov 16 '06 #83
jacob navia <ja***@jacob.remcomp.frwrote:
Richard Bos a écrit :
...is not at all the same as this, which is a function declaration which
includes a _pointer_ _argument_ which only looks like an array.

What was I saying?

int array[5]: the size information is destroyed or discarded...
No, that's not what you were saying. Look again:
>>>>int array[5];
void fn(int array[8])
Spot the fundamental difference?

Richard
Nov 16 '06 #84
jacob navia <ja***@jacob.remcomp.frwrote:
Frederick Gotham wrote:
Mark McIntyre:
>In what way is int array[8] not an array?
In the following context:

void Func(int array[8])
{
sizeof array;
}

int main(void) { return 0; }
Yes, that's precisely my point.

Arrays become just pointers,
No, they don't. In that context, there _is_ no array. There is a
notational oddity which _looks_ like an array. That's all.

Richard
Nov 16 '06 #85
Keith Thompson:
>And we'd probably end up with something like C++...

C++ has the same array/pointer conversion rules as C (though it also
has STL vectors and so forth).
<OT>

Yes, but we can have references to arrays, and we can pass an array by
reference.

void Func(int (&arr)[5]) {}

Or more exotically:

#include <cstddef>

void Func(int *p,std::size_t len) {}

template<std::size_t len>
void Func(int (&arr)[len]) { Func(arr,len); }

int main()
{
int arr[5];

Func(arr);
}

</OT>

--

Frederick Gotham
Nov 17 '06 #86
sa*****@yahoo.co.in wrote:
Hi everyone,

I have been asked this question quite a few times and i wonder what
could the actual reason?

" When to prefer C over C++ or vice versa, of course this is for real
world pratical scenario"

As per my understanding, C++ makes it easier to program application
related logic as OOPS helps in that sense, but for some reason that is
not a reasonable explanation, could any one add on their comments?
Hi!
The answer is pretty simple:
C is mainly used for low-level programming, - like operating systems, or
something like that - when it's simplicity is an advantage. C++ is used
for application programming.

Leslie Kis-Adam
<dfighter_AT_NOSPAM_freemail.hu>
Nov 17 '06 #87
On Fri, 17 Nov 2006 21:55:11 +0100, Leslie Kis-Adam
<df******@freemail.huwrote:
>sa*****@yahoo.co.in wrote:
>Hi everyone,

I have been asked this question quite a few times and i wonder what
could the actual reason?

" When to prefer C over C++ or vice versa, of course this is for real
world pratical scenario"

As per my understanding, C++ makes it easier to program application
related logic as OOPS helps in that sense, but for some reason that is
not a reasonable explanation, could any one add on their comments?

Hi!
The answer is pretty simple:
C is mainly used for low-level programming, - like operating systems, or
something like that - when it's simplicity is an advantage. C++ is used
for application programming.
Except, of course, for the many applications written in C.
--
Al Balmer
Sun City, AZ
Nov 17 '06 #88
Al Balmer wrote:
On Fri, 17 Nov 2006 21:55:11 +0100, Leslie Kis-Adam
<df******@freemail.huwrote:
sa*****@yahoo.co.in wrote:
Hi everyone,

I have been asked this question quite a few times and i wonder what
could the actual reason?

" When to prefer C over C++ or vice versa, of course this is for real
world pratical scenario"

As per my understanding, C++ makes it easier to program application
related logic as OOPS helps in that sense, but for some reason that is
not a reasonable explanation, could any one add on their comments?
Hi!
The answer is pretty simple:
C is mainly used for low-level programming, - like operating systems, or
something like that - when it's simplicity is an advantage. C++ is used
for application programming.
Except, of course, for the many applications written in C.
And the many operating systems written in C++, (offhand, L4, Windows NT
and Choices come to mind).

Nov 18 '06 #89
santosh wrote:
Al Balmer wrote:
>On Fri, 17 Nov 2006 21:55:11 +0100, Leslie Kis-Adam
<df******@freemail.huwrote:
>>sa*****@yahoo.co.in wrote:
Hi everyone,

I have been asked this question quite a few times and i wonder what
could the actual reason?

" When to prefer C over C++ or vice versa, of course this is for real
world pratical scenario"

As per my understanding, C++ makes it easier to program application
related logic as OOPS helps in that sense, but for some reason that is
not a reasonable explanation, could any one add on their comments?

Hi!
The answer is pretty simple:
C is mainly used for low-level programming, - like operating systems, or
something like that - when it's simplicity is an advantage. C++ is used
for application programming.
Except, of course, for the many applications written in C.

And the many operating systems written in C++, (offhand, L4, Windows NT
and Choices come to mind).
Of course you can write applications in C, my point was that C is the
most useful for system programming.
I guess Windows NT-s GUI was written in C++, but I'm not convinced, that
other parts were written with that.
Nov 18 '06 #90
Skarmander wrote:
Frederick Gotham wrote:
<snip>
>However, we're talking about a programming language. When you're
learning a new programming language, you can't really build on past
experience. You need to confirm and clarify everything.
Says who? The language? No. So what, then? Experience? Sure. Experience
tells us we cannot rely on our previous experience, but you see how that
only goes so far.

If I read

c = a + b;

it is not possible and not helpful for me to pretend that these are
meaningless symbols barring an explicit definition in a language
standard somewhere that will explain to me what exactly this sequence of
symbols means, if anything.

For sure, the language standard *is* the only authority on it. I cannot
*rely* on my assumptions about the statement's semantics, and a good
many may be wrong. I cannot with any definite justification shout
"that's wrong" if it shouldn't match my expectation. However, if "c = a
+ b;" turned out to mean "perform a low-level format of all attached
disk drives", I would have reason to complain nonetheless, however
formally precise and consistent the definition might be.
Actually, depending on your background and the language you use that
expression in you could be very surprised by the result. If your
experience is Pascal and saw it in a context where a condition is
expected you would think it was doing a comparison. If your experience
is C and you saw it in a Pascal program you would think it was doing an
assignment. If it is actually in C++ then with object overloading the +
operator or the = operator *could* (with appropriate system specific
extensions) perform a low level format of all attached disk drives!

So, even for such a simple example, you *still* have to learn the
language to know what it means, and sometimes learn the code base you
are working with as well!
>The simple fact of the matter is that you have to be in the know when
it comes to a programming language. Some people may presume that you
can pass an array by value, but alas they're wrong. Was their
intuition flawed to think they could simply write:

void Func(int arr[5]) {}

Maybe, maybe not.

As long as we're willing to concede the possibility, that's enough. It's
not a black and white issue, and that's my point. "It's standard C so
there's no point criticizing it for what it isn't" is a reasonable
attitude for writing programs (indeed, the only reasonable attitude),
but not when the point precisely is criticism of C's design.

Is the intuition flawed? Consider this: in C, everything that can be
passed is passed by value, but arrays cannot be passed as values. This
is not reflected in the most intuitive attempt at doing it, since that
is not an error, but instead implements quite different semantics.
<snip other related stuff about intuition since this is enough to show
the arguments going on>

My experience says you can't rely on your intuition because your
intuition is based on your experience and even a very simple expression
can mean drastically different things depending on the language and
surrounding code.

Having said that, I agree that C would be better if either you could not
use "int array[6]" as a parameter definition or if it really did mean
you were passing an array of 6 ints by value.
--
Flash Gordon
Nov 18 '06 #91
sa*****@yahoo.co.in wrote:
When [should I] prefer C over C++ or vice versa?
Of course, this is for real world practical scenario.
If there is really a choice, good programmers always choose C++.

In practice, programmers who use C do so because they have no choice.
They must maintain legacy C code, they don't have access
to a reliable C++ compiler for the target platform or
they just don't understand C++ well enough to write good C++ programs.

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Nov 18 '06 #92
"E. Robert Tisdale" <ed***@netwood.netwrites:
sa*****@yahoo.co.in wrote:
>When [should I] prefer C over C++ or vice versa?
Of course, this is for real world practical scenario.

If there is really a choice, good programmers always choose C++.

In practice, programmers who use C do so because they have no choice.
They must maintain legacy C code, they don't have access
to a reliable C++ compiler for the target platform or
they just don't understand C++ well enough to write good C++ programs.
That is manifestly untrue, but I'm not going to waste my time arguing
the point.

--
Keith Thompson (The_Other_Keith) 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.
Nov 18 '06 #93
"E. Robert Tisdale" wrote:
sa*****@yahoo.co.in wrote:
>When [should I] prefer C over C++ or vice versa?
Of course, this is for real world practical scenario.

If there is really a choice, good programmers always choose C++.
Trollsdale alert. It's baaack. Now we have to watch out for
altered quotations again, not to mention misinformation. Looks
like it got fired from JPL at last, which is progress.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
Nov 18 '06 #94
CBFalconer wrote:
"E. Robert Tisdale" wrote:
sa*****@yahoo.co.in wrote:
When [should I] prefer C over C++ or vice versa?
Of course, this is for real world practical scenario.
If there is really a choice, good programmers always choose C++.

Trollsdale alert. It's baaack. Now we have to watch out for
altered quotations again, not to mention misinformation. Looks
like it got fired from JPL at last, which is progress.
Would that be the "Jet propulsion laboratory" ? Whatever
it is how do you know he got fired ?

Nov 18 '06 #95
Spiros Bousbouras said:
CBFalconer wrote:
>Looks
like it got fired from JPL at last, which is progress.

Would that be the "Jet propulsion laboratory" ? Whatever
it is how do you know he got fired ?
That's what Jet Propulsion Laboratories *do* - fire things.
--
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.
Nov 18 '06 #96
In article <11*************@sp6iad.superfeed.net>, E. Robert Tisdale
<ed***@netwood.netwrites
>sa*****@yahoo.co.in wrote:
>When [should I] prefer C over C++ or vice versa?
Of course, this is for real world practical scenario.

If there is really a choice, good programmers always choose C++.
Absolute CRAP.
In fact I would say that if a programmer always chooses C++ if there is
a choice between c and C++ they are incompetent.
>In practice, programmers who use C do so because they have no choice.
Not true.
>They must maintain legacy C code, they don't have access
to a reliable C++ compiler for the target platform or
This is sometimes true. There are not C++ compilers for all the targets
that have C compilers.
>they just don't understand C++ well enough to write good C++ programs.
Also of course a lot of C++ programmers have no idea how to write good C
programs.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Nov 19 '06 #97
Leslie Kis-Adam <df******@freemail.huwrote:

[ Snip! ]
santosh wrote:
Al Balmer wrote:
On Fri, 17 Nov 2006 21:55:11 +0100, Leslie Kis-Adam

sa*****@yahoo.co.in wrote:
" When to prefer C over C++ or vice versa, of course this is for real
world pratical scenario"
>The answer is pretty simple:
C is mainly used for low-level programming, - like operating systems, or
something like that - when it's simplicity is an advantage. C++ is used
for application programming.

Except, of course, for the many applications written in C.
And the many operating systems written in C++, (offhand, L4, Windows NT
and Choices come to mind).
Of course you can write applications in C, my point was that C is the
most useful for system programming.
Yes, and that point was wrong. Many people write application programs in
C.
I guess Windows NT-s GUI was written in C++, but I'm not convinced, that
other parts were written with that.
Anyway, I'm not convinced that Windows NT is a valid counter-example
against anything involving operating systems.

Richard
Nov 20 '06 #98
Richard Bos wrote:
Leslie Kis-Adam <df******@freemail.huwrote:

[ Snip! ]
santosh wrote:
Al Balmer wrote:
>On Fri, 17 Nov 2006 21:55:11 +0100, Leslie Kis-Adam
>>
>>sa*****@yahoo.co.in wrote:
<snip>
>>The answer is pretty simple:
>>C is mainly used for low-level programming, - like operating systems, or
>>something like that - when it's simplicity is an advantage. C++ is used
>>for application programming.
>>>
>Except, of course, for the many applications written in C.
>
And the many operating systems written in C++, (offhand, L4, Windows NT
and Choices come to mind).
>
<snip>
I guess Windows NT-s GUI was written in C++, but I'm not convinced, that
other parts were written with that.

Anyway, I'm not convinced that Windows NT is a valid counter-example
against anything involving operating systems.
Both of you seem to have overlooked my first, and admittedly better,
example for an operating system kernel written in C++, namely L4.

Nov 20 '06 #99
On Sat, 18 Nov 2006 11:51:44 -0800, "E. Robert Tisdale"
<ed***@netwood.netwrote:
A standard Tisdale Troll, having changed his email address and
temporarily escaped my filter.

--
Al Balmer
Sun City, AZ
Nov 20 '06 #100

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

Similar topics

4
by: Nuno | last post by:
Is there any SQL Error? Or I have to use Select case in VB code to control SQL instead. Thank you for any ans. Nuno
13
by: elad | last post by:
Hi The Menu doesn't work properly when I have 2 frame and the Menu popup frame=document target frame, when I choose item in the menu the doc opened and the menu get stuck. Here is the code...
24
by: Steven T. Hatton | last post by:
In the following code, at what point is S::c fully defined? #include <iostream> using std::cout; using std::endl; using std::ostream; class C { int _v;
7
by: sql-db2-dba | last post by:
Does DB2 just fudge it when it is an empty table? Is there a "formula" for average row size when you have variable length records. Or you really have to know what your application is packing into...
7
by: Nicolae Fieraru | last post by:
Hi All, I am trying to change the rowsource of a combobox when I click on it. I played with many events, associated with the form and the combobox, but still haven't figured out what is the way...
4
by: Peter Row | last post by:
Hi, I have created a UserControl which is subsequently hosted on a standard form. My control has a TabControl on it but it has no TabPages configured. At runtime I create X pages and put a...
5
by: AAguiar | last post by:
I have an asp.net project where the code behind the aspx page calls a c# class which makes calls to a managed static C++ class. The C# class works fine when the asp net worker process starts, when...
8
by: Galina | last post by:
Hello I have 6 dependent list boxes on my ASP page:  Faculty;  Lecturer;  Course;  Course occurrence;  Group;  Week commencing date. When faculty is selected, lists of lecturers and...
44
by: Smokey Grindle | last post by:
I have a list box on my form, but I need to databind it to a data table that is a private member of the form's class... so I basically have Public Class MyForm priate m_MyTable as new datatable...
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...
0
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: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: 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: 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: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.