[Commercial] Advance C and Linux System Programming: Hands-OnTraining

[Concepts Systems]

Hello All,

Advance C and Linux System Programming are an intensive hands-on
course designed by Concepts Systems to provide a detailed examination
of each topic.
These modules enable professionals and students to rapidly identify
issues critical to their project, and provide them in-depth knowledge
to add Linux support to their product lines in an aggressive time
frame.

Course Highlights:

Advance C:

- Struct ,enums,typedefs, #define
- Arrays & Pointer Arithmetic
- Function Pointers etc
- Dynamic linking
- Segments & Executables
- calling conventions
- Segmentation Faults

Detail syllabus is available at

http://www.conceptssys.com/SyllabusPdf/Adv C.pdf

Linux System Programming:

-Operating Systems Basics
-System Calls for I/O
-Multithreading and Synchronization
-Interprocess communication
-Memory Management
-Memory mapped files
-UNIX/ POSIX files and File Systems
-Pipes

Detail syllabus is available at

http://www.conceptssys.com/SyllabusPdf/LinuxSysPro.pdf
Starting Date : May 24, 2008.
Duration : 1.5 months for each module.
Days & Timings: Saturday and Sunday, 3 Hours Per day.

Venue:
Concepts Systems,
602-603, The Pentagon, Shahu College Road,
Next to Pune-Satara Road,
Near Panchami Hotel, Parvati. Pune - 411009.

Registration: We encourage you to register at the earliest since there
are limited seats.

If you have any queries feel free to call us on 020-24216888 /
9960638738 Or mail us at tr******@conceptssys.com.

About Us:
Concepts Systems is Pune based Training Consultancy having expertise
in core systems. Concepts already has many leading software companies
like EMC, HP, Nvidia,Oracle India, KPIT Cummins etc. as its clients.
Systems Technology Experts having Industry exposure forms backbone of
Concepts Training Division.

Thanks & Regards,
Concepts Systems Team

[Richard Heathfield]

Concepts Systems said:

<snip>

>
Detail syllabus is available at

http://www.conceptssys.com/SyllabusPdf/Adv C.pdf

Not a particularly detailed syllabus, actually - but instructive insofar as
it demonstrates that the author of that syllabus doesn't appear to
understand casting. This is betrayed by his calling it "type casting". In
C, we don't cast types. We cast expressions. It is, in fact, impossible to
cast a type.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Bart]

On May 11, 9:49*am, Richard Heathfield <[e-mail]:

Concepts Systems said:

<snip>

Detail syllabus is available at

http://www.conceptssys.com/SyllabusPdf/AdvC.pdf

Not a particularly detailed syllabus, actually - but instructive insofar as
it demonstrates that the author of that syllabus doesn't appear to
understand casting. This is betrayed by his calling it "type casting". In
C, we don't cast types. We cast expressions. It is, in fact, impossible to
cast a type.

T x;
U y;

y=(U)x;

What changes about x in this expression? The expression doesn't; it's
still x. The value /might/, eg. if T and U were numeric types. Mainly
it's the type from T to U;

So Type Casting is a better description than Expression Casting or
Value Casting.

Maybe the author was trying to be clear rather than pedantically
precise (and Type Casting is ambiguous in English anyway).

--
Bartc

[Spiros Bousbouras]

On 11 May, 09:49, Richard Heathfield <[e-mail]:

Concepts Systems said:

<snip>

Detail syllabus is available at

http://www.conceptsys.com/SyllabusPdf/AdvC.pdf

Not a particularly detailed syllabus, actually - but instructive...

You have just exhibited to the world that spamming this
group does work since you bother to read the spam.

[santosh]

Bart wrote:

You snipped attributions.

Richard Heathfield wrote:

>In C, we don't cast types. We cast expressions. It
is, in fact, impossible to cast a type.

T x;
U y;

y=(U)x;

What changes about x in this expression? The expression doesn't; it's
still x. The value /might/, eg. if T and U were numeric types. Mainly
it's the type from T to U;

From section 6.5.4 of n1256:

Syntax

1 cast-expression:
unary-expression
( type-name ) cast-expression

Constraints

2 Unless the type name specifies a void type, the type name shall
specify qualified or unqualified scalar type and the operand shall have
scalar type.

3 Conversions that involve pointers, other than where permitted by the
constraints of 6.5.16.1, shall be specified by means of an explicit
cast.

Semantics

4 Preceding an expression by a parenthesized type name converts the
value of the expression to the named type. This construction is called a
cast.89) A cast that specifies no conversion has no effect on the type
or value of an expression.

5 If the value of the expression is represented with greater precision
or range than required by the type named by the cast (6.3.1.8), then the
cast specifies a conversion even if the type of the expression is the
same as the named type.

[Bart]

On May 11, 4:50*pm, santosh <[e-mail]:

Bart wrote:

You snipped attributions.

Richard Heathfield wrote:

In C, we don't cast types. We cast expressions. It
is, in fact, impossible to cast a type.

T x;
U y;

y=(U)x;

What changes about x in this expression? The expression doesn't; it's
still x. The value /might/, eg. if T and U were numeric types. Mainly
it's the type from T to U;

From section 6.5.4 of n1256:

...

4 Preceding an expression by a parenthesized type name converts the
value of the expression to the named type. This construction is called a
cast.89) A cast that specifies no conversion has no effect on the type
or value of an expression.

I mentioned expressions, values and types, and that the latter two can
change.

This mentions that values can change; also 'has no effect on type or
value' suggests that a cast that specifies a conversion can affect
both value and type.

Richard Heathfield mentioned casting 'expressions'.

A lot of the stuff in this syllabus isn't even part of the standard.

My point is that Type Casting seems perfectly acceptable (especially
as the English doesn't appear to be of the best).

--
Bartc

[Richard Heathfield]

Spiros Bousbouras said:

On 11 May, 09:49, Richard Heathfield <[e-mail]:

>Concepts Systems said:

<snip>

Detail syllabus is available at

>http://www.conceptsys.com/SyllabusPdf/AdvC.pdf

Not a particularly detailed syllabus, actually - but instructive...

You have just exhibited to the world that spamming this
group does work since you bother to read the spam.

That's one way of looking at it. Another way, the way I look at it, is
this: it's possible that some people might be unwise enough to take the
advertisement on trust; by posting a rebuttal, even a little one, it may
be that I succeed in saving at least one newbie from wasting his
hard-earned cash on a course that is very likely to be broken.

If in the process I attract flak for "responding to spam", so be it.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Peter Nilsson]

Richard Heathfield wrote:

... the author of that syllabus doesn't appear to understand casting.
This is betrayed by his calling it "type casting". In C, we don't cast
types. We cast expressions. It is, in fact, impossible to cast a type.

Well that explains the UK's reluctance to apply metric conversions to
miles per gallon. Okay US, what's your excuse?

--
Peter