C/C++ question about dynamic "static struct"

[Ian Collins]

The language has grown SO complex that nobody knows ALL the subtleties
of it. Most programmers know a small subset that they use (30-40%), and
ignore the rest. Experts may know 60-70%, but nobody really understands
it ALL.

You never seem to get the point that there is nothing wrong with cherry
picking language features. A project team should agree which features
they want to use and stick with them until they are happy to embrace
more. Maybe they never will, that fine, the choice is theirs. At least
they are able to make a choice.

Even you recognise some of the benefits C++ can offer by including C++
like extensions to your compiler.

You may call be biased, but I was a C programmer for over a decade
before I learned C++ and two decades later I still work on C as well as
C++ projects. But I really miss some C++ features when I'm working in
C, RAII more than anything else. I guess its much the same as missing
the 1st class menu when flying economy!

 

[James Kuyper]

On 10/18/12 James Kuyper wrote:
[snip]

I'm primarily a C programmer, so I may be
missing out some elegant C++ way of doing that, but the following
inelegant (and untested) code should do the job:

[snip]

I'm intrigued. I have never ever met someone who described himself as a
C programmer. May I ask what kind of business you are in? My guess is
your line of work includes either device drivers, embedded devices,
kernel code or something else that forces you to write C instead of C++.

I don't work in any of the areas you listed. I'm a scientific computer
programmer. My programs process data sent down from instruments mounted
on satellites (mainly geolocation and calibration of images). They run
24-7 in a production environment with no user interaction; they just
read and write files. The production system itself is controlled by a
GUI which interacts with the operators, but my programs themselves do not.

In all these years I have never met someone who used C instead of C++
unless he was forced to do so.

Our contract with our client imposes requirements on our delivered code.
Among other things, the permitted languages are C95, Fortan 77, Fortran
90, or Ada. So that part you got right.

I recently started work on an additional project covered by a different
contract with fewer restrictions, and most of the code is in C++. I've
found my extensive knowledge about C++ more useful than I expected, and
my lack of C++ experience less of a problem than I'd feared.

 

[Rui Maciel]

Le 18/10/12 09:55, Stuart a écrit :

On 10/18/12 James Kuyper wrote:
[snip]

I'm primarily a C programmer, so I may be
missing out some elegant C++ way of doing that, but the following
inelegant (and untested) code should do the job:

[snip]

I'm intrigued. I have never ever met someone who described himself as a
C programmer.

C++ people think that their extremely complex language is the best of
all worlds. They have so little consideration for other views that
they really think, as you say:

I don't believe that anyone can really claim, at least with a straight face,
to know how everyone who ever learned to program in a specific programming
language thinks.

I have never used C++ unless I was forced to.

C++ is a mistake. It has produced a language that nobody understands,
not even Stroustrup himself.

The C++ language is complex, but your claim that "nobody understands" it is
based on a definition of "understands" that is a bit distorted and
inflamatory.

Throughout the years, plenty of complex pieces of software were successfully
implemented in C++, to the point that it seemed that the entire software
industry was based on C++. That wouldn't have happened if no one understood
the C++ programming language. So, in this aspect, your claim that "nobody
understands" C++ is patently false.

But then, although that was what you actually said, that certainly wasn't
what you meant. You certainly referred to the difficulty of gaining
complete insight into how each and every tiny bit of the language works and
interacts with anything else. The C++ programming language is complex.
Yet, you failed to mention that the complexity issue isn't exclusive to C++,
nor it is a significant limitation.

But let's come back to reality. I will not convince you that simplicity
outperforms complexity in software engineering.

So, be assured that C++ is the best invention since sliced bread.

You are the only person suggesting that claim.


Rui Maciel

 

[Rui Maciel]

Le 18/10/12 10:23, Juha Nieminen a écrit :
To say in a C group (comp.lang.c)


is NOT inflammatory, of course.

I did NOT treat anyone of "stupid" or "troll" Mr Nieminen.

It is, nevertheless, provocative. You have to admit that.

Just some facts to put this discussion in a less polemic tone:

1) Mr Stroustrup gave up on "concepts" after several YEARS of work. He
could not (as he said) understand all the implications that the change
could have, nor could the people in the standards committee so they just
balked out.

For me, in my stupid little mind, it means that nobody could really
understand the consequences of a modification of the language and that
the languagve has gotten too complex for humans to understand. You need
a machine to understand c++

You are referring to a change which, although it was proposed and considered
by the standards committee, wasn't made a part of the language. That means
that you aren't really referring to C++'s complexity as it stands, you are
referring to the complexity of a specific proposal. Bolting on a formal
verification system on a programming language isn't a trivial thing to pull,
particularly on a metaprogramming system. Would you claim that nobody
understood the C programming language if no one succeeds in bolting on a
formal verification system to it?

2) Further proof that C++ is a language humans can't fully understand is
the fact that the specifications for operator overloading (for instance)
go for pages and pages of the C++ standard and require in the last
resort a topological sort of all possible classes involved. This means
that it can only be done in a moderately complex application by a
machine (i.e. a compiler) that will do the sort and produce its result
that can be (maybe) followed by humans in a super human effort but
can't be done in a daily basis by the C++ programmers that can only
GUESS that their code is right.

3) And yet another proof is that when somebody asks something in the
C++ group the answer is in MOST cases

"I compiled it with compiler XXX and the answer was YYY"

and NOT

"The correct answer should be YYY because the standard specifies ..." etc.

That is a silly argument to make. The C programming language wouldn't
suddenly become a language that nobody understands if comp.lang.c was
suddenly flooded by people who answered "I compiled it with compiler X and
the answer was Y".

People give as a ROUTINE answer the answer the machine proposes them,
not the answer they deduced since understanding a statement can be
an impossible task.

The language has grown SO complex that nobody knows ALL the subtleties
of it. Most programmers know a small subset that they use (30-40%), and
ignore the rest. Experts may know 60-70%, but nobody really understands
it ALL.

That is irrelevant. Some C++ projects specifically state in their coding
guidelines that feature X and Y should not be used, which tend to influence
specialization. In addition, certainly you are aware that C++'s support for
metaprogramming was a fluke, and that no one is really required to fully
understand every obscure consequence of a fluke to be able to employ the
programming language efficiently. Would it be fair if people started to
make the same claim regarding C if a significant number of C programmers
weren't aware of Duff's device or every obscure alignment requirement
imposed by the standard?

Is it necessary for humans to understand completely a machine language?

No, and the same applies to pretty much any technical field. For example,
for ages buildings have been built in spite of the science behind them being
far from fully understood.


Rui Maciel

 

[Stuart]

Am 10/18/12 1:18 PM, schrieb James Kuyper:

On 10/18/12 James Kuyper wrote:
[snip]

I'm primarily a C programmer, so I may be
missing out some elegant C++ way of doing that, but the following
inelegant (and untested) code should do the job:

[snip]

I'm intrigued. I have never ever met someone who described himself as a
C programmer. May I ask what kind of business you are in? My guess is
your line of work includes either device drivers, embedded devices,
kernel code or something else that forces you to write C instead of C++.

I don't work in any of the areas you listed. I'm a scientific computer
programmer. My programs process data sent down from instruments mounted
on satellites (mainly geolocation and calibration of images). They run
24-7 in a production environment with no user interaction; they just
read and write files. The production system itself is controlled by a
GUI which interacts with the operators, but my programs themselves do not.

In all these years I have never met someone who used C instead of C++
unless he was forced to do so.

Our contract with our client imposes requirements on our delivered code.
Among other things, the permitted languages are C95, Fortan 77, Fortran
90, or Ada. So that part you got right.

Then I would have chosen Ada without a moments hesitation. I fell in
love with that language right away, and I believe that Ada compilers and
C++ compilers are equally complicated. It's a pity that Ada did not gain
the popularity of C++ but that is probably due to the fact that Ada came
too late (I know that C++ emerged later than Ada, but by that time
probably too many people were using C already, and the transition from C
to C++ is more "natural" than the transition from C to Ada, I guess).

I recently started work on an additional project covered by a different
contract with fewer restrictions, and most of the code is in C++. I've
found my extensive knowledge about C++ more useful than I expected, and
my lack of C++ experience less of a problem than I'd feared.

When I started programming with C++ I did not want to learn too much,
especially not that nifty template stuff. My coding style in those days
can best be described as "C-ish": I wrote the usual procedural code, but
instead of messing around with char* pointers and strcpy, I used
std::string (I only realized much later that this is already a templated
class).

Later I started to write my own classes and was thrilled. OOP! My man,
this rocked.

On day I stumbled upon a loop that ran really slow: It iterated over the
pixels of an image. Since my image could be either 8bits or 16bits so I
had to provide a virtual getPixel method. This was particularly clumsy:
My algorithm had to invoke a virtual method million of times only to
discover that it actually invoked the _same_ method each time. It would
be much better if I could have two versions of the same algorithm for
two different data types, thus avoiding the million virtual method
invokations.

It turned out that all I had to do was to make it a template function.
Easy, peasy, japanesey.

That's how it all started with this template stuff. Ten years later I
was writing code like this

template<class t_BaseImpl, class t_CoClass = t_BaseImpl::CoClassType>
class HAirCushionSwitchHelper : public t_BaseImpl
{
...

even before I had my morning coffee.

Admittedly, I have not had the guts to delve deeper into template
metaprogramming, but one should never say never. That's what I like
about C++: There is always a new continent to discover, but only when
you need it.

Regards,
Stuart

 

[Keith Thompson]

I think you are confusing variable-length arrays (in C) with the keyword
'auto', which has absolutely nothing to do with that (in either language).

Richard didn't mention the "auto" *keyword*. I think his point is
that a VLA must have automatic storage duration ("storage type auto"
was not the best way to phrase that).

Which is true for *identifiers* defined as VLAs, but not for all VLAs:

int x = /* whatever */;
int y = /* whatever */;
typedef double vla[x][y];
vla *ptr = malloc(sizeof *ptr);
if (ptr == NULL) {
/* allocation failed */
}

This lets you allocate a VLA on the heap. It has the advantage that
you can easily use array notation to access elements of the VLA:

(*ptr)[j]

without having to manage arrays of pointers, and you can test
whether the allocation succeeded.

(You can't do this in C++, but the standard library provides ways to do
similar things.)

 

[Ian Collins]

On 10/18/12 James Kuyper wrote:
[snip]

I'm primarily a C programmer, so I may be
missing out some elegant C++ way of doing that, but the following
inelegant (and untested) code should do the job: [snip]

I'm intrigued. I have never ever met someone who described himself as a C
programmer. May I ask what kind of business you are in? My guess is your
line of work includes either device drivers, embedded devices, kernel code
or something else that forces you to write C instead of C++. In all these
years I have never met someone who used C instead of C++ unless he was
forced to do so.

Well, you have now. I've worked in several shops (both small and billion
dollar companies) which were C only by choice. The consensus was that the
cost/benefit of C++ didn't pan out, particularly for backend, non-GUI work.
When you're writing high availability server software, the fewer moving
parts the better.

That's one situation where the C++ subset of C + RAII can be an
excellent choice.

C++ can be too big. You can certainly cherry pick features, but different
people cherry pick different features. And you also need someone who
understands _all_ the features to go through and grok those used and unused.

That is why it is important that choice of features is a team decision.
I have assisted a team who's chose to use just RAII and function
overloaded and another who jumped in boots and all with boost. Both
succeeded and both made the best choice for their projects and skill sets.

Plus, there's linking, interoperability, etc, which is more of a pain. And
C++'s strict typing can lead to code bloat and/or excessive casting.

I can't say I've seen either and I'm not sure how that could arise.

There are lots of cool features in C++, but often those features are better
implemented in other languages. It can be easier to use C + [insert other
language], then just C++. So, depending on your perspective, C++'s winning
features can seem middling to someone willing to use more than a single
language.

Unless like me you happen to be a driver writer!

I'm guessing that you come from a Windows background and/or graduated
college in the past 3 or 4 years. That's usually how it goes, IME. C++
didn't make waves in the Unix world until a few years ago, and then it took
off with Google and Apple**, especially when they picked up their college
recruitment. C++ grew up in Microsoft-land and in Microsoft-friendly
universities which dumped SUN--or never had the history to begin with. Which
isn't a slight, just an observation about the peculiarities of C++ culture.

It's not my sector, but I know C++ and Motif was very popular in the
banking world back in the 90s. Maybe it still is.

 

[Stuart]

Stuart wrote in reply to James Kuyper:
[snip]

I'm intrigued. I have never ever met someone who described himself [James
Kuyper, whom I replied to at that time, not William Ahern] as a C
programmer. May I ask what kind of business you are in? My guess is your
line of work includes either device drivers, embedded devices, kernel code
or something else that forces you to write C instead of C++. In all these
years I have never met someone who used C instead of C++ unless he was
forced to do so.

Well, you have now. I've worked in several shops (both small and billion
dollar companies) which were C only by choice. The consensus was that the
cost/benefit of C++ didn't pan out, particularly for backend, non-GUI work.
When you're writing high availability server software, the fewer moving
parts the better.

C++ can be too big. You can certainly cherry pick features, but different
people cherry pick different features. And you also need someone who
understands _all_ the features to go through and grok those used and unused.

In all the shops I have worked so far this choice was always up to me.
To put it more correctly, whenever I felt that the established
programming techniques became insufficient due to the restricted set of
compiler features, I made a presentation that showed how much effort a
particaluar, hitherto unused compiler feature can save. And if you use
the right words, your boss can almost never disagree with you because
any new technique that saves anything must be good! ;-)

Plus, there's linking, interoperability, etc, which is more of a pain. And
C++'s strict typing can lead to code bloat and/or excessive casting.

There are lots of cool features in C++, but often those features are better
implemented in other languages.

Do you mind giving an example? I often find that I have the wish to use
another programming language because it has some library that does not
exist under C++ (I haven't found platform independent C++ GUI library
that satisfies my needs, for example), but that should not be an
argument against the programming language itself because one just had to
implement a similar library for C++. There should be nothing inherent to
GUI programming that makes this problem space incompatible with the C++
programming language, I think, although the qt people think that
reflection is a good thing for GUI programming. But that is a story for
another day...

Scripting can also be a good argument against C++. Although there are
efforts to provide C++ scripting environments, this is probably too
difficult a task for the open-source community (and the industry does
not seem to be bothered with such a thing). I have only ever seen BGB
who designed a language called BGBScript that resembles C and can be
either compiled and interpreted, but chances are little that his
language will become main-stream.

It can be easier to use C + [insert other
language], then just C++. So, depending on your perspective, C++'s winning
features can seem middling to someone willing to use more than a single
language.

Interesting point. However, I always considered the additional friction
that stems from making two programming languages interoperate too much
an effort, so I decided to stick to a programming language that can to
"everything". Maybe that is a wrong thing to do (the last company I
worked at decided to use C++ for the hardware communication layer and C#
for the GUI, but that never really took off).

I'm guessing that you come from a Windows background and/or graduated
college in the past 3 or 4 years. That's usually how it goes, IME. C++
didn't make waves in the Unix world until a few years ago,

That always struck me as odd. After all, C++ was not invented by some
large company that wants to dictate what people should want (as it feels
when I use C# or Java) but by a single guy whom you can chat with in a
newsgroup. Almost grassroots, as one could say.

and then it took
off with Google and Apple**, especially when they picked up their college
recruitment. C++ grew up in Microsoft-land and in Microsoft-friendly
universities which dumped SUN--or never had the history to begin with. Which
isn't a slight, just an observation about the peculiarities of C++ culture.

Windows background, true, but not due to university. My hometown
university only offers a undergraduate course that is more or less a
introductory course for languages like Ada, C++ and Java. So one should
not be surprised to meet postdocs in computer science that don

I started to code in C++ ten years ago when I worked during semester
break at Fraunhofer institute. They used Borland's C++ compiler (*
sniff, remembering the good old times *). I had a look at some book that
showed how to write Win32 GUI apps with C and I found it awful. All
those gigantic switch statements, brrr ...
Admittedly, there may be some wrapper libraries for Win32 API that were
written in C, but I couldn't find a suitable one. Apparently C
programmers were supposed to use the Win32 API directly, I guess.

Regards,
Stuart

 

[Juha Nieminen]

There are lots of cool features in C++, but often those features are better
implemented in other languages.

That sounds to me like the typical discussion where someone is trying to
define what makes humans different from animals, and each time he says
"humans can do this" someone argues "well, (some obscure species) can do
that too!"

Most of the "better" languages also have drawbacks. The drawbacks might
not always be related to the language itself (although in many cases there
are those too), but about the environment. For example, C# is in principle
better than C++ in many aspects, but trying to use it is quite limiting
because, in practice, you will be restricting yourself to programming
for Windows (or the Xbox 360.)

(Yes, I know that there exist C# implementations for other platforms too,
but they just tend to be way more limited then Microsoft's C#, and a
typical C# program written for Windows will likely not compile for those
other platforms because there's so much Windows-specific stuff in a
typical C# program. Also, there's the issue that C# programs are about
3 times slower than equivalent C++ programs...)

Java excels at portability, and gives a good challenge to C and C++ in
the programming language shootout (and in fact beats C and C++ 100-0
in situations where one just must allocate millions of tiny objects
dynamically and there's no way around it). However, on a more average
level it tends to be slower, more resource-consuming, and always requires
a runtime environment (which makes it unsuitable for some applications).
It also has some annoyances at the language level.

Also, C++ does have some features that are not offered by other languages.
They might offer something that resembles it in a limited manner, but is
not quite as useful. For example, garbage collection is often touted as
a better replacement for RAII, but people who say this do not understand
that RAII is useful for much more than just memory management. Some even
claim that "generics" (they cannot be called "templates" because that's
a curseword) are better than C++ templates, while not seeing how much
more powerful templates are to "generics". The vast majority of languages
out there do not support value-based objects; while this is not always
useful, in many situations it certainly is, as it allows for very
significant speed and memory usage optimizations (which is one of the
reasons why C++ tends to be so fast compared to those, when competently
used.)

It can be easier to use C + [insert other
language], then just C++.

Ironically, your typo there actually makes the sentence better.

 

[Juha Nieminen]

However, that's probably not what the OP meant because he explicitly
wanted to use an initializer list to initialize the array. Therefore
he probably didn't mean to imply that the size of the array is only
known at runtime.

Right, except for the fact that he wrote:

"I need to set dynamic values [...] where both the values and the number
of values are only known at runtime."

Yes, so? I precisely said above that it's probably not what he meant
(because he wanted to use an initializer list.)

 

[Juha Nieminen]

Which is true for *identifiers* defined as VLAs, but not for all VLAs:

int x = /* whatever */;
int y = /* whatever */;
typedef double vla[x][y];
vla *ptr = malloc(sizeof *ptr);
if (ptr == NULL) {
/* allocation failed */
}

I don't think dynamically allocated arrays with malloc() are called
"variable length arrays". That term is quite specific and refers to
the new C99 feature where stack-allocated arrays do not need to have
a compile-time constant size.

 

[Keith Thompson]

Which is true for *identifiers* defined as VLAs, but not for all VLAs:

int x = /* whatever */;
int y = /* whatever */;
typedef double vla[x][y];
vla *ptr = malloc(sizeof *ptr);
if (ptr == NULL) {
/* allocation failed */
}

I don't think dynamically allocated arrays with malloc() are called
"variable length arrays". That term is quite specific and refers to
the new C99 feature where stack-allocated arrays do not need to have
a compile-time constant size.

The type "vla" is a variable-length array type. I happened to
allocate an object of that type via malloc(), rather than as a
declared object at block scope. The type meets the definition of
"variable length array" in N1370 6.7.6.2p4.

Not all arrays allocated with malloc() are VLAs, only those of some
VLA type:

typedef double not_a_vla[100];
not_a_vla *ptr = malloc(sizeof *not_a_vla);

 

[Noob]

However, that's probably not what the OP meant because he explicitly
wanted to use an initializer list to initialize the array. Therefore
he probably didn't mean to imply that the size of the array is only
known at runtime.

Right, except for the fact that he wrote:

"I need to set dynamic values [...] where both the values and the number
of values are only known at runtime."

Yes, so? I precisely said above that it's probably not what he meant
(because he wanted to use an initializer list.)

The initializer list is merely an illustration of the OP's /intent/
and he even realized that his illustration was not valid code:

"However, I need to set dynamic values along these lines
(I know that the code does not work)"

He then went on to state his /actual/ requirements:

"values and number of values are only known at runtime"

You can keep believing that "it's not just you", and "most of the
answers to the OP's question given in this thread [are] unusually
vague, incorrect and outright incompetent". I'm sure Dunning and
Kruger would love to include you in their follow-up study.

 

[James Kuyper]

However, that's probably not what the OP meant because he explicitly
wanted to use an initializer list to initialize the array. Therefore
he probably didn't mean to imply that the size of the array is only
known at runtime.

Right, except for the fact that he wrote:

"I need to set dynamic values [...] where both the values and the number
of values are only known at runtime."

Yes, so? I precisely said above that it's probably not what he meant
(because he wanted to use an initializer list.)

Isn't it more likely that he was wrong about wanting to use an
initializer list (because he mistakenly thought that he could use it
this way), than that he was wrong about needing to set the values at run
time? That assumption seems to me to be much more consistent with what
he said.

 

[gus gassmann]

However, that's probably not what the OP meant because he explicitly
wanted to use an initializer list to initialize the array. Therefore
he probably didn't mean to imply that the size of the array is only
known at runtime.

Right, except for the fact that he wrote:

"I need to set dynamic values [...] where both the values and the number
of values are only known at runtime."

Yes, so? I precisely said above that it's probably not what he meant
(because he wanted to use an initializer list.)

The initializer list is merely an illustration of the OP's /intent/
and he even realized that his illustration was not valid code:

"However, I need to set dynamic values along these lines
(I know that the code does not work)"

He then went on to state his /actual/ requirements:

"values and number of values are only known at runtime"

You can keep believing that "it's not just you", and "most of the
answers to the OP's question given in this thread [are] unusually
vague, incorrect and outright incompetent". I'm sure Dunning and
Kruger would love to include you in their follow-up study.

At the risk of starting a flame war, but in the hopes of keeping down
traffic: Noob's got it exactly right.

What threw me was the "static" keyword in the code sample that I was
provided, combined with some bad experiences about ignoring things like
that with this particular header file and a rather superficial
understanding of the language. Thanks to Noob and others I got the code
to work. So, even if the answers given were "vague, incorrect and
outright incompetent", they got me on the right track. Now, if there
were inefficiencies or other gotchas I need to watch out for going
forward, I would love to hear about it.

Thanks.

 

[James Kuyper]

Which is true for *identifiers* defined as VLAs, but not for all VLAs:

int x = /* whatever */;
int y = /* whatever */;
typedef double vla[x][y];
vla *ptr = malloc(sizeof *ptr);
if (ptr == NULL) {
/* allocation failed */
}

I don't think dynamically allocated arrays with malloc() are called
"variable length arrays". That term is quite specific and refers to
the new C99 feature where stack-allocated arrays do not need to have
a compile-time constant size.

<side_issue>The C standard doesn't talk about "stack-allocated". The
closest it comes is the term "automatic storage duration". I'll assume
that's what you're talking about. While the rules governing the
lifetimes of objects with automatic storage duration allow, and even
encourage, implementation using stack-like semantics, it's not mandatory
that they be allocated from the actual hardware stack (if there even is
one). For example, some real-world implementations implement those
semantics using activation records rather than a hardware
stack.</side_issue>

"... If an identifier is declared to be an object with static or thread
storage duration, it shall not have a variable length array type. ..."
(6.7.6.2p2). Only two of the four storage durations are prohibited by
that clause; both automatic and allocated storage durations are allowed.

"... If the size is * instead of being an expression, the array type is
a variable length array ... If the size is an integer constant
expression and the element type has a known constant size, the array
type is not a variable length array type; otherwise, the array type is a
variable length array type. ..." (6.7.6.2p4) The first and third
occurrences of "variable length array" in that citation are italicized,
indicating that those sentences together constitute the definition of
the term.

The type of *ptr is an array with a size of x, which is neither '*' nor
an integer constant expression. That alone would be enough to give *ptr
a variable length array type. However, the element type of that array is
also double[y], which does not have a known constant size, which would
therefore also be sufficient to make it a variable length array type.
ptr itself does NOT have a VLA type, it only points at one. It does,
however, have a variably modified (VM) type. There are no restrictions
on the storage duration of VM types, only of VLA types.

 

[Stuart]

That sounds to me like the typical discussion where someone is trying to
define what makes humans different from animals, and each time he says
"humans can do this" someone argues "well, (some obscure species) can do
that too!"

I rather thought that -- for a change -- we had a rather different
discussion, e.g. why some people prefer C over C++ (William original
stated that he considered himself rather a C programmer than a C++
programmer). That caught my interest because I always thought that
hardly anyone used C instead of C++ (unless outer circumstances dictated
that C must be used). In my eyes this looks as if someone bought a Audi
TT and contented himself never to drive faster than 80kmh/50mph (case in
point: my professor

[snip]

Java excels at portability, and gives a good challenge to C and C++ in
the programming language shootout (and in fact beats C and C++ 100-0
in situations where one just must allocate millions of tiny objects
dynamically and there's no way around it).

You mean Java beats C++'s standard allocator, don't you? SCNR, but I
don't want to start another flame war (this has already gone to far IMHO).

It can be easier to use C + [insert other
language], then just C++.

Ironically, your typo there actually makes the sentence better.

Didn't caught it until you pointed it out. Nice one. Doesn't mean that I
agree, though, since I hear from more and more people that they use a
multitude of programming languages in a single project. Makes me feel
like a relict.

Regards,
Stuart

 

[Juha Nieminen]

That caught my interest because I always thought that
hardly anyone used C instead of C++ (unless outer circumstances dictated
that C must be used).

Many people use C, some for good reasons, others out of stubborness even
though they do know the limitations of C and advantages of other languages
(whether they actually *acknowledge* it or not is another story), and yet
others use it for completely misinformed reasons.

You mean Java beats C++'s standard allocator, don't you? SCNR, but I
don't want to start another flame war (this has already gone to far IMHO).

The C/C++ standard allocator tends to have horrendous efficiency (not
helped by the fact that it's basically impossible to make it a compacting
allocator, which is perfectly possible in a JVM.)

In order to get good allocation speed in C/C++ you have to resort to other
means, bypassing the system allocator (ie. bypassing it for individual
allocations; of course you still allocate big chunks at a time from it).
Even then, it's still difficult to match the allocation speed of a good
JVM (which can perform some types of cache optimizations that are very
difficult, if not impossible, to do in a C/C++ program.)

Luckily, it's relatively rare to need to allocate millions of individual
small objects in C++ (because objects can be handled by value.)

 

[ImpalerCore]

Many people use C, some for good reasons, others out of stubborness even
though they do know the limitations of C and advantages of other languages
(whether they actually *acknowledge* it or not is another story), and yet
others use it for completely misinformed reasons.



The C/C++ standard allocator tends to have horrendous efficiency (not
helped by the fact that it's basically impossible to make it a compacting
allocator, which is perfectly possible in a JVM.)

In order to get good allocation speed in C/C++ you have to resort to other
means, bypassing the system allocator (ie. bypassing it for individual
allocations; of course you still allocate big chunks at a time from it).
Even then, it's still difficult to match the allocation speed of a good
JVM (which can perform some types of cache optimizations that are very
difficult, if not impossible, to do in a C/C++ program.)

Luckily, it's relatively rare to need to allocate millions of individual
small objects in C++ (because objects can be handled by value.)

It's still possible to layer a slab allocator on top of the general
purpose allocator in C optimized for small objects. It's not trivial
to implement, but you can make an allocator tuned to allocate pages
that are sliced up into fixed sized blocks, and then write a wrapper
over that to handle slabs of aligned block sizes as a kind of "small
object" allocator. But it's definitely not readily available from the
C standard library.

In the use case of a linked list, the ability to allocate a list's
nodes from a fixed-block slab can greatly improve its allocation speed
and its cache consistency (useful for improving it's performance when
traveling the list) over the general purpose allocator, which throws
everything and the kitchen sink into the same blob memory (which will
really hurt cache consistency). If the list objects are of fixed
size, like a linked list of integers, one can have a slab allocator
for the list nodes, and a slab allocator for the 'int' objects, and
you'll reap the same benefits (with the bonus of blasting that memory
away at the slab level when done with the linked list). Of course
this increases the programmer's complexity over just using the
standard allocator, but it's certainly possible.

Best regards,
John D.

 

[Öö Tiib]

It is, nevertheless, provocative. You have to admit that.

Developers should write in the language that they like. Nobody should writeprograms in language that they hate. Probably Jakob Navia is forced to useC++ for something against his own will and that makes him always so poisonous.