Design decisions

[Ian Collins]

Le 23/06/12 00:21, Ian Collins a écrit :

It is difficult to understand, maybe because "s" is undefined

ManageSomething(Something s) looks like a function call but probably
isn't one since you are declaring a struct, so it must be a declaration
of a constructor. Yes, and then a further function call (or similar)
separated by a colon. Mmmm I have seen that sometimes in C++ code
and "thing" is a "Something" so that must be a function call?

Or not?

You can be worried, I do not parse all that and I do not care actually
to parse that.

Somewhat disingenuous coming from someone who claims to be paid to
maintain C++ code don't you think?

Yes. Up to 30% or more of space are now taken by tables describing the
stack movements to the unwinding virtual machine that the C++ run time
needs.

Now where did you dig up that "fact" from? Automatic destruction works
perfectly well without run time support.

But this has no sense Ian. Keep C++. I will go on developing simple
solutions to simple problems. A stack is a stack, and I prefer pushing
the things to cleanup into a stack with:

pushCleanup( Opcode,pointer);

each time I need to cleanup something, and then I just write:

UnwindCleanupStack();

and I am done. And I write pushCleanup() and Unwind once and I can
use them again and again.

I prefer to let the compiler do the pushing and popping for me. Lazy?
maybe, but I know the compiler won't have a bad hair day and forget to
pop something.

 

[jacob navia]

Le 23/06/12 02:59, Ian Collins a écrit :

On 06/23/12 12:13 PM, jacob navia wrote:

Now where did you dig up that "fact" from? Automatic destruction works
perfectly well without run time support.

Confirmed. Most C++ programmers have no idea of what is needed behind
the scene to make all those nice syntax constructs work.

AUTOMATIC DESTRUCTION MUST WORK IN THE CASE OF A THROW.

So, since the compiler can't know if a throw will go through the
procedure that you are compiling it must generate a description of all
stack movements just in case.

The stack unwinding machinery needs information about push/pop and any
stack addition/subtraction. This is described in detail by gcc/MSVC and
other c++ compilers, and by lcc-win, since I do generate that
information also.

Surprised?

lcc-win generates that information because even if it never invokes a
throw, it could be that a throw passes through tghe code of lcc-win
when the lcc-win libraries are used with C++.

 

[Ian Collins]

Le 23/06/12 02:59, Ian Collins a écrit :

Confirmed. Most C++ programmers have no idea of what is needed behind
the scene to make all those nice syntax constructs work.

Confirmed, you are talking out of the wrong end again.

AUTOMATIC DESTRUCTION MUST WORK IN THE CASE OF A THROW.

Not if you turn exceptions off, which is a better comparison in this
case (C++ as a better C). I use C++ (mainly to get automatic resource
management) in driver and kernel module code where there isn't any run
time support, so I most certainly do know what goes on behind the scenes.

For example, the following

extern "C" int* get();
extern "C" void done(int*);
extern "C" void process(int*);

struct Manage {
int* n;
Manage( int* n ) : n(n) {}
~Manage() {done(n);}
};

void f() {
int* n = get();
Manage m(n);
process(n);
}

Compiles (with g++ -S -O3 -fno-exceptions) to:

.file "z.cc"
.text
.p2align 4,,15
..globl _Z1fv
.type _Z1fv, @function
_Z1fv:
pushl %ebp
movl %esp, %ebp
pushl %ebx
subl $20, %esp
call get
movl %eax, %ebx
movl %eax, (%esp)
call process
movl %ebx, (%esp)
call done
addl $20, %esp
popl %ebx
popl %ebp
ret
.size _Z1fv, .-_Z1fv
.ident "GCC: (GNU) 4.5.2"

Which is probably tighter than any manual stack pushing and popping.

 

[jacob navia]

Le 23/06/12 11:52, Ian Collins a écrit :

Not if you turn exceptions off,

If you turn it off, the whole program must turn them off if not
it will crash.

But OK, you can do that and use C++ in a 'lite' mode

 

[Stefan Ram]

int (*GetElement)(intList *l,size_t idx);
The problem is that it is not possible to return an error

I am late to this thread. So: Sorry, if that was already
suggested:

if( has_element( l, i ))
{ int const element = get_element( l );
use( element ); }
else
{ int const whynonextelement_code = get_whynonextelement_code( l );
if( whynonextelement_code != LIST_IS_EMPTY )
fputs( get_whynonextelement_string_enUS( l ), stderr ); }

In the above code, »l« could or should be a list iterator
instead of a list. The mandatory call of »has_element« also
sets the »size_t idx« for the next calls of the API, so they
only have one argument. After each call of »has_element«, at
most one call per function of each of the other functions is
allowed. A »get_element« with no preceding »has_element« is
UB, but will print an error message in debug mode.

 

[Stefan Ram]

if( has_element( l, i ))
{ int const element = get_element( l );
use( element ); }
else
{ int const whynonextelement_code = get_whynonextelement_code( l );
if( whynonextelement_code != LIST_IS_EMPTY )
fputs( get_whynonextelement_string_enUS( l ), stderr ); }

WRT the naming style: shorter names would be nice:

if( has( l, i ))
{ int const it = element( l );
use( it ); }
else
{ int const code = whynot( l );
if( code != EMPTY )
fputs( whynot_enUS( l ), stderr ); }

But then, one wants to avoid clashes, so:

if( jnlist_has( l, i ))
{ int const it = jnlist_element( l );
use( it ); }
else
{ int const code = jnlist_whynot( l );
if( code != JNLIST_EMPTY )
fputs( jnlist_whynot_enUS( l ), stderr ); }

 

[jacob navia]

Le 22/06/12 10:42, jacob navia a écrit :

Note that the trivial new Finalize procedure is skipped. It just frees
the copied VTable allocated with malloc.

This is no longer necessary. The standard Finalize procedure will
compare the VTable to the default value. If it is different, Finalize
wxill assume that it has been allocated and it will free it using the
Vector's allocator object.


One less thing to do.

 

[Joe.]

"Design decisions"? As in, you can't design your way out of a paper bag but
"the interrape" is a place to get what you want: something for nothing?

As is my nature, I should just ask questions:

What is "the interrape"?
Are other species of life <> than humans?

In the new

As if the readers of this USENET discussion group actually gave a shit about
your "old" "offering".

As it stands, jake the snake, no one needs to wait for you to grow up,
because youth is growing up faster around you than you may realize. That
said, I don't mean to push a weak person like you into the grave or to do
something wrong. That said, this is not an offer for help. If you want to
flame around C programming as some kind of "guru", ... can you do anything
else? You really suck at software development, at the large... perhaps a
role in a VERY structured environment where you can twiddle bits and be
slapped on the knuckles at every juncture for your failure to grasp your
"role" in that environment... I digress.

Politics have hurt not only you, but all people. You may find for yourself
that you have no place to work, because ... why? I'm hardly one to avoid
characterization (true/false/evil/whatever). Ha! I find myself in what I
wrote "no place to work", that is, of course, the proverb of the falacy of
"job" (not the saint, but rather the verbage of the politician's tongue,
hopefully to soon be known as verbage of politician tongue).

So, what is "a job"? Why do politicians spew such verbage and not define it?

Oh, I have lots of questions. But of course my "job" requires compensation
to keep up the good work. Else you can take this "job" and shove it.

*****

But I digress. (TBD).

 

[Joe.]

How does C++ deal with it?

My feeling is that GetElement should be as simple and convenient to use as
possible, especially for the 99.999% of calls (and usually 100%) where
there is no error. Perhaps have two versions, one where any errors are
handled internally (either aborting, returning an agreed default value, or
whatever), and another which has full error returns for people who insist
on checking every single list access themselves.

He sucked you in?

 

[Joe.]

Er, no you don't. Allocated memory isn't the only thing you may want to
clean up.

This situation is much the same as the early return cases discussed at
great length on the recent goto thread.

Who could not respect someone with a name like yours?

Aren't you a "golden boy" playin it safe by "being good"?

(Maybe you and James Kanze should team up and conquer the world?).

 

[Joe.]

Le 22/06/12 10:00, gwowen a écrit :

Really? Do you really believe that? What about resources that are not
memory - mutex/critical sections, network connections, open ports,
file descriptors.

How would I use your error handler to do this:

[snip code]


Very easy. Just use a pushdown stack. Each time you acquire a
mutex lock you push it in the stack, each time you release it you pop it.

If an exception occurs, you pop the whole mutex stack. This would
require just a few lines more of code.

"So much" discussion for .... ah, my bad.. y'all are just learning how to
program. And I say I'm intuitive. Code-on, grasshoppers.

- They call it "freedom", but rape is legal. (unknown).

 

[Joe.]

How does C++ deal with it?

Of the C++ standard containers, only basic_string, array, deque, and
vector containers have a close equivalent of GetElement. The other
container types do not provide int-indexed access. The ones that do,
each have two GetElement equivalents. If Container is one of those
templates, then given the declaration:

Container<T> container;

the expressions container[idx] and container.at(idx) both have the
semantics of *(container.begin()+n). If idx is out of range,
container[idx] has undefined behavior; container.at(idx) throws
std:ut_of_range.

Pfft. An "authority" on C++? Apparently you are milking the fact that you
know a lot about a nothing, that nothing being C++? I've been programming in
C# for 3 years and know it is superior to C++, or I may be lying.